Arquitetura Computadores

http://www.candidatoreal.
com
http://www.candidatoreal.com
Sum
ario
I Fundamentos de Computac
ao 16
1 Arquitetura e Organiza c
ao de Computadores 17
1.1 Conceitos Basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Estrutura e Funcionamento da CPU . . . . . . . . . . . . . . . . 18
1.2.1 Pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Conjunto de Instrucoes . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4 Unidade de Controle . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.5 Modos de Enderecamento . . . . . . . . . . . . . . . . . . . . . . 25
1.6 Organizac
ao de Mem oria . . . . . . . . . . . . . . . . . . . . . . . 26
1.7 Desempenho do computador . . . . . . . . . . . . . . . . . . . . . 28
1.7.1 Tempo de execuc ao de um programa . . . . . . . . . . . . 29
1.7.2 Desempenho da CPU . . . . . . . . . . . . . . . . . . . . 29
1.7.3 Programas para medir desempenho . . . . . . . . . . . . . 30
1.7.4 Comparando desempenho . . . . . . . . . . . . . . . . . . 30
1.7.5 Lei de Amdahl . . . . . . . . . . . . . . . . . . . . . . . . 31
2 Componentes de um Computador 33
2.1 Principais componentes de Hardware . . . . . . . . . . . . . . . . 34
2.1.1 Discos Rgidos . . . . . . . . . . . . . . . . . . . . . . . . 34
2.1.2 Teclado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.1.3 Mouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.1.4 Placa de rede . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.1.5 Impressora . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1.6 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3 Aritmetica Computacional 39
3.1 Numeros Com Sinal e N umeros Sem Sinal . . . . . . . . . . . . . 39
3.1.1 Sinal e amplitude/magnitude . . . . . . . . . . . . . . . . 39

3.1.2 Complemento de 1 . . . . . . . . . . . . . . . . . . . . . . 39
3.1.3 Complemento de 2 . . . . . . . . . . . . . . . . . . . . . . 39
3.1.4 Notacao em excesso . . . . . . . . . . . . . . . . . . . . . 40
3.2 Adic
ao e Subtrac
ao . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Operac
oes L
ogicas . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Construc
ao de uma Unidade L ogica Aritmetica . . . . . . . . . . 42
3.5 Ponto Flutuante . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1
4 Sistemas Operacionais 44
4.1 Introduc
ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Conceitos B asicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 Multiprogramac ao . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2 Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.3 Interrupcoes . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.4 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Escalonamento de Processos . . . . . . . . . . . . . . . . . . . . . 49
4.4 Entrada e Sada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1 Camadas do subsistema de Entrada e Sada . . . . . . . . 51
4.5 Gerencia de Mem oria . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.6 Sistemas de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.6.1 Conceitos b asicos sobre arquivos . . . . . . . . . . . . . . 54
4.6.2 Implementacao de arquivos . . . . . . . . . . . . . . . . . 56
4.6.3 Cache de Sistema de Arquivos . . . . . . . . . . . . . . . 57
4.6.4 Gerenciamento do espaco livre . . . . . . . . . . . . . . . 58
4.6.5 Diretorios . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6.6 Implementacao de diret orios . . . . . . . . . . . . . . . . . 61
4.7 Sistemas Operacionais Distribudos . . . . . . . . . . . . . . . . . 61
4.7.1 Estruturac ao de Sistemas Distribudos . . . . . . . . . . . 63
5 Principais Processadores de Mercado 65

5.1 Processadores Intel . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.1 Famlia Pentium . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.2 Famlia Celeron . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1.3 Famlia Core . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1.4 Xeon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.5 Itanium . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2 AMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.1 Sempron . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.2 Athlon 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.3 Turion 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.4 Opteron . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
II L
ogica de Programac
ao 83
6 Orientac
ao a Objetos 84
6.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.2 Conceitos fundamentais . . . . . . . . . . . . . . . . . . . . . . . 84

6.3 Princpios de programac ao orientada a objetos . . . . . . . . . . 90
6.4 Tratamento de excecoes . . . . . . . . . . . . . . . . . . . . . . . 90
III Metodologia de Desenvolvimento 92

7 Ciclo de Vida 93
7.1 Modelo seq
uencial linear . . . . . . . . . . . . . . . . . . . . . . . 95
7.2 Modelo em V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.3 Modelo de prototipagem . . . . . . . . . . . . . . . . . . . . . . . 96
2
7.4 Modelo RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.5 Modelos de processo de software evolucion arios . . . . . . . . . . 97
7.5.1 Modelo incremental . . . . . . . . . . . . . . . . . . . . . 97
7.5.2 Modelo espiral . . . . . . . . . . . . . . . . . . . . . . . . 98
7.5.3 Modelo espiral ganha-ganha . . . . . . . . . . . . . . . . . 99
7.5.4 Modelo de desenvolvimento concorrente . . . . . . . . . . 100
7.6 Desenvolvimento baseado em componentes . . . . . . . . . . . . . 100
7.7 Modelo de metodos formais . . . . . . . . . . . . . . . . . . . . . 100
7.8 Tecnicas de quarta gerac
ao . . . . . . . . . . . . . . . . . . . . . 100
8 Analise Comparativa de Processos de Desenvolvimento 102

8.1 RUP - Rational Unified Process . . . . . . . . . . . . . . . . . . . 102
8.2 XP - Extreme Programming . . . . . . . . . . . . . . . . . . . . . 105
8.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.4 Crystal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.5 Feature Driven Development (FDD) . . . . . . . . . . . . . . . . 106
8.6 Dynamic Systems Development Method (DSDM) . . . . . . . . 107
8.7 Adaptive Software Development (ASD) . . . . . . . . . . . . . . 107
9 Engenharia de Requisitos 109

9.1 O Processo de Engenharia de Requisitos . . . . . . . . . . . . . . 109
9.2 Tecnicas de Levantamento de Requisitos . . . . . . . . . . . . . . 110
9.2.1 Observac ao . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.2.2 Entrevista . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.2.3 An alise de Protocolo . . . . . . . . . . . . . . . . . . . . . 111
9.2.4 JAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.2.5 PD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.2.6 QFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.2.7 CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
9.2.8 Prototipac ao . . . . . . . . . . . . . . . . . . . . . . . . . 112
9.2.9 Cen arios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
9.2.10 FAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
9.3 Analise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.3.1 Metodos de an alise . . . . . . . . . . . . . . . . . . . . . . 114
9.3.2 Modelagem da an alise . . . . . . . . . . . . . . . . . . . . 114
9.4 Gerenciamento de Requisitos . . . . . . . . . . . . . . . . . . . . 116
10 Metricas 118
10.1 Metricas de processo e aperfeicoamento de processo de software . 118
10.2 Metricas de projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 119

10.3 Medic
ao de software . . . . . . . . . . . . . . . . . . . . . . . . . 119
10.3.1 Metricas orientadas a tamanho . . . . . . . . . . . . . . . 120
10.3.2 Metricas orientadas a funcao . . . . . . . . . . . . . . . . 120
10.3.3 Metricas de pontos por funcao estendidas . . . . . . . . . 122
10.4 Metricas de qualidade de software . . . . . . . . . . . . . . . . . 122
10.4.1 Fatores de qualidade de McCall . . . . . . . . . . . . . . . 123
10.4.2 FURPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
10.4.3 ISO 9126 . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
10.5 Estimativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
10.5.1 COCOMO (Constructive Cost Model) . . . . . . . . . . . 125
3
11 Testes 127
11.1 Teste de caminho b asico . . . . . . . . . . . . . . . . . . . . . . . 127
11.2 Teste de estrutura de controle . . . . . . . . . . . . . . . . . . . . 129
11.2.1 Teste de condic ao . . . . . . . . . . . . . . . . . . . . . . . 129
11.2.2 Teste de fluxo de dados . . . . . . . . . . . . . . . . . . . 130
11.2.3 Teste de ciclo . . . . . . . . . . . . . . . . . . . . . . . . . 130
11.3 Teste caixa-preta . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
11.3.1 Metodos de teste baseados em grafo . . . . . . . . . . . . 131
11.3.2 Particionamento de equivalencia . . . . . . . . . . . . . . 131
11.3.3 An alise de valor limite . . . . . . . . . . . . . . . . . . . . 132
11.3.4 Teste de comparac ao . . . . . . . . . . . . . . . . . . . . . 132
11.3.5 Teste de matriz ortogonal . . . . . . . . . . . . . . . . . . 132
11.4 Teste de ambientes, arquiteturas e aplicac oes especializadas . . . 133
11.5 Estrategia de teste de software . . . . . . . . . . . . . . . . . . . 134
12 UML 136
12.1 Diagrama de caso de uso . . . . . . . . . . . . . . . . . . . . . . . 136
12.1.1 Ator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
12.1.2 Descric
ao do caso de uso . . . . . . . . . . . . . . . . . . . 137
12.2 Diagrama de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 137
12.2.1 Associacoes de classe . . . . . . . . . . . . . . . . . . . . . 138
12.3 Diagramas de seq uencia . . . . . . . . . . . . . . . . . . . . . . . 140
12.4 Diagramas de colaborac ao . . . . . . . . . . . . . . . . . . . . . . 140
12.5 Diagramas de estado . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.6 Diagramas de atividade . . . . . . . . . . . . . . . . . . . . . . . 143
12.7 Elementos auxiliares . . . . . . . . . . . . . . . . . . . . . . . . . 144
12.8 Diagramas de componente . . . . . . . . . . . . . . . . . . . . . . 144
12.9 Diagramas de distribuic ao . . . . . . . . . . . . . . . . . . . . . . 144
13 Gerencia de Configura c
ao e Mudan cas 145
13.1 As Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
13.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
13.3 Papeis e Responsabilidades . . . . . . . . . . . . . . . . . . . . . 147
14 CMM - Capability Maturity Model 149

14.1 Os nveis de maturidade no CMM . . . . . . . . . . . . . . . . . 150
14.1.1 Nvel 1 - Inicial . . . . . . . . . . . . . . . . . . . . . . . . 150
14.1.2 Nvel 2 - Repetitivo . . . . . . . . . . . . . . . . . . . . . 150
14.1.3 Nvel 3 - Definido . . . . . . . . . . . . . . . . . . . . . . . 151
14.1.4 Nvel 4 - Gerenciado . . . . . . . . . . . . . . . . . . . . . 152

14.1.5 Nvel 5 - Otimizado . . . . . . . . . . . . . . . . . . . . . 152
14.2 Um pouco mais sobre KPAs . . . . . . . . . . . . . . . . . . . . 152
14.3 Efeitos da evoluc
ao do nvel de maturidade . . . . . . . . . . . . 153
IV Linguagem de Programac
ao Java 155
15 Conceitos B asicos de Java 156
15.1 Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
15.2 Modificadores de Acesso . . . . . . . . . . . . . . . . . . . . . . . 157
4
15.3 Vari
aveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
15.4 Operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
15.5 Express oes, Sentencas e Blocos . . . . . . . . . . . . . . . . . . . 160
15.6 Comandos de Controle de Fluxo . . . . . . . . . . . . . . . . . . 161
15.7 Classes Aninhadas . . . . . . . . . . . . . . . . . . . . . . . . . . 166
15.8 Tipos Enumerados . . . . . . . . . . . . . . . . . . . . . . . . . . 167
15.9 Anotacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
15.10Genericos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
15.11Reflex
ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
16 Classes Essenciais 173

16.1 Exception e Controle de Excec oes . . . . . . . . . . . . . . . . . . 173
16.1.1 Excec
oes tpicas . . . . . . . . . . . . . . . . . . . . . . . 173
16.1.2 Capturando Excec oes . . . . . . . . . . . . . . . . . . . . 175
16.2 Threads e Concorrencia . . . . . . . . . . . . . . . . . . . . . . . 176
16.2.1 Definindo e Iniciando uma Thread . . . . . . . . . . . . . 176
16.2.2 Pausando a execuc ao com sleep . . . . . . . . . . . . . . . 177
16.2.3 Interrupcoes . . . . . . . . . . . . . . . . . . . . . . . . . . 178
16.2.4 Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
16.2.5 Sincronizacao . . . . . . . . . . . . . . . . . . . . . . . . . 179
16.2.6 Executores e Thread Pools . . . . . . . . . . . . . . . . . 180
16.3 Streams e Serializacao . . . . . . . . . . . . . . . . . . . . . . . . 181
16.3.1 I/O Streams . . . . . . . . . . . . . . . . . . . . . . . . . 181
16.3.2 Serializac
ao - Streams de Objetos . . . . . . . . . . . . . . 183
16.4 Classes e Operacoes de I/O . . . . . . . . . . . . . . . . . . . . . 185
16.5 Classes para manipulac ao de propriedades . . . . . . . . . . . . . 185
17 Colec
oes 188
17.1 Interface Collection . . . . . . . . . . . . . . . . . . . . . . . . . . 189
17.2 Interface Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
17.3 Interface List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
17.4 Interface Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
17.5 Interface Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
18 JDBC - Java Database Connectivity 199

18.1 Conceitos Basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
18.2 Carregamento de drivers . . . . . . . . . . . . . . . . . . . . . . . 200
18.3 Conexao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
18.4 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
18.5 Prepared Statements . . . . . . . . . . . . . . . . . . . . . . . . . 203

18.6 Transac
ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
18.7 Informac
oes Complementares . . . . . . . . . . . . . . . . . . . . 204
18.8 Exemplo Extra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
19 A plataforma J2EE 207

19.1 Containers J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
19.2 Clientes J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
19.3 Um pouco mais sobre Servlets . . . . . . . . . . . . . . . . . . . . 209
19.3.1 Ciclo de Vida dos Servlets . . . . . . . . . . . . . . . . . . 211
19.3.2 Mantendo o estado do cliente . . . . . . . . . . . . . . . . 212
5
19.4 Um pouco mais sobre p aginas JSP . . . . . . . . . . . . . . . . . 213

19.4.1 JSP vs. Servlets . . . . . . . . . . . . . . . . . . . . . . . 215
19.5 Um pouco mais sobre EJBs . . . . . . . . . . . . . . . . . . . . . 216
19.5.1 Ciclo de Vida dos EJBs . . . . . . . . . . . . . . . . . . . 217
V Desenvolvimento Web 220

20 Usabilidade 221
20.1 Definic
ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
20.2 Princpios da usabilidade . . . . . . . . . . . . . . . . . . . . . . . 222
20.3 Tecnicas de avaliac
ao de usabilidade . . . . . . . . . . . . . . . . 223
21 Acessibilidade 224
21.1 Definic
ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
21.2 Princpios da acessibilidade . . . . . . . . . . . . . . . . . . . . . 224
21.3 Tecnicas de avaliac
ao de acessibilidade . . . . . . . . . . . . . . . 227
22 Padr
oes Web W3C 229
23 XML 233
23.1 O que e XML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
23.2 Caractersticas do XML . . . . . . . . . . . . . . . . . . . . . . . 234
23.3 Comparac ao entre XML e HTML . . . . . . . . . . . . . . . . . . 234
23.4 Sintaxe basica do XML . . . . . . . . . . . . . . . . . . . . . . . 234
23.5 Conjunto de tags . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
23.6 NameSpaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
23.7 Gram atica de um documento XML . . . . . . . . . . . . . . . . 239
23.8 Tecnologias XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
23.9 Benefcios da linguagem XML . . . . . . . . . . . . . . . . . . . . 245
23.10Ferramentas de desenvolvimento . . . . . . . . . . . . . . . . . . 246
24 XSLT 247
24.1 O que e uma folha de estilo? . . . . . . . . . . . . . . . . . . . . 247
24.2 Comparac ao entre o CSS e XSL . . . . . . . . . . . . . . . . . . . 247
24.3 O que e o XSL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
24.4 O que e o XSLT? . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
24.5 Caractersticas do XSLT . . . . . . . . . . . . . . . . . . . . . . . 249
24.6 Declarando um documento XSL . . . . . . . . . . . . . . . . . . . 249
24.7 Elemento <xsl:template> . . . . . . . . . . . . . . . . . . . . . . 250
24.8 Elemento <xsl:value-of> . . . . . . . . . . . . . . . . . . . . . . . 251

24.9 Elemento <xsl:for-each> . . . . . . . . . . . . . . . . . . . . . . . 252
24.10Elemento <xsl:sort> . . . . . . . . . . . . . . . . . . . . . . . . . 252
24.11Elemento <xsl:if> . . . . . . . . . . . . . . . . . . . . . . . . . . 252
24.12Elemento <xsl:choose> . . . . . . . . . . . . . . . . . . . . . . . 253
24.13Elemento <xsl:apply-templates> . . . . . . . . . . . . . . . . . . 253
24.14XSL no lado Cliente . . . . . . . . . . . . . . . . . . . . . . . . . 254
24.15XSL no lado Servidor . . . . . . . . . . . . . . . . . . . . . . . . 254
24.16Processadores XSLT . . . . . . . . . . . . . . . . . . . . . . . . . 255
6
25 Gerenciador de Conte udo Web Zone/Plone 256

25.1 Gestao de Conteudo . . . . . . . . . . . . . . . . . . . . . . . . . 256
25.2 Sistema de Gestao de Conte udo . . . . . . . . . . . . . . . . . . . 257
25.3 Zope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
25.4 Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
26 Web Services 263

26.1 O que e Web Services? . . . . . . . . . . . . . . . . . . . . . . . . 263
26.2 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
26.3 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
26.4 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
26.5 Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
VI Redes de Comunicac
ao 270
27 Tecnicas B asicas de Comunica c
ao 271
27.1 Base Te orica da Comunicac ao de Dados . . . . . . . . . . . . . . 271
27.2 Taxa M axima de Dados em um Canal . . . . . . . . . . . . . . . 272
27.3 Sinais Digitais Binarios . . . . . . . . . . . . . . . . . . . . . . . 272
27.4 Transmiss ao em Banda Base . . . . . . . . . . . . . . . . . . . . . 273
27.5 Classificac
ao dos Sinais . . . . . . . . . . . . . . . . . . . . . . . . 273
27.6 Tecnicas de Codificac
ao de Linha . . . . . . . . . . . . . . . . . . 274
27.6.1 Codificacao NRZ . . . . . . . . . . . . . . . . . . . . . . . 274
27.6.2 Codificacao RZ . . . . . . . . . . . . . . . . . . . . . . . . 275
27.6.3 Codificacao AMI (Alternate Mark Invertion) . . . . . . . 275
27.6.4 Codificacao HDB-3 (High Density Bipolar with 3 Zero
Maximum Tolerance) . . . . . . . . . . . . . . . . . . . . 275
27.6.5 Codificacao Manchester . . . . . . . . . . . . . . . . . . . 276
27.7 Modulac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
27.7.1 Modulac ao de Onda Contnua . . . . . . . . . . . . . . . . 277
27.7.2 Modulac ao de Pulsos . . . . . . . . . . . . . . . . . . . . . 279
27.8 Tecnicas de Multiplexac ao . . . . . . . . . . . . . . . . . . . . . . 280
27.8.1 FDM - Frequency Division Multiplexing . . . . . . . . . . 281
27.8.2 TDM - Time Division Multiplexing . . . . . . . . . . . . . 281
27.8.3 OFDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
27.8.4 WDM -Wavelength Division Multiplexing . . . . . . . . . 282
27.9 Protocolos de Acesso M ultiplo . . . . . . . . . . . . . . . . . . . . 283
28 Topologias de Redes 284
29 Arquitetura de Redes 286

29.1 Organizac
ao em Camadas . . . . . . . . . . . . . . . . . . . . . . 286
30 Protocolos de Rede 287

30.1 ARP - Address Resolution Protocol . . . . . . . . . . . . . . . . 287
30.2 DHCP - Dynamic Host Configuration Protocol . . . . . . . . . . 287
30.3 DNS - Domain Name System . . . . . . . . . . . . . . . . . . . . 289
30.4 TCP - Transmission Control Protocol . . . . . . . . . . . . . . . 291
30.5 UDP - User Datagram Protocol . . . . . . . . . . . . . . . . . . . 293
7
30.6 HTTP - Hyper Text Transfer Protocol . . . . . . . . . . . . . . . 294

30.7 SMTP - Simple Mail Transfer Protocol . . . . . . . . . . . . . . . 299
30.8 POP3 - Post Office Protocol Version 3 . . . . . . . . . . . . . . . 301
30.9 IMAP - Internet Mail Access Protocol . . . . . . . . . . . . . . . 303
30.10LDAP - LightWeight Directory Access Protocol . . . . . . . . . . 305
30.11SNMP - Simple Network Management Protocol . . . . . . . . . . 305
30.12FTP - File Transfer Protocol . . . . . . . . . . . . . . . . . . . . 306
30.13IP - Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . 310
30.14TELNET - TELetype NETwork . . . . . . . . . . . . . . . . . . 311
31 O Modelo de Refer
encia OSI 314
32 Roteamento 316
32.1 Link State e Distance Vector . . . . . . . . . . . . . . . . . . . . 317
32.1.1 Vetor de Dist
ancias vs. Estado do Link . . . . . . . . . . 319
32.2 Protocolos de Roteamento . . . . . . . . . . . . . . . . . . . . . . 320
32.2.1 RIP - Routing Information Protocol . . . . . . . . . . . . 320
32.2.2 OSPF - Open Shortest Path First . . . . . . . . . . . . . 320
32.2.3 IGRP e EIGRP . . . . . . . . . . . . . . . . . . . . . . . . 321
33 Redes Ethernet 322

33.1 Protocolo CSMA/CD . . . . . . . . . . . . . . . . . . . . . . . . 322
33.2 Fast Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
33.3 Gigabit Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
34 Cabeamento Estruturado 326

34.1 Par Trancado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
34.1.1 Interferencias nos Cabos de Par Trancado . . . . . . . . . 326
34.2 Categorias 5e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
34.3 Categoria 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
34.4 Categoria 5e vs. Categoria 6 . . . . . . . . . . . . . . . . . . . . 328
34.5 Cabeac
ao Estruturada Norma EIA/TIA 568 . . . . . . . . . . . 329
34.5.1 Sistemas de Cabeamento Estruturado . . . . . . . . . . . 329
34.6 Desempenho do Hardware e Meios de Transmiss ao . . . . . . . . 333
34.6.1 Cabeamento UTP . . . . . . . . . . . . . . . . . . . . . . 334

34.6.2 Fibra Optica . . . . . . . . . . . . . . . . . . . . . . . . . 335
34.7 C
odigo de Cores para Sistemas de Cabec ao UTP . . . . . . . . . 336
35 Redes sem fio 337

35.1 O padrao IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 337
35.1.1 CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . 338

35.1.2 Formato do Quadro 802.11 . . . . . . . . . . . . . . . . . 339
36 Elementos de Interconex ao de Redes de Computadores 340

36.1 Repetidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
36.2 Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
36.3 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
36.4 Bridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
36.5 Roteadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
36.6 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
8
37 Redes Multimdia 344

37.1 Qualidade de Servico . . . . . . . . . . . . . . . . . . . . . . . . . 344
37.2 Servicos Integrados - IntServ . . . . . . . . . . . . . . . . . . . . 346
37.3 Servicos Diferenciados - DiffServ . . . . . . . . . . . . . . . . . . 347
38 Redes X.25 e Frame Relay 348

38.1 X.25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
38.2 Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
38.2.1 Estrutura do Frame . . . . . . . . . . . . . . . . . . . . . 349
38.2.2 Envio de um datagrama IP de Ethernet para Frame Relay
e Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
38.3 Interligac
ao de Redes LAN . . . . . . . . . . . . . . . . . . . . . 351
38.3.1 Voz sobre Frame Relay (VoFR) . . . . . . . . . . . . . . . 351
38.3.2 Interacao entre Frame Relay e ATM . . . . . . . . . . . . 352
38.3.3 CIR (Taxa de Informac ao Comprometida) . . . . . . . . . 352
39 Redes Virtuais Locais 354

39.1 VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
39.1.1 Definic
ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
39.1.2 Protocolo 802.1q . . . . . . . . . . . . . . . . . . . . . . . 354
40 Redes de Circuito Virtuais 356

40.1 Redes ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
40.2 MPLS - Multiprotocol Label Switching . . . . . . . . . . . . . . . 358
41 Arquitetura TCP/IP 360

41.1 Vis
ao geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
41.2 Comparacao entre a arquitetura OSI e TCP/IP . . . . . . . . . . 360
41.3 Camada Fsica (host/rede) . . . . . . . . . . . . . . . . . . . . . 361
41.4 Camada de Inter-Rede . . . . . . . . . . . . . . . . . . . . . . . . 361
41.5 Camada de Transporte . . . . . . . . . . . . . . . . . . . . . . . . 362
41.6 Camada de Aplicacao . . . . . . . . . . . . . . . . . . . . . . . . 362
42 Camada de Aplica c
ao 364
42.1 Proxy Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
VII Ger
encia de Redes 366
43 O protocolo SNMP 367
43.1 Management Information Base . . . . . . . . . . . . . . . . . . . 368
VIII Seguran
ca da Informac
ao 370
44 Polticas de Seguran ca de Informa c
ao 371
44.1 Polticas de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . 371
44.2 Projeto de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . 372
44.3 Plano de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . 372
44.4 Normas de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . 373
44.4.1 ISO/IEC 17799 . . . . . . . . . . . . . . . . . . . . . . . . 373
9
44.4.2 Famlia ISO 27000 . . . . . . . . . . . . . . . . . . . . . . 375

44.4.3 Diferencas entre a ISO/IEC 17799 e a ISO 27001 . . . . . 376
44.5 Procedimentos de Seguranca . . . . . . . . . . . . . . . . . . . . . 376
44.6 Arquitetura de Seguranca . . . . . . . . . . . . . . . . . . . . . . 377
44.7 Classificac
ao de Informac
oes . . . . . . . . . . . . . . . . . . . . . 377
45 Seguran ca Fsica e Logica 379

45.1 Seguranca Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
45.2 Seguranca Logica . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
45.2.1 Matrizes de acesso, listas de controle de acesso e capabilities379
45.2.2 Modelos de Controle de Acesso . . . . . . . . . . . . . . . 380
46 Backup de Dados 384

46.1 Meios de Armazenamento . . . . . . . . . . . . . . . . . . . . . . 384
47 Vrus e Ataques 386

47.1 Estrategias de combate `
a pragas eletr onicas . . . . . . . . . . . . 388
47.1.1 Antivrus . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
48 Princpios de Criptografia 390

48.1 Tipos de Criptografia . . . . . . . . . . . . . . . . . . . . . . . . 391
48.2 Algoritmos de Criptografia Simetricos . . . . . . . . . . . . . . . 392
48.3 Algoritmos de Criptografia Assimetricos . . . . . . . . . . . . . . 393
48.4 Tecnicas de Quebra de Criptografia . . . . . . . . . . . . . . . . . 394
49 Autentica cao 395

49.1 Autenticac
ao de Mensagens . . . . . . . . . . . . . . . . . . . . . 395
49.2 Protocolos de Autenticacao . . . . . . . . . . . . . . . . . . . . . 396
49.2.1 Metodos de Autenticac ao . . . . . . . . . . . . . . . . . . 396
49.2.2 Autenticac
ao baseada em uma chave secreta compartilhada396
49.3 Certificado Digital . . . . . . . . . . . . . . . . . . . . . . . . . . 397
50 Seguran ca em diversas camadas 399

50.1 Secure Sockets Layer . . . . . . . . . . . . . . . . . . . . . . . . . 399
50.2 IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
50.3 Virtual Private Network (VPN) . . . . . . . . . . . . . . . . . . . 401
50.4 Filtragem de Pacotes e Firewalls . . . . . . . . . . . . . . . . . . 403
50.4.1 Regras iptables - Exemplo 1 . . . . . . . . . . . . . . . . . 405
50.4.2 Regras iptables - Exemplo 2 . . . . . . . . . . . . . . . . . 405
50.4.3 Firewall Stateful . . . . . . . . . . . . . . . . . . . . . . . 406
50.4.4 Application Gateway . . . . . . . . . . . . . . . . . . . . . 407

50.4.5 Arquitetura de firewall e DMZ . . . . . . . . . . . . . . . 407
50.5 Sistemas de Detecc ao de Intrusao (IDS) . . . . . . . . . . . . . . 409
50.6 Seguranca em Redes Wireless 802.11 . . . . . . . . . . . . . . . . 409
50.6.1 WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
50.7 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
10
IX Alta Disponibilidade 411

51 Soluc
oes de Armazenamento RAID, SAN e NAS 412
51.1 RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
51.1.1 RAID 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
51.1.2 RAID 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
51.1.3 RAID 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
51.1.4 RAID 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
51.1.5 RAID 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
51.1.6 RAID 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
51.1.7 RAID 6 (Redund ancia de P+Q) . . . . . . . . . . . . . . 419
51.1.8 Tipos Hbridos . . . . . . . . . . . . . . . . . . . . . . . . 419
51.1.9 Comparativo de Desempenho entre as diversas configurac oes
RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
51.2 SAN - Storage Area Network . . . . . . . . . . . . . . . . . . . . 420
51.2.1 Hardware para SAN . . . . . . . . . . . . . . . . . . . . . 421
51.2.2 Topologias de SAN . . . . . . . . . . . . . . . . . . . . . . 422
51.3 NAS - Network Attached Stotage . . . . . . . . . . . . . . . . . . 423
51.4 Comparativo entre SAN e NAS . . . . . . . . . . . . . . . . . . . 424
52 Clusters de servidores 427

52.0.1 Princpios de um Cluster . . . . . . . . . . . . . . . . . . 427
52.0.2 Abstracoes em um Cluster . . . . . . . . . . . . . . . . . . 428
52.0.3 Arquitetura de um Cluster . . . . . . . . . . . . . . . . . 429
52.0.4 Cluster X Sistemas Distribudos . . . . . . . . . . . . . . 430
52.0.5 Cluster de Alta Disponibilidade . . . . . . . . . . . . . . . 431
52.0.6 Cluster de Alto Desempenho . . . . . . . . . . . . . . . . 433
53 Balanceamento de Carga 436

53.1 Balanceamento de armazenamento (storage) . . . . . . . . . . . . 436
53.2 Balanceamento de rede . . . . . . . . . . . . . . . . . . . . . . . . 436
53.2.1 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
53.2.2 IP Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . 437
53.2.3 Direct Routing . . . . . . . . . . . . . . . . . . . . . . . . 438
53.3 Algoritmos de balanceamento . . . . . . . . . . . . . . . . . . . . 438
53.4 Balanceamento de CPU . . . . . . . . . . . . . . . . . . . . . . . 439
53.4.1 Sistema de processamento distribudo . . . . . . . . . . . 439
X Sistemas Operacionais 442

54 Ambiente Microsoft Windows 2000/2003 443
54.1 DHCP - Dynamic Host Configuration Protocol . . . . . . . . . . 443
54.1.1 Processo de Instalac
ao/Configurac
ao . . . . . . . . . . . . 443
54.1.2 Integrac
ao do DHCP com o DNS . . . . . . . . . . . . . . 445
54.1.3 APIPA - Automatic Private IP Addressing . . . . . . . . 445
54.1.4 Comandos ipconfig Relacionados ao DHCP . . . . . . . . 446
54.1.5 Regra 80/20 . . . . . . . . . . . . . . . . . . . . . . . . 446
54.2 DNS - Domain Name System . . . . . . . . . . . . . . . . . . . . 446
ao/Configurac
ao . . . . . . . . . . . . 447
11
54.2.2 Seguranca de Acesso . . . . . . . . . . . . . . . . . . . . . 449

54.2.3 Integracao do DNS com o Active Directory . . . . . . . . 449
54.2.4 Servidor DNS somente Cache . . . . . . . . . . . . . . . . 451
54.2.5 Arquivo Hosts . . . . . . . . . . . . . . . . . . . . . . . . 451
54.2.6 Distribuicao de Carga . . . . . . . . . . . . . . . . . . . . 451
54.2.7 Comando ipconfig/dnscmd Relacionadas ao DNS . . . . . 451
54.3 Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
54.3.1 Tipos de Servidores . . . . . . . . . . . . . . . . . . . . . 453
54.3.2 Definic
oes de Floresta, Domnio, Site e Unidade Organi-
zacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
54.3.3 Recursos do Active Directory . . . . . . . . . . . . . . . . 454
54.3.4 Seguranca com o Active Directory . . . . . . . . . . . . . 455
54.3.5 Ferramentas de Controle . . . . . . . . . . . . . . . . . . . 456
54.4 IIS - Internet Information Services . . . . . . . . . . . . . . . . . 456
54.4.1 IIS versus Apache HTTP Server . . . . . . . . . . . . . . 456
54.4.2 Principais Componentes do IIS . . . . . . . . . . . . . . . 459
54.4.3 Principais Recursos do IIS . . . . . . . . . . . . . . . . . . 460
54.4.4 Principais Diferencas entre IIS4, IIS5 e IIS6 . . . . . . . . 461
54.5 Terminal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
54.5.1 Principais Benefcios . . . . . . . . . . . . . . . . . . . . . 462
54.5.2 Protocolos de Comunicac ao . . . . . . . . . . . . . . . . . 463
54.5.3 Licencas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
XI Banco de Dados 465

55 Conceitos B
asicos 466
56 Abordagem Relacional 468

56.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
56.2 Esquemas e Restric
oes de Integridade . . . . . . . . . . . . . . . 468
57 Modelagem Entidade Relacionamento 470

57.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
57.2 Cardinalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
57.3 Representac
ao Gr
afica . . . . . . . . . . . . . . . . . . . . . . . . 471
57.4 Recursos do Modelo Entidade Relacionamento . . . . . . . . . . 471
58 Normaliza c
ao 473
58.1 Aspectos desej
aveis em um bom projeto . . . . . . . . . . . . . . 473
58.2 Forma normal de Boyce-Codd . . . . . . . . . . . . . . . . . . . . 473

58.3 Terceira forma normal . . . . . . . . . . . . . . . . . . . . . . . . 474
59 Transforma
cao do Modelo Conceitual 475
60 Linguagem SQL 476

60.1 Criac
ao de tabela . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
60.2 Consultas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
60.3 Funcoes de agregac
ao . . . . . . . . . . . . . . . . . . . . . . . . . 477
60.4 Atualizacoes e exclus
oes . . . . . . . . . . . . . . . . . . . . . . . 478
60.5 Vis
oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
12
60.6 Chaves estrangeiras . . . . . . . . . . . . . . . . . . . . . . . . . . 479
61 Conceitos de Datawarehousing e Bussiness Inteligence 480

61.1 Banco de Dados Multidimensionais . . . . . . . . . . . . . . . . . 480
61.1.1 Modelagem Multidimensional . . . . . . . . . . . . . . . . 481
61.2 Datawarehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
61.3 OLTP, OLAP, MOLAP, ROLAP e HOLAP . . . . . . . . . . . . 485
61.4 Outros conceitos importantes . . . . . . . . . . . . . . . . . . . . 487
XII Administra
cao de Bancos de Dados Relacionais 489
62 Ger
encia de Transa
coes 490
63 Controle de Concorr
encia 492
64 Ger
encia de Desempenho 494
XIII Oracle e Microsoft SQL Server 497

65 Administra c
ao de Bancos de Dados Oracle 498
65.1 Arquitetura de um Servidor Oracle . . . . . . . . . . . . . . . . . 498
65.1.1 Estruturas em mem oria . . . . . . . . . . . . . . . . . . . 498
65.1.2 Processos server . . . . . . . . . . . . . . . . . . . . . . . 499
65.1.3 Processos user . . . . . . . . . . . . . . . . . . . . . . . . 499
65.1.4 Processos em Background . . . . . . . . . . . . . . . . . . 499
65.1.5 Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
65.2 Arquitetura Oracle de Armazenamento de Dados . . . . . . . . . 501
65.3 Tratamento de Transac oes no Oracle . . . . . . . . . . . . . . . . 501
65.3.1 Gerenciamento do Redo Log . . . . . . . . . . . . . . . . . 501
65.3.2 Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . 502
65.3.3 Segmentos de rollback . . . . . . . . . . . . . . . . . . . . 502
65.3.4 Consistencia de leitura . . . . . . . . . . . . . . . . . . . . 503
65.4 Configurac
ao do Servidor . . . . . . . . . . . . . . . . . . . . . . 503
65.5 Tipos de Usuarios Oracle . . . . . . . . . . . . . . . . . . . . . . 504
65.5.1 Administradores de banco de dados . . . . . . . . . . . . 504
65.5.2 Outros papeis . . . . . . . . . . . . . . . . . . . . . . . . . 505
66 Administra c
ao de Bancos de Dados SQL Server 506
66.1 Arquitetura de um Servidor SQL Server . . . . . . . . . . . . . . 506

66.1.1 Cat
alogos de sistema . . . . . . . . . . . . . . . . . . . . . 506
66.1.2 Processos em background . . . . . . . . . . . . . . . . . . 507
66.2 Arquitetura SQL Server de Armazenamento de Dados . . . . . . 507
66.3 Tratamento de Transacoes no SQL Server . . . . . . . . . . . . . 507
XIV ITIL 509

67 Suporte a Servi cos 510
67.1 Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
13
67.1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

67.1.2 Responsabilidades . . . . . . . . . . . . . . . . . . . . . . 510
67.1.3 V
arios Tipos de Central . . . . . . . . . . . . . . . . . . . 511
67.2 Gerenciamento de Incidentes . . . . . . . . . . . . . . . . . . . . 511
67.2.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
67.2.2 Atividades do Processo . . . . . . . . . . . . . . . . . . . 511
67.2.3 Papeis e Responsabilidades . . . . . . . . . . . . . . . . . 512
67.3 Gerenciamento de Problemas . . . . . . . . . . . . . . . . . . . . 512
67.3.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
67.3.2 Definic
oes Importantes . . . . . . . . . . . . . . . . . . . . 513
67.4 Gerenciamento de Configurac ao . . . . . . . . . . . . . . . . . . . 514
67.4.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
67.4.2 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
67.5 Gerenciamento de Mudancas . . . . . . . . . . . . . . . . . . . . 515
67.5.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
67.5.3 Definic
oes Importantes . . . . . . . . . . . . . . . . . . . . 515
67.6 Gerenciamento de Liberac ao . . . . . . . . . . . . . . . . . . . . . 516
67.6.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
67.6.3 Definic
oes Importantes . . . . . . . . . . . . . . . . . . . . 517
68 Entrega de Servi cos 518

68.1 Gerenciamento do Nvel de Servico . . . . . . . . . . . . . . . . . 518
68.1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
68.2 Gerenciamento Financeiro . . . . . . . . . . . . . . . . . . . . . . 519
68.2.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
68.2.4 Elementos de Custo . . . . . . . . . . . . . . . . . . . . . 520
68.3 Gerenciamento da Capacidade . . . . . . . . . . . . . . . . . . . 521
68.3.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
68.3.2 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
68.4 Gerenciamento de Disponibilidade . . . . . . . . . . . . . . . . . 522
68.4.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
68.4.2 Ciclo de vida do incidente . . . . . . . . . . . . . . . . . . 522

68.5 Gerenciamento de Continuidade . . . . . . . . . . . . . . . . . . . 523
68.5.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
68.5.2 Est
agios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
68.5.3 Tipos de Continuidade . . . . . . . . . . . . . . . . . . . . 524
XV Ger
encia de Projetos segundo PMBOK 525
69 Gerenciamento de Escopo 526
69.1 WBS e Definic
ao do Escopo . . . . . . . . . . . . . . . . . . . . . 526
14
70 Gerenciamento de Recursos Humanos 528

70.1 Estruturas Organizacionais . . . . . . . . . . . . . . . . . . . . . 528
70.1.1 Organizac
ao Funcional . . . . . . . . . . . . . . . . . . . . 528
70.1.2 Organizac
ao por Projeto . . . . . . . . . . . . . . . . . . . 529
70.1.3 Organizac
ao Matricial . . . . . . . . . . . . . . . . . . . . 530
70.2 Planejamento Organizacional . . . . . . . . . . . . . . . . . . . . 531
70.3 Desenvolvimento da Equipe . . . . . . . . . . . . . . . . . . . . . 531
71 Gerenciamento do Tempo 534

71.1 Tecnicas de Desenvolvimento do Cronograma . . . . . . . . . . . 534
71.1.1 An alise Matem atica . . . . . . . . . . . . . . . . . . . . . 535
71.1.2 Compress ao do Cronograma . . . . . . . . . . . . . . . . . 535
71.1.3 Simulac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
71.1.4 Heurstica do nivelamento de recursos . . . . . . . . . . . 536
71.1.5 Estrutura de Codificac ao . . . . . . . . . . . . . . . . . . 536
72 Gerenciamento de Custo 537

72.1 Tecnicas de Estimativas de Custos . . . . . . . . . . . . . . . . . 537
72.1.1 Estimativas An alogas . . . . . . . . . . . . . . . . . . . . 537
72.1.2 Modelagem Parametrica . . . . . . . . . . . . . . . . . . . 538
72.1.3 Estimativa bottom-up . . . . . . . . . . . . . . . . . . . . 538
73 Gerenciamento de Riscos 539

73.1 An
alise Qualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . 539
73.2 An
alise Quantitativa de Riscos . . . . . . . . . . . . . . . . . . . 540
74 Gerenciamento de Qualidade 542

74.1 Tecnicas de Planejamento da Qualidade . . . . . . . . . . . . . . 542
74.1.1 An alise Custo/Benefcio . . . . . . . . . . . . . . . . . . . 542
74.1.2 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . 543
74.1.3 Fluxograma . . . . . . . . . . . . . . . . . . . . . . . . . . 543
74.1.4 Elaboracao de Experimentos . . . . . . . . . . . . . . . . 543
74.1.5 Custo da Qualidade . . . . . . . . . . . . . . . . . . . . . 544
74.2 Tecnicas de Controle da Qualidade . . . . . . . . . . . . . . . . . 544
74.2.1 Graficos de Controle . . . . . . . . . . . . . . . . . . . . . 545
74.2.2 Diagramas de Pareto . . . . . . . . . . . . . . . . . . . . . 545
74.2.3 Diagramas de Dispers ao . . . . . . . . . . . . . . . . . . . 546
75 Gerenciamento da Comunica c
ao 547
75.1 Um mais sobre Planejamento da Comunicac
ao . . . . . . . . . . 547
76 Gerenciamento das Aquisi c

oes 548
76.1 Um pouco mais sobre Planejamento de Aquisic
oes . . . . . . . . 548
77 Gerenciamento da Integra c
ao 550
77.1 Ferramentas de Apoio `
a Integrac
ao . . . . . . . . . . . . . . . . . 550
78 Sobre os Ciclos do Projeto e Processos de Gerenciamento 551
15
Parte I
Fundamentos de
Computa
c
ao
16
Captulo 1
Arquitetura e Organiza
cao
de Computadores
1.1 Conceitos B
asicos
Dois conceitos fundamentais no estudo dos sistemas de computac ao sao o de
Arquitetura e Organizacao de computadores. O termo arquitetura refere-se aos
atributos do ponto de vista do programador, e portanto, tem impacto direto
sobre sobre a execuc
ao l
ogica de um programa. O termo organizacao, refere-se
as unidades operacionais e suas interconex
` oes. Desta forma, uma mesma ar-
quitetura pode ser implementadas por meio de diferentes organizac
oes.
As funcoes basicas de um computador sao o processamento de dados, ar-

mazenamento de dados, transferencia de dados e controle. Para desempenhar
essas func
oes o computador precisa executar um conjunto de instruc oes (pro-
grama). Os computadores que conhecemos s ao baseados no conceito de pro-
grama armazenado, introduzido por Von-Neuman. As instruc oes do programa
e os dados s ao armazenados em uma mem oria, de forma que a alterac
ao de um
programa consiste na alteracao de um endereco de memoria.
O ciclo de execuc
ao de cada uma das instruc oes de um programa e divi-
dido nos seguintes estados: (i)Calculo do Endereco de Instruc ao; (ii)Busca da
Instruc
ao (Instruction Fetch); (iii) Decodificac
ao da Instruc
ao; (iv)Calculo do
Endereco do Operando; (v)Busca do Operando (Operand Fetch); (vi)Execuc ao
da Operacao; (vii)Armazenamento do Resultado. No entanto, os computadores

modernos utilizam o conceito de interrupc ao para diminuir o tempo de ociosi-
dade dos processadores, o ciclo de execuc
ao das instruc
oes ganham mais alguns
estados. As classes de interrupcoes mais comuns s ao interrupc
oes de software,
de rel
ogio, de E/S e de falha de hardware.
A estrutura b
asica de um computador e composta pelos seguintes compo-
nentes:
(i)Unidade Central de Processamento(CPU);

(ii)Mem
oria Principal;
17
(iii)Dispositivos de E/S;
(iv)Sistemas de Interconex
ao.
Esses componentes tambem possuem suas subdivis oes. A CPU por exemplo
se subdivide em: Unidade de Controle, Unidade L ogica e Aritmetica (ALU),
Registradores e por fim as Interconexoes da CPU. Cada um desses componentes
er
a melhor descrito posteriormente. Para interconectar dois ou mais dispositivos
em um sistema s ao utilizados os chamados barramentos. Os barramentos s ao
compostos por linhas que podem ser de Dados, Endereco ou Controle. Os
barramentos de controle podem ser utilizados por exemplo para controlar direito
de leitura ou escrita em mem oria ou E/S, interrupc
oes, confirmac
oes, rel
ogio
e reset. O projeto dos barramentos que comp oe um sistema s ao de grande
importancia no desempenho do sistema. Quest oes importantes no projeto de
barramentos sao:
(i)Tipo - dedicado ou multiplexado;
(ii)Metodo de Arbitracao - Centralizado ou Distribudo;

(iii)Temporizac
ao - Sncrona ou Assncrona;
(iv)Largura - n
umero de linhas;
(v) Tipo de Transferencia - leitura, escrita, leitura/modificac

ao/escrita,
escrita/leitura, em bloco.
Para aumentar o desempenho do sistema, os barramentos s ao organizados de

forma hierarquica, de forma isolar o tr
afego de dados entre CPU e mem oria do
tr
afego proveniente de operac
oes de E/S. Os chamados barramentos de expans ao
proporcionam maior flexibilidade ao sistema (ex: SCSI), enquanto os barramen-
tos de alta velocidade sao utilizados para dispositivos de alta capacidade (ex:
FireWire).
1.2 Estrutura e Funcionamento da CPU

Os principais elementos da CPU sao a Unidade de Controle , a Unidade L
ogica
e Aritmetica (ULA) e os Registradores. Esses elementos se conectam interna-
mente atraves do barramento interno da CPU.
A CPU se comunica com o mundo externo atraves dos barramentos do sis-

tema. Ao longo da execuc ao de um programa, os barramentos constituem os
chamados caminho dos dados. No topo da organizac ao hier
arquica de mem oria
em um sistema se encontram os registradores. Esses se dividem em dois tipos:
Registradores visveis ao Usu
ario e Registradores de Controle e de Estado.
Os registradores visveis ao usu

ario s
ao aqueles que podem ser referenciados
pela linguagem de montagem. Eles podem ser registradores de dados, endereco
ou entao de proposito geral. Os registradores de Controle e de Estado s ao uti-
lizados para controlar a operacao da CPU. Na maioria das vezes nao s
ao visveis
aos usuarios. Exemplos de registradores de Controle e de Estado s ao o Program
18
Counter (PC), Instruction Register (IR), Memory Address Register (MAR),

Memory Buffer Register (MBR), Program Status Word (PSW), Stack Pointer
(SI), Page Table Base Register (PTBR), Page Table Base Limit (PTBL).
A seq uencia de eventos ao longo de um ciclo de instruc

ao depende do projeto
da CPU, no entanto, em termos gerais, pode-se indicar o que acontece em nos
subciclos de busca, indireto e interrupc ao. O ciclo de execucao depende do
c
odigo da operac ao que sera executada. A figura 1.1 mostra o diagrama de
transic
ao de estados do ciclo de instruc
ao.
Figura 1.1: Transic

ao de Estados do Ciclo de Instruc
ao
Durante o ciclo de busca, o contador de programa contem o endereco da

proxima instruc
ao a ser buscada na mem oria. Esse endereco e movido para o
registrador MAR e a unidade de controle requisita uma leitura na mem oria. O
resultado da leitura e colocado no registrador MBR, que em seguida e copiado
para o registrador IR. Enquanto isso o PC e incrementado de 1 para preparar
a busca da pr oxima instruc
ao. O fluxo de dados do ciclo de busca e mostrado
na figura 1.2.
Ao fim do ciclo de busca, o unidade de controle examina se a instruc ao
especifica algum operando com enderecamento indireto. Os n bits mais a direita
de MBR s ao colocados em MAR, e ent ao a unidade de controle requisita uma
leitura a mem oria para carregar o valor do operando para MBR. O fluxo de
dados do ciclo de indireto e mostrado na figura 1.3.
No ciclo de interrupc
ao, o conteudo do registrador PC dever ser salvo, para
que mais tarde a CPU possa retornar sua atividade normal depois de processar
a interrupc
ao. O conte udo do PC e transferido para MBR. A endereco de
mem oria reservado para guardar o valor de PC (ex: topo da pilha) e carregado
para MAR, e ent ao a unidade de controle solicita uma escrita na mem oria. Por
fim o PC e carregado com o endereco da rotina de interrupc ao, para que o no
proximo ciclo de instruc
ao seja feita a busca da instruc
ao apropriada. A figura
1.4 mostra o fluxo de dados do ciclo de interrupc ao.
19
Figura 1.2: Fluxo de Dados do Ciclo de Busca
Figura 1.3: Fluxo de Dados do Ciclo de Indireto

Figura 1.4: Fluxo de Dados do Ciclo de Interrupc

ao
1.2.1 Pipelines
Como pudemos ver, um ciclo de instruc ao pode subdividido em etapas menores.
Uma divis ao comum e a baseada nos ciclos de busca, indireto, execucao e inter-
rupc
ao. A ideia da tecnica de pipeline e trabalhar as diversas etapas do ciclo
de instruc
ao de forma paralela, e n ao de forma serial, de forma aumentar o
20
desempenho da CPU.
A tecnica de pipeline pode ser descrita genericamente como uma estrategia

de aceitar novas entradas em uma extremidade sem que as entradas previas
tenha aparecido como sadas na outra extremidade. Imaginemos um esquema
em que o ciclo de instruc ao e subdividido em 2 etapas que s ao a busca da in-
struc
ao e a execuc
ao. Enquanto uma instruc ao est
a sendo executada, a pr oxima
instruc
ao pode estar sendo buscada. Este esquema configura um pipeline de 2
est
agios, e a tecnica utilizada e a de busca antecipada de instruc
ao (Instruction
Prefetch ou Fetch Overlap). Embora possa ser obtido um ganho de desempenho,
o pipeline de 2 estagios ainda e muito fraco para lidar com instrucoes de desvio,
nas quais a busca da pr oxima instruc
ao depende do resultado da execuc ao da
instruc
ao corrente.
Portanto, uma subdivisao do ciclo de instruc

ao em um n
umero maior de
est
agios pode proporcionar maior desempenho. Imaginemos o ciclo de instruc
ao
como sendo composto dos seguintes est agios:
(1)BI - Busca da Instruc

ao;
(2)DI - Decodificac
ao da Instruc
ao;
(3)CO - Calculo dos Enderecos dos Operandos;
(4)BO - Busca dos Operandos;

(5)EI - Execuc
ao da instruc
ao;
(6)EO - Escrita do Operando.
Essa subdivisao busca fazer com que os tempos gastos em cada um dos 6
est
agios seja parecido. Se os 6 est
agios pudessem ser executados em paralelo, o
desempenho seria aproximadamente 6 vezes maior.
No entanto, podem existir conflitos de acesso ` a mem oria por parte dos
estagios e nem todas as instrucoes possuem os seis est
agios. Somam-se à esses
dois problemas, a existencia de instrucoes de desvios, principais inimigas da
tecnica de pipeline. Para lidar com os problemas introduzidos pelas instrucoes
de desvio sao utilizadas tecnicas como:
M
ultiplos Fluxos (duplicac
ao de est
agios iniciais);
Busca Antecipada de Instruc

ao-Alvo de Desvio;
Mem
oria de Laco de Repetic
ao (loop buffer );
Previs
ao de Desvio baseadas no opcode;
Previs
ao de Desvio baseadas em hist
orico (BTB - Branch Target Buffer,
tambem conhecida como BHT - Branch History Table).
As figuras 1.5 e 1.6 mostram os diagramas de tempo para o pipeline de

instruc
oes com e sem instrucoes de desvio.
21
Figura 1.5: Diagrama do Tempo para Pipeline de Instruc

oes
Figura 1.6: Efeito do desvio condicional no Pipeline de Instruc

oes
1.3 Conjunto de Instru

coes
A operacao da CPU e determinada pelo conjunto de instrucoes que ela executa.
Sao as chamadas instruc
oes de maquina. A colec
ao de instruc
oes que uma CPU
pode executar e chamada Conjunto de Instruc oes. O conjunto de instruc oes
deve ser suficiente para traduzir programas escritos em uma linguagem de alto
nvel para a linguagem de m aquina. Os principais elementos e uma instruc ao
s
ao:
(i)C
odigo da operac
ao (opcode): especifica a operac
ao a ser efetuada;
(ii)Referencia `
a Operando Fonte: indica as entradas para a operac
ao;
(iii)Referencia ao operando Destino: A operac
ao pode produzir um resul-
tado;
(iv)Endereco da pr
oxima instruc
ao: Pode ser indicado implicitamente (ex:
registrador PC).
22
Os operandos fonte e destino podem estar localizados em memoria (principal

ou virtual), em algum registrador, ou em algum dispositivo de E/S.
Cada instrucao de um computador e representada internamente como um

conjunto de bits. A instruc ao e dividida em campos correspondentes aos ele-
mentos da instrucao. O papel da CPU e ler a instruc ao, extrair informacao de
cada um dos campos e efetuar a operac ao. Devido ` as dificuldades de se lidar
com a representacao binaria, e utilizada uma especie de notacao simbolica para
representar as instruc
oes de m aquina. Os codigos das operacoes s
ao representa-
dos por mnem onicos. (ex: ADD, SUB, MPY, DIV, LOAD, STOR). O mesmo
ocorre para os operandos. Um conjunto de instruc oes pode apresentar mais de
um formato de instruc ao.
As instruc
oes podem ser classificadas em:
(i)Processamento de Dados: instruc

oes l
ogicas e aritmeticas;
(ii)Armazenamento de dados: instruc

oes de mem
oria;
(iii)Movimentac
ao: instruc
oes de E/S;
(iv)Controle: instruc
oes de teste e desvio.
No projeto do conjunto de instruc oes as questoes mais relevantes sao o

repertorio de operac
oes, os tipos de dados, o formato e tamanho das instruc
oes,
os registradores acessveis, e os modos de enderecamento. As classes de dados
sobre as quais as instruc oes de maquina operam s ao enderecos, n
umeros (ex:
ponto fixo, ponto flutuante, decimal), caracteres (ex: ASCII e EBCDIC) e da-
dos l
ogicos.
Os tipos de operac
oes mais comuns s
ao:
(i)Transferencia de Dados: mov,push/pop,xlat,in/out;

(ii)Aritmeticas: add,sub,mul,idiv;
(iii)L
ogicas: and,or,shl/shr;
(iv)Convers
ao de Tipos: jmp,call,loop,int/into;
(vi)Controle do Sistema: hlt,wait;

(vii)Transferencia de Controle: blt,bgt,beq,call,jmp.
Nas operacoes de salto e desvio, e importante conhecer cada um dos c

odigos
de condic
ao envolvidos. (ex: Vai-Um, Zero, Paridade, Sinal, Overflow) Na im-
plementacao das chamadas de procedimento e importante ressaltar a utilizac
ao
de pilhas para permitir chamadas reentrantes (uma chamada dentro da outra).
23
1.4 Unidade de Controle

A unidade de controle coordena os diversos elementos do processador para que
este possa realizar todas as suas funcoes. A execuc
ao de um programa consiste
de uma seq uencia de ciclos de instruc
ao. Um ciclo de instrucao pode ser sub-
dividido em quatro subciclos que s ao busca, indireto, execuc
ao e interrupc
ao.
Somente os ciclos de busca e execuc ao est
ao presentes em todos os ciclos de
instruc
ao. Cada subciclo, por sua vez, e composto por microoperac oes.
Os quatro registradores b
asicos da unidade de controle s
ao:
PC (Program Counter ): Mantem o endereco da pr

oxima instruc
ao a ser
buscada na mem
oria;
MAR (Memory Address Register ): Especifica endereco de memoria para
uma operac
ao de leitura ou escrita;
MBR (Memory Buffer Register ): Conectado ao barramento do sistema.
Contem um valor a ser armazenado na mem
oria ou o u
ltimo valor dela
lido;
IR (Instruction Register ): Mantem a u
ltima instruc
ao buscada na mem
oria.
O ciclo de busca ocorre no incio de cada ciclo de instruc ao, fazendo com
que a instruc
ao seja obtida na mem oria no endereco indicado pelo registrador
PC, e armazenada no registrador IR. Uma vez completada essa etapa, pode ser
necess
ario que se busquem operandos para a instruc ao. Isso e realizado no ciclo
de indireto. Ap os o termino do ciclo de execuc ao, e feita uma checagem para
determinar se ocorreu alguma interrupc ao, e neste caso o conte udo de PC e
salvo em mem oria e PC e carregado com um endereco da rotina de interrupc ao
apropriada. Os ciclos de busca, indireto e de interrupc ao envolvem um n umero
pequeno e fixo de microoperac oes. Isso nao ocorre nos ciclos de execucao. Em
uma m aquina com N c odigos de instruc
ao podem existir N diferentes seq uencias
de microoperacoes para o ciclo de execucao.
Todas as microoperac
oes caem em uma das seguintes categorias:
(i)Transferencia de dados entre registradores;

(ii)Transferencia de dados entre registrador e interface externa (barra-
mento);
(iii)Transferencia de dados de interface externa para registrador;
(iv)Execuc
ao de operac
oes l
ogicas e aritmeticas, usando registradores como
entrada e sada.
Portanto, a unidade de controle desempenha duas tarefas b asicas que s

ao o
sequenciamento e a execuc
ao das microoperac
oes. A base para o funcionamento
da unidade de controle sao os sinais de controle, que constituem as entradas e
sadas.
24
As unidades de controle podem ser implementadas tanto em hardware quanto

em software (Microprogramac ao). A implementac ao baseada em micropro-
gramac
ao e mais simples e tambem mais barata do que as implementac oes em
hardware. As implementac oes em hardware envolvem a criac ao de uma l
ogica
complexa para sequenciamento das microoperac oes, o que a torna mais cara.
No entanto, e mais eficiente dos que as implementac oes basadas em micropro-
gramac
ao. As arquiteturas CISC geralmente utilizam unidades de controle mi-
croprogramadas, devido ao grande n umero de instrucoes e sua complexidade. J
a
as arquiteturas RISC, geralmente utilizam implementac oes baseadas em hard-
ware uma vez que o n umero de instruc
oes e reduzido e de baixa complexidade.
As tecnicas de microprogramac ao tambem podem ser aplicadas em em-

ulac
oes, permitindo que maquinas rodem programas escritos originalmente para
outras m aquinas. Microprogramas podem conferir maior desempenho ao sis-
tema operacional se forem utilizados na implementac ao de certas primitivas.
Alem disso, as tecnicas de microprogramacao podem ser utilizadas na imple-
mentacao de dispositivos de prop
osito especial, por exemplo uma placa de rede
(firmware).
1.5 Modos de Endere

camento
Os modos de enderecamento est ao relacionados com a forma utilizada para
especificar o valor ou endereco de um operando de uma instruc ao. Questoes im-
portantes na escolha do modo de enderecamento s ao a quantidade de posic
oes de
mem oria enderecaveis, flexibilidade de enderecamento, numero de referencias a
mem oria feitas pela instrucao e complexidade do calculo do endereco. Em geral,
as arquitetura n ao oferecem s o um modo de enderecamento, mas sim um con-
junto de modos. Por este motivo, e necess ario que exista uma forma de se
identificar qual o modo de enderecamento que se est a utilizando. Isso e feito
atraves do campo de modo de enderecamento, que consiste em um subconjunto
dos bits de uma instruc ao.
Imediato: o valor do operando e especificado diretamente na instruc

ao.
Sua principal vantagem e n
ao requer acesso a mem oria para obter o
operando. A desvantagem e que esse modo imp oe uma limitac
ao no
tamanho do operando;
Direto: o campo de endereco contem o endereco efetivo do operando na

mem oria. Requer portanto apenas um acesso para determinar o valor do

operando. Sua limitac
ao e fornecer um espaco de enderecamento limitado;
Indireto: o campo de endereco aponta para uma posicao de mem oria que
contem o endereco de mem oria do operando. Sua principal desvantagem
e a necessidade de dois acessos ` a memoria. A vantagem em relac ao ao
modo de enderecamento direto e o aumento do espaco de enderecamento,
que passa a ser igual 2n onde n e o tamanho da palavra;
Registrador : e semelhante ao modo direto, no entanto o modo de endereco

se refere a um registrador e nao `
a uma posic
ao de memoria. Geralmente e
25
composto por 3 ou 4 bits, o que permite referenciar de 8 a 16 registradores

de proposito geral. Suas vantagens s
ao o tamanho pequeno do campo de
endereco e n
ao necessidade de se acessar a mem oria. Sua desvantagem e
o espaco de enderecamento limitado pelo n
umero de registradores;
Indireto via Registrador : semelhante ao modo de enderecamento indireto.
O campo de endereco aponta para o registrado que contem a posic ao de
mem oria do operando. Sua vantagem e a necessidade de um unico acesso
a mem oria, um a menos que no modo indireto;
Deslocamento: requer que uma instruc ao tenha dois campos de endereco,
com pelo menos um explcito. O valor de um dos campos e usado dire-
tamente (valor = A). O outro campo e baseado no c odigo da operac
ao, e
especifica um registrador cujo conte udo e adicionado a A, para produzir o
endereco efetivo. Os tres modos de enderecamento por deslocamento s ao
relativo, via registrador-base e indexado;
Pilha: A pilha e um bloco reservado de posicoes em mem oria. Elementos
podem ser colocados e removidos do topo da pilha. o apontador do topo
da pilha (stack-pointer ) e mantido em um registrador. Portanto, de fato,
referencias a pilha s
ao feitas por enderecamento indireto via registrador.
1.6 Organizac
ao de Mem
oria
Um sistema de computador tpico e equipado com uma hierarquia de subsis-
temas de mem oria, algumas internas (diretamente acessveis pelo processador,
como registradores, cache e mem oria principal) e outras externas (acessveis
pelo processador por meio de um m odulo de E/S, como disco e cdrom). As
caractersticas fundamentais de um sistema de mem oria s
ao:
1. Localizac
ao - processador, interna (principal), externa (secund
aria);
2. Capacidade - tamanho da palavra e n
umero da palavra;
3. Unidade de Transferencia - palavra, bloco;
4. Metodo de Acesso - seq
uencial, direto, aleat
orio, associativo;
5. Desempenho - tempo de acesso, tempo de ciclo e taxa de transferencia;
6. Tecnologia - semicondutores, magnetica,
optica, magneto-
optico;
7. Caractersticas Fsicas - vol

atil/n
ao vol
atil, apag
avel/n
ao apag
avel.
Quanto ao metodo de acesso das mem orias internas, vale a pena destacar os
acessos aleat
orio e associativo. No acesso aleat orio, cada unidade enderec avel
possui um mecanismo de enderecamento u nico e fisicamente conectado a ela. E
o metodo utilizado na mem oria principal. O esquema associativo consiste em
um tipo de mem oria de acesso aleat
orio que possibilita comparar simultanea-
mente um certo n umero de bits de uma palavra com todas palavras da mem oria
(totalmente associativo) ou com um conjunto de palavras de mem oria (associa-
tivo por conjunto). O metodo associativo e empregado pelas mem orias cache.
26
As restric
oes de um projeto de mem
oria podem ser resumidos por 3 quest oes:
Capacidade, Velocidade e Custo. Neste cen ario, valem as seguintes relac
oes:
1. Menor tempo de acesso, maior custo por bit;

2. Maior capacidade, menor custo por bit;
3. Maior capacidade, menor tempo de acesso.
A organizac
ao hierarquica dos sistemas de mem oria visa lidar com o dilema
imposto pelas relac
oes apresentadas. A hierarquia e elaborada de forma que as
a medida que nela descemos as seguintes relacoes s
ao tambem v alidas:
1 O custo por bit diminui;

2 A capacidade aumenta;
3 O tempo de acesso aumenta;
4 A freq
uencia de acesso pelo processador diminui.
Desse modo, as mem orias menores, mais caras e mais rapidas s

ao combi-
nadas com memoria de maior capacidade, mais lentas e baratas.
A chave do sucesso dessa organizac ao baseia-se principalmente na relac ao

4, que resume o princpio da Localidade das Referencias. Este princpio diz
que ao longo da execuc ao de um programa, as referencias feitas `
a mem
oria pelo
processador, tanto no caso de instrucoes como dados, tendem a formar grupos
no qual est ao proximas umas das outras. Desse modo e possvel organizar os
dados ao longo de uma hierarquia de forma que a porcentagem de acessos ` a um
certo nvel seja sucessivamente bem inferior do que a porcentagem de acessos ` a
um nvel imediatamente superior.
Registradores, mem oria cache e mem oria principal s

ao as tres formas de
mem oria interna que empregam tecnologias de semicondutores. O uso de tres
nveis explora as diferencas de velocidade e custo dessas mem orias. Alem de-
las, alguns sistemas utilizam tecnologias e tecnicas adicionais na hierarquia de
mem oria.
A Mem oria Expandida emprega uma tecnologia mais lenta que a mem orias
principais. Ela funciona como um ramo lateral a mem oria principal, n
ao se
comunicando com a mem oria externa. J

a a tecnica de Mem oria Virtual permite
que os discos funcionem como uma extens ao da mem oria principal, aumentando
o desempenho do sistema.
A utilizac
ao de mem orias cache tem por objetivo proporcionar uma veloci-
dade de acesso pr oxima a velocidade de acesso aos registradores, no entanto
oferecendo uma capacidade maior do que o conjunto de registradores, e custo
n
ao muito superior ao da mem oria principal. Os principais elementos de projeto
de mem orias cache sao:
i Tamanho - deve ser projetado para conjugar bem velocidade, capacidade

e custo;
27
ii Func
ao de Mapeamento - direto, associativo, associativo por conjuntos;
iii Algoritmo de Substituic
ao - LRU, FIFO, LFU, Aleat
orio;
iv Poltica de Escrita - direta (write-through), de volta (write-back) e u

nica
(write-once);
v Tamanho da Linha;
vi N
umero de Mem
orias Cache - um ou dois nveis, unificada/separada.
Entre os elementos de projeto de mem oria cache vale destacar tres. O

primeiro e a Funcao de Mapeamento, que diz respeito a determinar onde um
bloco da mem oria principal pode ser encontrado na mem oria cache. Para re-
alizar este mapeamento s ao necess
arios o endereco do bloco na mem oria prin-
cipal e a func
ao de mapeamento. No esquema de mapeamento direto, um de-
terminado conjunto de blocos da mem oria principal s
o pode ser encontrado em
uma linha especfica da mem oria cache. E de f
acil implementac
ao, porem pode
utilizar de forma ineficiente o espaco da cache. No mapeamento associativo
um bloco da mem oria principal pode ser colocado em qualquer linha da cache.
Maximiza a ocupac ao da cache, porem exige uma l ogica de controle que real-
ize comparacao do r otulo com todas as linhas do cache simultaneamente. No
esquema associativo por conjuntos, um bloco da mem oria principal pode se en-
contrar em um conjunto de linhas da cache, e n ao nela toda. Visa conjugar
vantagens dos metodos direto e associativo.
O segundo elemento e Poltica de Escrita, que visa garantir a coerencia das

informacoes nos diferentes mem orias acessveis pelo processador e dispositivos
de E/S. Na tecnica e a de escrita direta (write-through), todas as operac oes de
escrita s
ao feitas na mem oria principal e no cache. Esta garante a coerencia em
todas as mem orias do sistema, no entanto e de baixo desempenho. Na tecnica
de escrita de volta (write-back), as escritas s ao feitas apenas na cache. Minimiza
as operacoes de escrita em mem oria principal, porem imp oe que operac
oes de
E/S acessem o cache.
O terceiro elemento e o n
umero de mem orias cache do sistema. Atualmente,
a organizacao mais comuns e baseada em 2 nveis, um interno ao processador
(L1) e outro externo (L2). Originalmente, a maioria dos projetos de cache
inclui uma u nica memoria cache, que armazenava tanto instruc oes como da-
dos. Recentemente, tornou-se comum a utilizac ao de mem orias separadas para
instruc
oes e dados. Em processadores modernos que se valem de tecnicas de
busca antecipada de instrucao (Pipeline), tecnicas de Cache Separadas s ao mais
eficientes que as de Cache Unificada.
1.7 Desempenho do computador

O desempenho de um computador pode ser definido como:
1
Desempenho = (1.1)
T empo de Execucao
28
O tempo e a medida de desempenho de um sistema computacional. Em

geral, ele e medido em segundos e pode ser definido de diferentes maneiras. O
tempo de resposta ou tempo decorrido (elapsed time) define o tempo total para
se completar uma tarefa computacional, incluindo os acessos ` a mem oria e ao
disco, as atividades de entrada e sada e o overhead do sistema operacional.
O tempo do processador (CPU time) define o tempo gasto pelo proces-

sador para executar um programa em particular, n ao considerando o tempo de
execucao de outros programas, tempo de espera por I/O, etc. Este tempo e
dividido em tempo do usu ario e tempo do sistema. O tempo do usu ario e o
tempo gasto na execuc ao das instruc
oes do programa do usuario. J
a o tempo
do sistema e o tempo gasto pelo sistema operacional para executar tarefas em
benefcio do programa do usu ario. A medida de tempo que mais interessa e o
tempo de usu ario.
Os projetistas medem a velocidade do hardware na execuc ao de suas func

oes
b
asicas com o clock. O clock possui uma taxa constante e determina o momento
da ocorrencia de eventos do pr oprio hardware. O tamanho de um perodo de
clock e referenciado tanto como o tempo necess ario para completar um ciclo de
clock quanto como a freq uencia do clock (inverso do ciclo de clock). Por exemplo,
um ciclo de clock igual a 2 s corresponde a uma freq uencia de 500MHz, que e
o inverso do ciclo de clock.
1.7.1 Tempo de execuc

ao de um programa
F
ormulas bastante simples relacionam a medida do tempo de execuc ao gasto no
processador com a metrica basica baseada nos ciclos de clock e tempo do ciclo
de clock:
Tempo de CPU do programa = N de ciclos x Perodo de clock

= N de ciclos / Frequencia do clock
Essas formulas n ao incluem qualquer referencia ao numero de instrucoes

necess
arias `
a execuc
ao de um programa. O tempo de execuc ao tambem depende
do n
umero de instruc oes do programa. O numero de ciclos de clock necess
arios
a execuc
` ao de uma instrucao e dado por:
No de ciclos de clock = No instruc

oes do programa x CPI (1.2)
A CPI e a media do numero de ciclos por instruc

ao. Este par
ametro permite
a comparac
ao entre diferentes implementac oes de uma mesma arquitetura do
conjunto de instruc
oes, uma vez que o numero de instrucoes para a execuc
ao do
programa nas diferentes implementac oes e o mesmo.
1.7.2 Desempenho da CPU

O desempenho da CPU na execuc ao de um programa pode ser medido em termos
quantidade de instruc
oes, do CPI e do perodo do clock:
29
Tempo de CPU = No de instruc

oes x CPI x Perodo do clock (1.3)
O tempo de CPU e medido executando o programa, o perodo do clock e

divulgado pelo fabricante e o n
umero de instruc
oes e obtido por meio de soft-
wares conhecidos como execution profilers ou por simuladores de arquitetura.
Em uma primeira aproximac ao, o n

umero de instruc
oes, a CPI e o perodo
do clock s
ao afetados respectivamente pela capacidade de otimizac ao do com-
pilador, pela arquitetura do processador e de seu conjunto de instruc
oes; e pela
tecnologia empregada na implementac ao da maquina.
1.7.3 Programas para medir desempenho

Existem quatro nveis de programas que podem ser usados para avaliacao de
desempenho, eles est
ao listados em ordem decrescente de precis
ao de previs
ao:
Programas reais;
N
ucleos ou kernels (pedacos de programas reais);
Toy Benchmarks (programas com 10 a 100 linhas de c
odigo que produzem
um resultado conhecido a priori);
Benchmarks sinteticos (similar em filosofia aos n
ucleos, tentam casar a
freq
uencia media de operac
oes de um grande conjunto de programas).
Os benchmarks s ao conjuntos de aplicacoes que representam cargas de tra-

balho cujo objetivo e estimar o desempenho das cargas de trabalho reais. Os
benchmarks podem conter aplicac oes tpicas de processamento cientfico, com-
piladores, processadores de texto entre outras.
Um Benchmark Suite e um conjunto de programas de avaliac ao. A Stan-

dard Performance Evaluation Corporation (SPEC) tem lancado v arios bench-
mark suites: SPEC89, SPEC92, SPEC95 e SPEC2000. Estas benchmark suites
s
ao compostas por programas reais, escolhidos para serem representativos de
programas que tipicamente demandam muita CPU e pouco I/O.
1.7.4 Comparando desempenho

Uma vez selecionados os programas adequados para usar como benchmarks e

decidida a metrica de avaliacao, tempo de resposta ou throughput (numero de
tarefas executadas por unidade de tempo), e necess ario decidir como comparar
os dados de desempenho obtidos a partir de diferentes benchmarks.
A maneira mais simples de considerar o desempenho relativo e usar o tempo

total de execuc
ao de dois programas em m aquinas diferentes. Por exemplo, os
tempos de execuc ao de dois programas conforme a tabela 1.1.
Outra maneira de sumarizar os tempos e utilizando as medias aritmetica,
harm onica ou geometrica. A media geometrica e inadequada, pois n
ao prediz o
tempo de execuc ao.
30
Computador A Computador B
Programa 1 (s) 1 10
Programa 2 (s) 1000 100
Total (s) 1001 110
Tabela 1.1: Tempo total de execuc

ao de 2 programas
1
Media Aritmetica = Tempo (i,n) = (1.4)
n
n
Media Harm
onica = Taxa (i,n) = Pn 1 (1.5)
i=1 T axai
v
u n
uY
Media Geometrica = Tempo Normalizado (i,n) = t
n
T normalizadoi (1.6)
i=1
Alem das media, existem ainda outras medidas de desempenho. Uma das
alternativas e a metrica MIPS (million instruction per second), que e dada por
um das seguintes express oes:
N
umero de instrucoes
MIPS =
Tempo de execucao x 106
Freq
uencia de Clock
=
CPI 106
Existem problemas com o uso da metrica MIPS. Ela especifica a taxa de
execucao de instruc
oes, mas n
ao considera a capacidade de executar mais ou
menos trabalho. Portanto, n ao podemos comparar m aquinas com conjuntos de
instruc
oes diferentes. Outro problema e que os resultados obtidos variam en-
tre programas no mesmo computador, o que impede que determinada m aquina
tenha um MIPS caracterstico.
Outra alternativa e a metrica denominada MFLOPS (million floating-point

operations per second), que e dada pela seguinte express
ao:
N
umero de op. de ponto flutuante
MFLOPS = (1.7)
ao x 106
Tempo de execuc
Uma operac ao de ponto flutuante pode ser uma operac
ao de adic
ao, sub-
trac
ao, multiplicac
ao ou divis
ao aplicada a operandos expressos em precisao
simples ou dupla.
1.7.5 Lei de Amdahl

A lei de Amdhal pode ser utilizada para demonstrar o ganho de desempenho
de uma m aquina. Este ganho e dito acelerac
ao ou speedup. Entende-se por
acelerac
ao a medida de como a m aquina se comporta ap os a implementac
ao
31
de uma melhora em relac

ao ao seu comportamento anterior. Podemos definir
speedup como:
Desempenho ap
os a melhora
speedup = (1.8)
Desempenho antes da melhora
A lei de Amdhal demonstra que e errado esperar que a melhora em um dos
aspectos que influenciam no desempenho da m aquina resulte numa melhora no
desempenho total proporcional ao tamanho do ganho inicial da frac
ao.
32
Captulo 2
Componentes de um
Computador
O computador est
a organizado em dois componentes que s
ao:
Hardware: corresponde a parte fsica que esta dividida em: unidade de

entrada e sada, processador, mem
oria principal e memoria secund
aria;
Software: e o conjunto de programas que d

a vida `
a m classificado
aquina. E
em software aplicativo (jogos, planilha, etc.) e software basico (sistema
operacional, compiladores, editores de texto, etc.).
Para interligar os componentes do hardware existe uma placa de suporte

especial, chamada placa-m ae. A placa-m ae e respons
avel por gerenciar toda a
transac
ao entre o processador e os perifericos. Os componentes principais da
placa-m ae s
ao: chipset, BIOS, barramentos, e slots.
Chipset e o chip responsavel pelo controle de diversos dispositivos de entrada

e sada como o barramento, o acesso ` a mem oria, o acesso ao HD, perifericos
on-board e off-board, comunicac ao do processador com a mem oria RAM e en-
tre outros componentes da placa-m ae. Uma placa-m ae possui dois chipsets: o
chipset sul e o chiset norte. O chipset sul (south bridge) e responsavel pelo cont-
role de dispositivos de entrada ou sada enquanto o chipset norte (north bridge)
faz a comunicac ao entre o processador e a mem oria principal.
O BIOS (Basic Input/Output System) e o primeiro programa executado

pelo computador ao ser ligado. Sua func ao prim
aria e preparar a m
aquina para
que o sistema operacional, que pode estar armazenado em diversos tipos de
dispositivos (discos rgidos, disquetes, CDs, etc) possa ser executado. O BIOS
e armazenado num chip ROM (Read-Only Memory) localizado na placa-m ae,
chamado ROM BIOS. O BIOS tambem e respons avel por controlar o uso dos
dispositivos e manter informac oes de data e hora. O BIOS trabalha junto com
o post, um software que testa os componentes do micro em busca de eventuais
erros. Pode-se alterar as configurac oes de hardware atraves do setup.
33
Os barramentos permitem a interligac ao entre os dispositivos da placa-m

ae.
S
ao divididos em tres conjuntos: via de dados, via de enderecos e via de cont-
role. O desempenho do barramento pode ser medido pela sua largura de banda
(32, 64 bits, etc.) e pela sua velocidade de transmissao (100 Mbps, 1G bps, etc.).
Os slots s
ao respons
aveis por ligar os perifericos aos barramentos e suas
velocidades e largura de banda s
ao correspondentes as dos seus respectivos bar-
ramentos. Na placa-m ae s
ao encontrados varios slots para encaixe de placas
(vdeo, som, rede, modem, etc.). Alguns exemplos de slots: ISA, PCI, AGP,
PCI Express, etc.
2.1 Principais componentes de Hardware

2.1.1 Discos Rgidos
Os discos rgidos s
ao dispositivos de armazenamento destinados a grandes quan-
tidades de dados. Fisicamente, um disco rgido pode ser visto como um com-
posto por dois grandes blocos, como na figura 2.2. O primeiro bloco e um
conjunto de discos magneticos superpostos em alturas diferentes com auxlio de
um eixo central. No momento de acesso ao disco, essa estrutura e mantida em
uma rotac
ao constante. O segundo bloco e uma estrutura mec anica que suporta
um conjunto de cabecotes, um para cada superfcie de disco. Essa estrutura e
capaz de realizar movimentos de vai-e-vem de maneira que os cabecotes possam
ser deslocados desde a borda do disco ate o centro.
Figura 2.1: Organizac

ao fsica do disco
Do ponto de vista da organizac ao l

ogica, cada superfcie de um disco e di-
vidida em circunferencias concentricas denominadas trilhas. Cada trilha, por
sua vez, e subdividida radialmente em unidades chamadas setores. Em geral,
os setores tem o mesmo tamanho. O setor possui a unidade mnima de leitura
e gravac
ao em um disco. O conjunto de todas as superfcies do disco que fi-
cam exatamente ` a mesma dist ancia do eixo central forma o cilindro, conforme
a figura ??. As abstrac
oes cilindro, trilha e setor s
ao utilizadas para designar a
organizac
ao l
ogica da unidade de disco. A definic ao de trilhas e de setores em
34
um disco chama-se formatacao fsica e e um procedimento realizado pelo fabri-

cante. A capacidade total do disco e obtida multiplicando-se cabecas x cilindros
x setores x tamanho do setor.

ao l
ogica da unidade de disco
Para acessar dados no disco, e necess ario informar ` a controladora o cilin-

dro, a superfcie e o setor a ser acessado. Esse metodo e denominado de CHS
(Cylinder, Head, Sector). Outra maneira e acessar o disco e enxerg a-lo como
um conjunto de blocos, no qual cada bloco e um ou mais setores. O n umero de
blocos e ent
ao convertido em cilindros, superfcie e setores por um procedimento
que se denomina de LBA (Linear Block Addressing).
Outros termos bastante comuns associados a disco rgidos s ao formatac ao

l
ogica e partic
oes. A formatac
ao l
ogica consiste em gravar informac
oes no disco
de forma que arquivos possam ser escritos, lidos e localizados pelo sistema op-
eracional. O conceito de particao est
a associado à capacidade de dividir logica-
mente um disco em v arios outros discos.
Para realizar um acesso a um disco, e necess

ario posicionar o cabecote de
leitura e escrita sob um determinado setor e trilha onde dado sera lido ou es-
crito. O tempo total de acesso aos disco, seja para leitura ou para escrita, e
dado pela seguinte formula:
Ta cesso = Ts eek + Tl atencia + Tt ransf erencia (2.1)

A descric
ao de cada um dos termos da soma e a seguinte:
Tempo de Seek: tempo necess ario para deslocar o cabecote de leitura e

escrita ate o cilindro correspondente `
a trilha a ser acessada;
Tempo de Latencia: tempo necess ario, uma vez o cabecote posicionado j

a
na trilha correta, para o setor a ser lido, ou escrito, se posicionar sob o
cabecote de leitura e escrita no incio do setor a ser lido (ou escrito);
Tempo de Transferencia: corresponde ao tempo necess ario `
a transferencia
dos dados, isso e, `
a leitura ou a escrita dos dados.
35
Outro fator relacionado com a reduc ao do tempo de acesso a um disco e

o entrelacamento (interleaving). Essa tecnica numera os setores n ao mais de
forma contgua, mas sim com um espaco entre eles. O disco 2 da Ilustracao 14
possui um fator de entrelacamento igual a 2. Isso significa que entre o setor k
e o setor k+1, existem dois outros setores. O melhor fator de entrelacamento
para uma determinada unidade de disco depende da velocidade do processador,
do barramento, do controlador e da velocidade de rotacao do disco.
Figura 2.3: Trilha com 16 setores e diferentes fatores de entrelacamento
2.1.2 Teclado
O teclado e o principal periferico de entrada de dados utilizado na integrac
ao
direta de usu
arios com o computador. O princpio de operacao do teclado e bas-
tante simples: gerar um smbolo para cada tecla pressionada. Mecanicamente,
um teclado pode ser visto como uma matriz de i linhas e j colunas as quais
entram em contato quando uma tecla e pressionada. A cada elemento i,j da
matriz correspondente um caractere.
Quando uma tecla e pressionada, o teclado identifica a linha e a coluna

associadas a essa tecla e gera um c odigo que e denominado de scan mode (c odigo
de varredura). O pressionar da tecla gera ainda uma interrupc ao de hardware,
e por conseq uencia, a execucao de um tratador de interrupc
oes especfico para
o teclado. Com base no scan mode, o tratador de interrupc oes consulta uma
tabela interna, substituindo o scan mode pelo c odigo ASCII correspondente ` a
tecla pressionada. O c odigo ASCII da tecla, em seguida, e armazenado em
uma regi ao especial da mem oria (buffer do teclado) de onde e recuperado por
chamadas do sistema operacional.
Um teclado brasileiro difere de um teclado ingles na posic ao dos acentos e

da cedilha, por exemplo. A soluc ao empregada e associar a certos programas
aplicativos mapas de c odigos. Atraves desses mapas de c odigos, os programas
aplicativos s
ao capazes de consumir caracteres do buffer de teclado e converte-
los de forma apropriada.
O procedimento de ler os dados do teclado e escreve-los na tela denomina-se

ecoamento. Quando se tem v arias janelas abertas, os caracteres digitados devem
ser direcionados `
a janela correta. Dois metodos s ao normalmente empregados:
centralizado e dedicado.
36
No metodo centralizado o driver de teclado disponibiliza um conjunto de

mini-buffers os quais podem ser encadeados para formar um buffer maior. Nesse
caso, para cada janela aberta o sistema operacional atribui uma estrutura de
dados na qual um dos seus elementos e um ponteiro utilizado para referenciar
e lista encadeada de mini-buffers. No metodo dedicado, a bufferizac ao e feita
diretamente em uma area de memoria provida pela estrutura de dados associada
ao terminal. Nesse caso, o n umero de entradas para o terminal e limitado pelo
tamanho do buffer dessa estrutura.
2.1.3 Mouse
O mouse e um periferico de entrada que historicamente se juntou ao teclado
como auxiliar no processo de entrada de dados, especialmente em programas
com interface grafica. O mouse tem como func ao movimentar o cursor (apon-
tador) pela tela do computador. O formato mais comum do cursor e uma seta,
contudo, existem opcoes no sistema operacional e softwares que permitem per-
sonalizarmos o cursor do mouse.
O mouse funciona como um apontador sobre a tela do monitor, e disponibi-

liza, normalmente, quatro tipos de operacoes: movimento, click (clique), duplo
click e drag and drop (arrastar e largar).
Existem modelos com um, dois, tres ou mais bot oes cuja funcionalidade
depende do ambiente de trabalho e do programa que est
a a ser utilizado. Clara-
mente, o bot
ao esquerdo e o mais utilizado.
O mouse e normalmente ligado ao computador atraves de portas: serial, PS2

ou, mais recentemente, USB (Universal Serial Bus). Tambem existem conex oes
sem fio, as mais antigas em infra-vermelho, as atuais em Bluetooth. Outros dis-
positivos de entrada competem com o mouse: Touchpads (usados basicamente
em notebooks) e Trackballs.
O mouse original possua dois discos que rolavam nos eixos X e Y e tocavam
diretamente na superfcie. O modelo mais conhecido de rato e provavelmente o
mouse baseado em uma esfera, que roda livremente, mas que na pr atica gira dois
discos que ficam em seu interior. O movimento dos discos pode ser detectado
tanto mecanicamente quanto por meio otico.
Os modelos mais modernos de mouse s ao totalmente oticos, n

ao tendo pecas
moveis. De modo muito simplificado, eles tiram fotografias que sao comparadas
e que permitem deduzir o movimento que foi feito.
2.1.4 Placa de rede

Uma placa de rede e um dispositivo de hardware respons avel pela comunicac ao
entre os computadores em uma rede. A placa de rede e o hardware que permite
aos computadores conversarem entre si atraves da rede. Sua func ao e controlar
todo o envio e recebimento de dados atraves da rede. Cada arquitetura de rede
exige um tipo especfico de placa de rede, sendo as arquiteturas mais comuns as
37
redes Ethernet e Token Ring.
Alem da arquitetura usada, as placas de rede `

a venda no mercado diferenciam-
se tambem pela taxa de transmiss ao, cabos de rede suportados e barramento
utilizado (On-Board, PCI, ISA ou Externa via USB). As placas de rede para
Notebooks podem ser on-board ou por uma placa PCMCIA.
Quanto ` a taxa de transmissao, as placas mais comuns sao Ethernet de 10,

100 ou 1000 Mbps e placas Token Ring de 4 Mbps e 16 Mbps. Usando placas
Ethernet de 10 Mbps, por exemplo, devemos utilizar cabos de par trancado de
categoria 3 ou 5, ou ent ao cabos coaxiais. Usando uma placas de 100 Mbps o
requisito mnimo a nvel de cabeamento sao cabos de par trancado nvel 5. No
caso de redes Token Ring, os requisitos s ao cabos de par trancado categoria 2
(recomend avel o uso de cabos categoria 3) para placas de rede de 4 Mbps, e
cabos de par trancado blindado categoria 4 para placas de 16 Mbps. Devido ` as
exigencias de uma topologia em estrela das redes Token Ring, nenhuma placa
de rede Token Ring suporta o uso de cabos coaxiais.
2.1.5 Impressora
As impressoras sao dispositivos de sada que tem por finalidade imprimir em
papel ou filme pl
astico os resultados do processamento. Da mesma forma que
os monitores, a imagem impressa e resultado de muitos pontos impressos indi-
vidualmente que no conjunto formam o texto ou a imagem desejados. Tambem
de forma semelhante aos monitores, as impressoras evoluram a partir de dis-
positivos que imprimiam apenas caracteres em uma u nica cor para as modernas
impressoras capazes de reproduzir imagens sofisticadas, de alta resoluc
ao gr
afica,
em milhares de cores. As impressoras s ao classificadas em:
Impressoras alfanumericas: Esses equipamentos recebem do computador

c
odigos que representam caracteres alfanumericos e portanto tem capaci-
dade de imprimir apenas esses caracteres. Geralmente e possvel usar ape-
nas uma fonte gr
afica, caracterstica do equipamento. Algumas impresso-
ras permitem trocar o dispositivo de impress ao, viabilizando a utilizac
ao
de um pequeno n umero de fontes gr aficas;
Impressoras gr aficas: Esses equipamentos recebem do computador a in-
formac
ao sobre os pontos a serem impressos. Dessa forma, podem im-
primir gr
aficos. Na impress ao de textos, os caracteres s
ao impressos como
pontos, que em determinada configurac ao formam a imagem gr afica do
caractere a ser impresso. Quando se utiliza uma impressora gr afica para
imprimir texto, existe a possibilidade de utilizar um grande n umero de
diferentes fontes graficas, definidas por software.
2.1.6 Monitor
38
Captulo 3
Aritm
etica Computacional
3.1 N
umeros Com Sinal e N
umeros Sem Sinal
Existe uma grande variedade de opc
oes para representar os n
umeros inteiros
com ou sem sinal. Apenas quatro se destacam: sinal e amplitude/magnitude
(S + M ), complemento de 1, complemento de 2 e notac
ao em excesso (biased ).
3.1.1 Sinal e amplitude/magnitude

Neste sistema de representacao o bit mais a esquerda representa o sinal: 0 (zero)
para indicar o valor positivo e 1 (um) para indicar o valor negativo. Os bits
restantes representam o m odulo. A amplitude ou faixa de representac ao para n
bits e [(2n1 1); 2n1 1]. Por exemplo, para n=8 a faixa de representac ao
e [127; 127]. Neste sistema o zero possui duas representac oes, por exemplo,
n = 4 (0000 e 1000).
3.1.2 Complemento de 1
Neste sistema de representac ao o bit mais a esquerda representa o sinal: 0 (zero)
para indicar o valor positivo e 1 (um) para indicar o valor negativo. Para os
n
umeros positivos, os n-1 bits representam o m odulo. O simetrico de um n
umero
positivo e obtido pelo complemento de todos os seus dgitos (trocando 0 por 1
e vice-versa) incluindo o bit de sinal. A amplitude ou faixa de representac ao
para n bits e [(2n1 1); 2n1 1]. Por exemplo, para n = 8 a faixa de
representacao e [127; 127]. Neste sistema o zero possui duas representac oes,
por exemplo, n = 4 (0000 e 1000).
3.1.3 Complemento de 2
Neste sistema de representac
ao o bit mais a esquerda representa o sinal: 0 (zero)
para indicar o valor positivo e 1 (um) para indicar o valor negativo. Para os
numeros positivos, os bits restantes representam o m odulo. A amplitude ou
ao para n bits e [(2n1 ); 2n1 1]. Por exemplo, para
faixa de representac
n=8 a faixa de representac
ao e [128; 127]. Este sistema possui representac ao
assimetrica, o n
umero de representacoes negativas e maior do que a positiva.
Este sistema o zero possui uma u nica representac
ao, por exemplo, n=4 (0000).
39
O complemento de 2 de um n umero e obtido em dois passos: primeiro obtem-

se o complemento de todos os bits (inclusive o de sinal); e ao resultado obtido
soma-se 1 (um) em bin ario, desprezando o ultimo transporte, se houver.
Uma maneira pr atica de se obter o complemento de 2 de um n umero e copiar
da direita para a esquerda todos os bits ate encontrar o primeiro bit 1 (copiar
inclusive este bit), e inverter todos os demais bits. Um exemplo para n=4:
0110 (6 na base 10) usando a regra:

1001 (n
umero binario invertido) 0110 < > 1001
+ 0001 (soma binaria com 1)
1010 (complemento de 2)
Os computadores manipulam tanto numero inteiros positivos quanto negativos,
que s
ao representados em complemento de 2.
3.1.4 Nota
cao em excesso
Neste sistema de representac ao o bit mais a esquerda representa o sinal: 1
(um) para indicar o valor positivo e 0 (zero) para indicar o valor negativo. A
amplitude ou faixa de representac ao para n bits e [(2n1 ); 2n1 1]. Por
exemplo, para n=8 a faixa de representac ao e [128; 127]. Neste sistema cada
umero inteiro corresponde ao valor desejado acrescido de um excesso de 2n1 ,
n
onde n pode ser 4, 5, 7, 8, 16, etc.
Este sistema tem uma vantagem em relac ao aos outros sistemas apresenta-
dos anteriormente: o valor em bin ario com todos os bits a 0 (zero) representa o
menor valor inteiro, que este tenha sinal ou n ao, e o mesmo se aplica ao maior
valor em binario, i.e., com todos os bits 1: representa o maior inteiro, com ou
sem sinal.
Bin
ario (4 bits) S+M C1 C2 Excesso de 8 (n=4)
0000 +0 +0 0 -8 (0 - 8)
0001 1 1 1 -7 (1 - 8)
0010 2 2 2 -6 (2 - 8)
0011 3 3 3 -5 (3 - 8)
0100 4 4 4 -4 (4 - 8)
0101 5 5 5 -3 (5 - 8)
0110 6 6 6 -2 (6 - 8)
0111 7 7 7 -1 (7 - 8)
1000 -0 -7 -8 0 (8 - 8)
1001 -1 -6 -7 1 (9 - 8)
1010 -2 -5 -6 2 (10 - 8)
1011 -3 -4 -5 3 (11 - 8)
1100 -4 -3 -4 4 (12 - 8)
1101 -5 -2 -3 5 (13 - 8)
1110 -6 -1 -2 6 (14 - 8)
1111 -7 -0 -1 7 (15 - 8)
40
3.2 Adic
ao e Subtra
cao
Numa soma os bits s ao somados um a um da direita para a esquerda, com os
carries sendo passados para o pr oximo bit à esquerda. A operacao de sub-
trac
ao usa a adic
ao. O subtraendo e simplesmente negado antes de ser somado
ao minuendo. Lembre-se que a m aquina trata com numeros representados em
complemento a 2. O exemplo a seguir mostra as operac oes de soma (6 + 7) e
subtrac
ao (7 6) (complemento 2) bit a bit entre dois n
umeros representados
com 4 dgitos binarios.
7 = 0111
6 = 0110
13 = 1101 (soma)
1 = 0001 (subtrac
ao)
Tanto a soma como a subtrac ao podem gerar overflow ou underflow, se

o resultado obtido n ao puder ser representado pela quantidade de bits que
formam uma palavra. Se somarmos ou subtrairmos dois n umeros com sinais
contrarios, nunca ocorrera overflow ou underflow. Isto porque operandos com
sinais contrarios nunca podem ser maior do que qualquer dos operandos.
O overflow ocorre quando somamos dois operandos positivos e obtemos
um resultado negativo, ou vice-versa. Isto significa que utilizamos o bit de
sinal, gerando um carry, para armazenar um valor pertencente ao resultado
da operacao. Raciocnio semelhante e realizado para detectar a ocorrencia do
underflow numa subtrac ao. Neste caso, o bit de sinal tambem e usado para
armazenar um valor pertencente ao resultado da operac ao.
Os projetistas de um sistema devem decidir onde tratar a ocorrencia de
overflow ou de underflow em operac oes aritmeticas. Elas podem ser tratadas
tanto por hardware quanto por software. Pode existir a detecc ao por hardware
que gera uma excec ao, e que depois e tratada por software.
3.3 Operac
oes L
ogicas
Os computadores manipulam palavras, mas e muito u til, tambem, manipular
campos de bits dentro de uma palavra ou mesmo bits individuais. O exame
de caracteres individuais (8 bits) dentro de uma palavra e um bom exemplo
dessa necessidade. Assim, as arquiteturas de conjuntos de instruc oes incluem
instruc
oes para manipulacao de bits.
Um dos tipos de instruc ao utilizado e a de deslocamento de bits. As in-

struc
oes podem deslocar bits tanto ` a direita quanto ` a esquerda. Todos os bits
s
ao movidos para o lado determinado e os bits que ficam vazios s ao preenchidos
com 0s. Outras instruc oes l
ogicas muito u teis s
ao implementadas na unidade
l
ogica e aritmetica de um processador sao as operacoes NOT, AND, OR e XOR.
O exemplo abaixo mostra as operac oes l
ogicas, bit a bit, de deslocamento à di-
reita, `
a esquerda, NOT, AND, OR e XOR.
41
3.4 Construc
ao de uma Unidade L
ogica Aritm
etica
A ALU (Arithmetic and Logic Control) e a parte central do hardware de uma
CPU. Ela e respons
avel por realizar operac
oes aritmeticas e l
ogicas b
asicas, e
pode ser implementada com quatro componentes: AND, OR, INVERTER e
MULTIPLEXOR (3.4).
Figura 3.1: Multiplexador
Para implementar um somador de um bit, precisa-se de duas entradas para

os operandos, uma sada para o resultado, uma entrada relativa ao carry in e
um sada relativa ao carry out. A tabela abaixo mostra a tabela verdade para o
somador de um bit.
Entrada Sada
a b carry in soma carry out
0 0 0 0 0
0 0 1 1 0
0 1 0 1 0
0 1 1 0 1
1 0 0 1 0
1 0 1 0 1
1 1 0 0 1
1 1 1 1 1
As sadas soma e carry out s
ao:
soma = (a.b.carryin + a.b.carryin + a.b.carryin + a.b.carryin)
carryout = (b.carryin + a.carryin + a.b)

Para completar o projeto de uma ALU de n bits, podemos conectar n so-

madores de um bit. Os carry outs gerados pelos bits menos significativos s ao
propagados por toda extens ao do somador.
A operacao de subtrac ao pode ser realizada somando-se o minuendo com
a negac
ao do subtraendo. Este efeito e realizado acrescentando uma entrada
complementada de b ao somador e ativando o carry in do bit menos significativo
para um. O somador ent ao calcula a + b + 1.
Outras funcoes de interesse, com o XOR podem ser includas na ALU. Al-
gumas operac oes nao sao, em geral, implementadas na ALU (3.4). Exemplos:
shift, multiplicac
ao, divis
ao e operac
oes de ponto flutuante.
42
Figura 3.2: ALU
3.5 Ponto Flutuante

Para somar dois n
umeros na base 10 em notac
ao cientfica temos que:
Alinhar os pontos;
Somar os n
umeros;
Normalizar o resultado;
Arredondar o resultado para o n
umero m
aximo de casas permitidas.
Um hardware para somar n umeros de ponto flutuante tem que fazer as mes-
mas operac
oes com numeros binarios. Vejamos um exemplo:
Exemplo: Somar os n umeros 0.5 e -0.4375 em bin
ario e apresente com 4 bits
de precis
ao; trunque o resultado na fase de arredondamento.
ario) = 0.1 20 = 1.000 21

0.5 = 0.1 (bin
ario) = 0.0111 20 = 1.110 22

0.4375 = 0.0111 (bin
1. Igualar os expoentes (modificar o n

umero menor)
1.110 22 = 0.111 21
2. Somar as partes significantes (mantissas)
1.000 21 + (0.111 21 ) = 1.000 21 + (1.001 21 ) = 0.001 21
3. Normalizar o resultado
0.001 21 = 1.0 24
4. Arredondamento
O n
umero final est
a OK.
43
Captulo 4
Sistemas Operacionais
4.1 Introduc
ao
O sistema operacional e uma camada de software colocada entre o hardware
e os programas que executam tarefas para os usu arios. O sistema operacional
e responsavel pelo o acesso aos perifericos, ou seja, sempre que um programa
necessita de algum tipo de operac
ao de entrada e sada, ele solicita ao sistema
operacional.
Figura 4.1: Sistema Operacional

O objetivo do sistema operacional e tornar a utilizac

ao do computador mais
eficiente e mais conveniente. Uma utilizac ao mais eficiente do computador e
obtida por meio da distribuicao de seus recursos (mem oria principal, tempo de
processador, impressora, espaco em disco, etc.) entre os programas. Uma uti-
lizac
ao mais conveniente e obtida escondendo-se do programador detalhes do
hardware, em especial os perifericos. Para atingir esses objetivos, o sistema op-
eracional oferece uma serie de servicos como: gerencia de mem oria, gerencia do
processador, mem oria virtual, sistema de arquivos, sistema de entrada e sada.
A arquitetura de um sistema operacional corresponde `

a imagem que o usu
ario
tem do sistema, a forma como ele percebe o sistema. Esta imagem e definida
44
pela interface por meio da qual o usu ario acessa os servicos do sistema opera-
cional. Essa interface e formada pelas chamadas de sistema e pelos programas
de sistema.
Os programas solicitam servicos ao sistema operacional por meio das chamadas

de sistema que transferem a execucao dos programas para o sistema operacional.
A parte do sistema operacional respons avel para implementar as chamadas de
sistema e normalmente chamadas de n ucleo ou kernel. Os principais compo-
nentes do kernel de qualquer sistema operacional s ao a gerencia de processador,
gerencia de memoria, sistema de arquivos e gerencia de entrada e sada.
Os programas de sistemas, algumas vezes chamados de utilit arios, s

ao pro-
gramas normais executados fora do kernel do sistema operacional. Eles imple-
mentam tarefas b asicas para utilizac
ao do sistema e muitas vezes sao confun-
didos com pr oprio sistema operacional. Exemplos de programas de sistemas
s
ao os utilit
arios para manipulac ao de arquivos, listar arquivos, imprimir ar-
quivos, trocar nome de arquivos, data, hora e etc. O programa de sistema mais
importante e o interpretador de comando. Sua tarefa e receber comandos e
execut
a-los. Esses comandos podem ser enviados de forma textual ou por meio
de uma interface gr afica de usu
ario (GUI).
O sistema operacional n ao resolve problemas do usu

ario final. Somente
quando ocorre algum evento especial que o sistema operacional e ativado. Dois
tipos de eventos ativam o sistema operacional: uma chamada de sistema ou uma
interrupc
ao de periferico.
Os sistemas operacionais podem ser classificados segundo in

umeros criterios,
dentre os quais os mais comuns s
ao:
N
umero de usu
arios
Monousu arios: projetados para suportar um u
nico usu
ario. Exemp-
los de desse tipo de sistema s
ao o MS DOS, Windows 3x, Windows
9x, etc;
Multiusu
arios: projetados para suportar v
arias sess
oes de usu
arios.
Exemplos desse sistema s
ao Windows NT, UNIX, etc;
N
umero de tarefas
Monotarefa: capazes de executar apenas uma tarefa de cada vez. Por

exemplo, o MS DOS, etc;

Multitarefa: capazes de executar v
arias tarefas simultaneamente,
como uma compilacao e um processamento de texto. Por exemplo,
Windows, Unix, etc;
Tipo de servico oferecido ao usu

ario
Sistemas de processamento em lote (batch);
Sistemas de tempo compartilhado (time sharing);
Sistemas de tempo real (real time);
45
Sistemas Mainframes;
Sistemas desktop;
Sistemas distribudos;
Sistemas handheld;
Sistemas paralelos.
4.2 Conceitos B
asicos
4.2.1 Multiprogramac
ao
A multiprogramac ao torna mais eficiente o aproveitamento dos recursos do com-
putador. Isso e conseguido por meio da execuc ao simult
anea de varios progra-
mas. Em um sistema multiprogramado diversos programas s ao mantidos na
memoria ao mesmo tempo.
A ideia da multiprogramac ao e aproveitar o tempo ocioso do processador

durante as operacoes de entrada e sada, ou seja, enquanto o periferico executa
o comando enviado, o sistema operacional inicia a execuc ao de outro programa.
Isso faz com que exista uma maximizac ao do uso do processador e da mem oria.
Em um ambiente monoprogramado, o processador ficaria parado durante a re-
alizac
ao do acesso a um periferico.
4.2.2 Processo
Um processo pode ser definido como um programa em execuc ao. O processo e
considerado um elemento ativo, pois altera o seu estado `
a medida que executa
um programa. E o processo que realiza as chamadas de sistema.
Em muitos sistemas operacionais os processos s ao criados por outros pro-

cessos, por meio de chamada de sistema. Nesse caso, e possvel definir uma
hierarquia de processos. O processo que faz a chamada de sistema e chamado
de processo pai e o processo criado e chamado de processo filho. Um mesmo
processo pai pode estar associado a v
arios processos filhos. Os processos filhos,
por sua vez, podem criar outros processos.
Durante a sua execucao, um processo passa por diversos estados, refletindo

o seu comportamento din amico, isto e, sua evoluc

ao no tempo. Os possveis
estados para um processo s ao: criac
ao (new), apto (ready), executando (run-
ning), bloqueado (blocked) e terminado (exit). A figura 4.2 mostra esses cincos
estados e as transic
oes do processo entre eles.
No estado New um novo processo e criado. Apos ser criado, o processo entra
em um ciclo de processador. Ele precisa do processador para executar, mas o
processador podera estar ocupado com outro processo, ele dever a esperar. Di-
versos processos podem estar no nesse mesmo estado. Nesse caso, e necess ario
manter uma fila com os processos aptos a ganhar o processador. Essa fila e
chamada de fila de aptos (ready queue). No estado New, o sistema operacional
46
Figura 4.2: Ciclo de vida dos processos
aloca recursos para o processo, mas n

ao existe uma garantia de que o processo
ser
a executado.
Os processos na fila do processador est

ao no estado Ready. Um unico pro-
cesso ocupa o processador a cada instante. O processo que ocupa o processador
est
a no estado Running. Neste estado processo pode realizar as chamadas de
sistema. Enquanto o sistema espera pelo termino da chamada de sistema, o
processo est
a no estado Blocked.
O processo fica no estado Blocked ate ser atendido. Com isso, o processador
fica livre. O sistema operacional seleciona outro do processo da fila de aptos
para receber o processador. O estado Exit indica que o processo terminou sua
execucao ou foi abortado.
A mudanca de estado de qualquer processo e iniciada por um evento. Esse

evento aciona o sistema operacional, que ent
ao altera o estado de um ou mais
processos. O evento pode ser uma chamada de sistema ou uma interrupc ao de
hardware.
Alguns outros caminhos s ao possveis no grafo de estado. Por exemplo, pode

ocorrer de nenhum processo na mem oria principal est
a no estado Ready, pois
todos estao aguardando uma operac ao de entrada e sada. Nesse caso, o sistema
operacional realiza o swap (mover todo ou parte de um processo da mem oria
para o disco) de um dos processos bloqueados para disco, e coloca numa fila
de processo suspensos. O estado para essa situac ao e o Suspend. Quando a
operac
ao de entrada e sada de um dos processos e finalizada, o sistema opera-
cional tr
as do disco o processo da fila de suspenso colocando no estado de Ready.
4.2.3 Interrup
coes
O mecanismo de interrupc ao constitui a base de operac
ao de um sistema mul-
tiprogramac ao. O mecanismo de interrupc ao permite que o controlador de
periferico chame a atenc ao do processador. A func ao basica do controlador
de periferico e conectar o dispositivo em questao ao processador.
Uma interrupcao sempre sinaliza a ocorrencia de algum evento. Quando

ela acontece, desvia a execucao da posic
ao atual de programa para uma rotina
47
especfica. Essa rotina, respons

avel por atender a interrupcao e chamada de
tratador de interrupc
ao. O tratador realiza as ac
oes necess
arias em func
ao da
ocorrencia da interrupc
ao.
Em computador podem existir diversos controladores capazes de gerar inter-

rupc
oes. A forma mais simples de identificar a origem da interrupc
ao e associar
a cada controlador um tipo diferente de interrupc
ao. Por exemplo, cada tipo de
interrupc
ao e identificado por um n
umero.
Existem momentos que um programa n ao pode ser interrompido enquanto

realiza uma tarefa crtica. Para isso, o processador possui instruc
oes para habil-
itar e desabilitar as interrupc
oes. Enquanto as interrupcoes estiverem desabil-
itadas, elas ser
ao ignoradas pelo processador. Elas n ao s
ao perdidas, apenas
ficam pendentes. Quando o programa tornar a habilitar as interrupc oes, elas
ser
ao imediatamente atendidas pelo processador.
Interrupc
oes de software, tambem chamadas de traps, s ao causadas pela ex-
ecuc
ao de uma instruc ao especfica para isso. O efeito e semelhante a uma
chamada de sub-rotina, pois o pr oprio programa interrompido e quem gera a
interrupc
ao. O maior uso para interrupc oes de software e a implementac ao
de chamadas de sistemas, por meio das quais os programas solicitam servicos
ao sistema operacional. N ao e possvel desabilitar as interrupc
oes de software,
mesmo porque n ao e necess
ario.
Existe uma terceira classe de interrupcoes geradas pelo pr

oprio processador.
Sao as interrupc
oes por erro, muitas vezes chamadas de interrupcoes de excec
ao.
Elas acontecem quando o processador detecta algum tipo de erro na execuc ao do
programa. Por exemplo, uma divis ao por zero, um acesso a posic
ao de mem oria
invalido, etc.
4.2.4 Threads
Uma thread nada mais e que um fluxo de execuc
ao. Na maior parte das vezes,
cada processo e formado por um conjunto de recursos mais uma u
nica thread.
A ideia do multithreading e associar v

arios fluxos de execuc
ao (varias threads)
a um unico processo. Em determinadas aplicac oes, e conveniente disparar varias
threads dentro de um mesmo processo (programac ao concorrente). E importante
notar que as threads existem no interior de um processo, compartilhando entre

elas os recursos de processo, como espaco de enderecamento, c odigo e dados.
Devido a essa caracterstica, a gerencia de threads (criac ao, destruic
ao, troca
de contexto, sincronizacao) e mais leve quando comparada com processos. O
chaveamento entre duas threads de um mesmo processo e muito mais r apido
que o chaveamento entre dois processos. Em func ao disso, threads sao muitas
vezes chamadas de processos leves.
48
4.3 Escalonamento de Processos

Os mecanismos de gerenciamento de processador visam permitir que varios pro-
cessos compartilham o processador de forma aumentar a Utilizac
ao, aumentar
o Throughput, diminuir o Tempo de Resposta e o Tempo Total de Execuc ao.
Estas s
ao as principais metricas de desempenho de um sistema operacional no
que diz respeito `
a gerencia de processador.
Para alcancar bons resultados, os sistemas operacionais empregam v arias

polticas de escalonamento para determinar qual processo tomara posse do pro-
cessador em um determinado instante. Essas polticas s ao os chamados Al-
goritmos de Escalonamento. Exemplo de algoritmos de escalonamento s ao:
First In First Out (FIFO), Prioridades, Round-Robin, Shortest Job First (SJF),
Multiplas Filas com Realimentacao, entre outras.
A parte do sistema operacional responsavel por escolher qual o processo

tomara posse do processador em um determinado instante e o Scheduller, en-
quanto o responsavel por entregar o processador de fato a um processo e o
Dispatcher.
o Dispatcher quem realiza o chaveamento de contexto, que consiste em

E
salvar o estado dos registradores do processo que deixar
a o processador e car-
regar os registradores para o novo processo.
O algoritmo FIFO e o mais simples e de implementac ao mais f

acil. No en-
tanto, n
ao e dos mais eficiente no quesito tempo de resposta. Caso um processo
muito grande tome posse do processador, outros processos podem ter que es-
perar um tempo muito longo ate que possam executar.
O algoritmo Shortest Job First d a posse do processador ao processo que

gastar a menos tempo executando. O tempo de resposta medio e otimizado em
relac
ao ao FIFO, no entanto, essa poltica n
ao pode ser implementada de forma
perfeita uma vez que nao e possvel determinar quanto tempo um processo gas-
tar a no processador na proxima vez em que tomar posse. Implementac oes do
SJF estimam esse tempo utilizando informac oes passadas do processo.
Os algortimos Round-Robin consistem em dividir o tempo de processamento

em fatias de tempo chamadas time slots. Cada processo na fila de prontos tem
direito de executar durante um perodo de tempo fixo antes de perder a posse
do processador. Um problema neste algoritmo e a necessidade de determinar a

fatia de tempo ideal, de forma que a impress
ao de paralelismo na execuc
ao n
ao
seja perdida. Uma fatia de tempo muito pequena,por exemplo, pode fazer com
que o tempo gasto com chaveamento de contexto diminua a performance.
Filas de Prioridades s
ao a base das polticas de escalonamento nos sistemas
operacionais modernos. A cada processo e associada uma prioridade. O pro-
cesso de maior prioridade e quem toma a posse do processador no momento
oportuno. Uma variante dos algoritmos de prioridades pura, s ao os os algo-
ritmos de Prioridade com Preempc ao. Neste esquema, um processo da fila de
prontos que tenha prioridade maior que o processo em execuc ao pode tomar
49
posse do processador antes do processo em execuc

ao terminar de executar.
Na verdade, nos sistema operacionais, n

ao s
o um algoritmo de escalonamento
e utilizado na gerencia de processador. Usualmente, esse algoritmos s ao com-
binados de forma melhorar o desempenho do sistema. Algoritmos de m ultiplas
filas com realimentac
ao s
ao exemplos de combinacao de varias polticas. Esses
algoritmos permitem que seja dado um tratamento adequado ` a um determinado
processo de acordo com o seu comportamento.
Em gerencia de processador existem tambem os conceitos de execuc

ao em
Background e Foreground. Processos em background s ao geralmente s
ao aque-
les que est
ao rodando com uma prioridade muito baixa, necessitam de muito
pouco input e geram tambem um mnimo de output. Processos em foreground
funcionam da forma oposta.
O escalonador respons
avel por determinar qual processo receber
a o direito de
executar e chamado Escalonador de Curto Prazo. Existem tambem os escalon-
adores de Longo e Medio Prazo. O escalonador de Medio Prazo e parte por
exemplo do processo swapper e esta intimamente ligado a gerencia de mem oria,
enquanto o escalonador de longo prazo determina quando um processo novo
e de fato admitido no sistema para disputa dos recursos. E o escalonador de
longo prazo quem determina o grau de multiprogramac ao do sistema e tambem
e conhecido como Job Scheduller.
4.4 Entrada e Sada

Uma das atribuic oes dos sistemas operacionais e realizar a gerencia de perifericos,
tambem conhecida como gerencia de entrada e sada. Os perifericos s ao dispos-
itivos que permitem que o computador se comunique com o mundo externo. A
primeira preocupac ao dos sistemas operacionais no que diz respeito a gerencia
de E/S e a forma de comunicac ao que ser
a utilizada, que pode ser serial ou
paralela. As tres formas b asicas de se implementar o controle de perifericos s ao:
E/S programada: O controle dos estado da operac ao de E/S e feito atraves

de loops de status. A responsabilidade e do programador; A tecnica uti-
lizar o estado da operacao de E/S utilizada E/S programada e conhecida
como polling;
Interrupc
oes: Os perifericos chamam a atenc ao do processador atraves
de um sinal de hardware. Cabe ao processador identificar, priorizar e
mascarar as interrupc
oes geradas pelos perifericos;
Acesso Direto ` a Mem oria (DMA): Em situac oes em que o volume de dados
e muito grande, utiliza-se esta tecnica para permitir que perifericos tenham
acesso direto a mem oria sem a necessidade da intermediac ao por parte do
processador.
O localizac
ao dos perifericos do ponto de vista da arquitetura do sistema
pode ser feita de basicamente de duas maneiras: Mapeamento em Mem oria e
50
Espaco de E/S. Os drivers de dispositivos consistem em uma camada superior

ao hardware e tem por objetivo esconder as diferencas entre dispositivos de
mesmo tipo.
Existe tambem a necessidade de se empregar tecnicas de escalonamento de

E/S de forma otimizar o atendimento das requisic
oes feitas aos perifericos. Nos
discos magneticos, por exemplo, sao utilizados algoritmos de escalonamento
como:
FCFS: First Come Fisrt Served. Atende as requisic

oes na ordem de
chegada;
SSTF: Shortest Seek Time First. Atende primeiro as requisic

oes que ne-
cessitam de menor tempo de seek (seek time e o tempo necess ario para
mover o cabecote para a trilha adequada);
SLTF: Shortest Latency Time First. Atende primeiro as requisic oes de
menor latencia (latencia e o tempo necess
ario para localizar um setor
dentro de uma trilha do disco. Diretamente relacionado com a velocidade
de rotac
ao do disco.);
Scan: Varre o disco na direc
ao radial atendendo requisic
oes. S
o atende
requisic
oes em um sentido;
CScan: Similar ao Scan, porem atende requisic

oes na subida e na descida.
Alem de polticas de escalonamento de E/S, tambem s ao utilizadas tecnicas

de Buffer e Cache para aumentar o desempenho. A tecnica empregada para
realizar a alocac
ao e liberac
ao de recursos e conhecida como Spooling. A gerencia
de perifericos tambem se responsabiliza pelo controle de acesso aos perifericos e
tratamentos de erros.
4.4.1 Camadas do subsistema de Entrada e Sada

O objetivo do subsistema de entrada e sada e padronizar ao m aximo as rotinas
de acesso aos perifericos de forma a reduzir o n umero de rotinas de entrada e
sada. Para isso, o subsistema de entrada e sada e organizado em uma estrutura
de quatro camadas: hardware dos dispositivos de entrada e sada, os drivers, a
E/S independente de dispositivo e E/S nvel de usu ario. A figura 4.3 mostra
essas camadas.
A camada inferior de software (drivers) e composta por um conjunto de

modulos de software implementados para fornecer os mecanismos de acesso a
um dispositivo de entrada e sada especfico. A camada de software de E/S
independente do dispositivo implementa procedimentos e func oes gerais a todos
os dispositivos de entrada e sada como: escalonamento de E/S, denominac ao,
bufferizac
ao, cache de dados, alocac
ao e liberac
ao, direitos de acesso e tratamen-
tos de erro. A E/S nvel de usu ario e uma interface de programac ao associada
as bibliotecas de entrada e sada, ou aplicativos de desenvolvimento. E
` impor-
tante notar que as bibliotecas de entrada e sada n ao fazem parte do sistema
operacional.
51
Figura 4.3: Camadas do Subsistema de E/S
4.5 Ger
encia de Mem
oria
Umas das funcoes fundamentais de um sistema operacional moderno e realizar a
gerencia da mem oria principal do computador de forma permitir que os diversos
processos executem de forma eficiente e protegida. Quando o assunto e gerencia
de mem oria, dois conceitos b
asicos s
ao os de mem oria l
ogica e mem
oria fsica. Os
programas fazem referencia ` a enderecos l
ogicos que no momento da execuc ao s
ao
traduzidos em um endereco real chamado endereco fsico. As primeiras tecnicas
de traduc
ao de enderecos eram baseadas em registradores de base e limites.
Nos sistemas multiprogramados, e necess ario tambem implementar tecnicas

para que os diversos programas possam utilizar a mem oria ao mesmo tempo. Ini-
cialmente, a mem oria era dividida em particoes de tamanho fixo. Dois problemas
decorrentes desta tecnica sao conhecidos como Fragmentac ao Interna e a Frag-
mentacao Externa. A fragmentac ao interna ocorre quando um programa aloca
uma particao de mem oria que excede a quantidade necess aria. O espaco exce-
dente naquela particao e desperdicado. A fragmentac ao externa ocorre quando
apesar da quantidade total de mem oria ser suficiente, n
ao existe uma particao
contgua capaz de atender as necessidades de um programa.
Para solucionar o problema da fragmentacao interna, foi criado o mecanismo

de particionamento din amico, no qual um programa aloca somente a quantidade
exata de mem oria. No entanto, esse metodo aumenta a fragmentac ao externa
uma vez que permite o aparecimento de lacunas pequenas demais para serem
utilizadas por algum programa. Neste metodo de particionamento s ao utilizadas
v
arias tecnicas de preenchimento de lacunas. Exemplos s ao: First-Fit, Best-Fit,
Worst-Fit e Circular-Fit. Para evitar o aparecimento de lacunas muito peque-

nas, foi criada uma tecnica chamada Par agrafo, que consiste em determinar a
menor unidade de alocac ao de mem oria.
Todas as tecnicas apresentadas ate aqui levam em considerac ao o fato de

que os programas devem ocupar areas contguas de mem oria. Os sistema op-
eracionais modernos supriram esta necessidade atraves da tecnica de Paginac
ao.
Aqui aparecem os conceitos de p aginas l

ogicas e p
aginas fsicas, semelhantes
aos de enderecos l
ogicos e fsicos. Neste contexto, o endereco l ogico e formado
52
por duas partes que sao o n

umero da p agina mais o deslocamento dentro dela.
Existe tambem a necessidade de traduzir uma p agina l
ogica em uma pagina
fsica. A Tabela de Paginas e a respons
avel por essa tarefa. Existem v
arias
formas de implement a-la.
A primeira preocupac ao e onde armazenar a tabela de paginas. Em sistemas

com tabelas muito pequenas, as tabelas de p aginas podem ser armazenadas
em registradores, no entanto, em geral a tabela de p aginas e armazenada na
pr opria mem oria principal utilizando registradores (PTBR e PTBL) para in-
dicar a posic ao da tabela na mem oria. Um problema inerente a esta tecnica
e a necessidade de se acessar a mem oria duas vezes quando se deseja ler um
dado. Um acesso a tabela de p aginas e outra ao dado em si. Para minimizar
este problema e utilizado um mecanismo chamado Translation LookAside Buffer
(TLB). O TLB consiste em uma mem oria de r
apido acesso que armazena partes
da tabela de p aginas. Quando a traduc ao de uma pagina logica em uma p agina
fsica e possvel utilizando apenas o TLB, e dito que ocorreu um HIT, caso
contr ario dizemos que ocorreu um MISS.
A tecnica de Segmentac ao e utilizada para implementar a protecao de en-

derecos de mem oria utilizados por um processo. Usualmente isso e feito atraves
de registradores de limite. Quando um processo tenta acessar uma regi ao de
mem oria protegida ocorre uma falha de segmentac ao (Segmentation Fault). Esta
tecnica nao deve ser confundida com a tecnica de segmentac ao de mem
oria pre-
sente em algumas arquiteturas, onde a mem oria e dividida em partes como
Segmento de Dados, Segmento de C odigo, Pilha etc.
O Swapping e uma outra tecnica utilizada para gerenciamento de mem oria.

Nesta tecnica, um processo e suspenso e todas suas paginas de mem oria s
ao
descarregadas para o disco (swap-out), liberando a mem oria para que algum
outro processo possa executar. Quando processo suspenso pode voltar para
mem oria, as p
aginas do processo sao novamente carregadas para a mem oria
(swap-in). O swapper e responsavel pelo swap-in e swap-out.
Na tecnica de paginac
ao pura, o processo n ao precisa mais ocupar um tre-
cho contguo de mem oria, no entanto, ainda e necessario que todas as pagina
de um processo estejam carregadas na mem oria no momento da execuc ao. Uma
evoluc
ao do esquema de paginacao e a tecnica de Mem oria Virtual. Mem oria
Virtual consiste em um esquema de paginac ao sob demanda, no qual somente
as p
aginas necessarias para a execuc
ao de um processo s ao carregadas para a
mem oria.
Alem de aumentar o desempenho do sistema, esta tecnica permite que ex-

istam programas com espaco de enderecamento l ogico maiores. Para indicar
se uma p agina se encontra ou n ao carregada na mem oria em um determinado
instante, e utilizado um bit adicional para cada entrada da tabela. Quando um
processo tenta acessar uma pagina que n ao est
a carregada na mem oria e dito
que ocorreu um page-fault. O processo e ent ao suspenso e ate que esteja pronto
para executar novamente ocorre a seguinte seq uencia de eventos:
53
1. Alocac
ao de uma p
agina fsica;
2. Localizac
ao da P
agina Fsica no Disco;
3. Leitura da P
agina no Disco;
4. Atualizac
ao da Tabela de P
aginas;
5. Processo vai para fila de pronto.
O respons avel por carregar a p agina solicitada e o pager. Para carregar

uma nova p agina l
ogica para mem oria muitas vezes e necessario descarregar
uma pagina para o disco. Os algoritmos de substituic ao de paginas s
ao os
respons
aveis por decidir qual p
agina sera escolhida para deixar a memoria. Ex-
emplos de algoritmos de substituic
ao de pagina sao:
FCFS: Escolhe a p
agina que est
a a mais tempo na mem
oria;

Otimo: Escolhe a p
agina que vai ser acessada mais remotamente no futuro
(n
ao e implementavel);
LRU: Escolhe a que a mais tempo n

ao e acessada (obs: algoritmo imple-
mentado por hist
orico de bits);
Second Chance: Organiza p

aginas em forma de um fila circular e utiliza
bits de controle.
O Trashing e a situac
ao em que um processo possui poucas p
aginas fsicas
e o tempo gasto em page-faults e muito alto, predominando no tempo total de
processamento. Uma forma de solucionar este problema e utilizar a tecnica de
swap para permitir que o processo possa executar de forma satisfat
oria.
4.6 Sistemas de Arquivos

O sistema de arquivos e a parte do sistema operacional mais visvel para os
usuarios. Durante todo tempo, os usu arios manipulam arquivos contento tex-
tos, planilhas, desenhos, figuras, jogos e etc. Este fato exige que o sistema
operacional apresente uma interface coerente e simples. Para isso, o sistema de
arquivos implementa o conceito de arquivo e diretorio.
4.6.1 Conceitos b
asicos sobre arquivos
Um arquivo e um recipiente no qual dados s ao armazenados. Em geral, cada
arquivo contem um conjunto de dados que possui algum significado pr atico para
o usuario ou para o sistema. Um arquivo pode conter um programa execut avel,
um m odulo de um programa fonte, um texto, uma figura, etc. Cada arquivo e
identificado por um nome, o qual permite que o usu ario faca referencias a ele.
Alem do nome, cada arquivo possui uma serie de outros atributos que s ao man-
tidos pelo sistema operacional como tipo de conte udo, tamanho, data e hora
do ultimo acesso, data e hora da u
ltima alterac
ao, lista de usu arios que podem
54
acessar o arquivo, etc.
Em geral, o sistema operacional suporta diversas operac oes sobre os arquivos,

como criac
ao e destruic
ao do arquivo, leitura e alterac
ao do conteudo, troca de
nome do arquivo, etc. Essas operac oes correspondem a chamadas de sistema
que os programas de usu ario podem usar para manipular os arquivos.
Em sistemas multiusu arios, e importante controlar o acesso aos arquivos.

Sistemas operacionais multiusu arios implementam mecanismos que permitem
controlar quais os usu
arios podem fazer o que em quais arquivos.
O controle de acesso inicia com a identificac

ao dos usuarios por meio de um
c
odigo de usu ario e uma senha. A partir do momento que a identificac ao do
usu
ario e aceita, todos os processos disparados a partir do terminal em quest ao
passam a ter os direitos de acesso associados com aquele usu possvel
ario. E
associar a cada arquivo uma lista de usu arios e direitos de acesso. A forma
usual e permitir que apenas o usu ario que criou o arquivo possa alterar a lista
contendo os direitos de acesso do arquivo.
A forma como os dados sao dispostos dentro de um arquivo determina sua

estrutura interna. Cada tipo de arquivo possui uma estrutura interna apropri-
ada para a sua finalidade. Por exemplo, arquivos de texto s
ao organizados em
linha ou par
agrafos. Arquivos que contem programas executaveis s
ao organiza-
dos em termos de segmento de c odigo e segmentos de dados.
Em geral, os sistemas operacionais ignoram a estrutura interna dos arquivos.

Para o sistema operacional, cada arquivo corresponde a uma seq uencia de bytes,
cujo significado e conhecido pelo usu ario que o criou. A unica excecao sao os
arquivos que contem programas execut aveis. Nesse caso, a estrutura interna e
definida pelo proprio sistema operacional. Como o conceito de tipo de arquivo e
u
til para os usuarios, muitos sistemas operacionais suportam nomes de arquivos
onde o tipo e indicado. A forma usual e acrescentar extens ao de nome que
identifique o tipo de arquivo em quest ao.
O metodo de acesso diz respeito ` a forma como o conte udo de um arquivo

e acessado. O metodo de acesso mais simples e o seq uencial. Este metodo e
usado pelos compiladores, para a impress ao de um arquivo, etc. Outro metodo
de acesso e o acesso relativo. Neste metodo, o programa inclui na chamada de
sistema qual posicao do arquivo a ser lida. As posic
oes do arquivo s
ao numer-
adas a partir de 0 (ou a partir de 1 em alguns sistemas), sendo que cada posic
ao
corresponde a um byte.
Em muitos sistemas operacionais, existe o conceito de posic ao corrente no

arquivo. Nesse caso, a chamada de sistema para leitura ou escrita n ao informa
uma posic
ao. Essa sempre acontece a partir da posic
ao corrente. O sistema op-
eracional tambem permite que o programa altere a posicao corrente do arquivo
por meio de uma chamada de sistema.
Existem outros metodos de acesso mais sofisticados, tais como seq

uencial
indexado, indexado, direto, etc. Tais metodos de acesso s
ao implementados a
55
partir dos metodos seq

uencial e relativo.
4.6.2 Implementa
c
ao de arquivos
A forma basica de implementar arquivos e criar, para cada arquivo no sistema,
um descritor de arquivo. O descritor de arquivo e um registro no qual s ao
mantidas as informac oes a respeito do arquivo. Essas informac oes incluem os
seus atributos, alem de outros dados que nao s
ao visveis aos usu
arios, mas s
ao
necess
arios para o que o sistema operacional implemente as operac oes sobre os
arquivos.
Um descritor de arquivo contem as seguintes informac oes: nome do arquivo,

extensao do nome do arquivo, tamanho em byte, data e hora do u ltimo acesso,
data e hora da ultima alteracao, identificac
ao do usu
ario que criou o arquivo, lo-
cal no disco onde o conteudo do arquivo foi alocado, etc. A forma usual e manter
o descritor de um arquivo na mesma partic ao onde est
a o seu conteudo. Dessa
forma, esse disco podera ser ate mesmo fisicamente removido de um computador
e conectado a outro. Os arquivos nele poder ao ser acessados normalmente no
novo computador.
O descritor e acessado a cada operac

ao de escrita ou leitura para determinar
a localizac
ao no disco dos dados a serem escritos ou lidos. Para tornar mais
r
apido o acesso aos arquivos, o sistema de arquivos mantem na mem oria uma
tabela contendo todos os descritores dos arquivos em uso. Quando um arquivo
entra em uso, o seu descritor e copiado do disco para a mem oria. Quando o ar-
quivo deixa de ser usado, o seu descritor em mem oria pode ter sido alterado em
relac
ao `
a c
opia do descritor em disco. Nesse caso, o sistema de arquivos escreve
o descritor atualizado que est a na mem oria sobre a c opia original do descritor
em disco. A maioria dos sistemas operacionais exige que os pr oprios programas
informem quando um arquivo entra em uso e quando ele n ao e mais necess
ario.
Para tanto, existem as chamadas de sistema open e close. Tambem e u til passar
como par ametro o tipo de acesso que sera feito, isto e, leitura (READONLY ou
RD) ou leitura e escrita (READWRITE ou RW).
O sistema de arquivos utiliza uma Tabela de Descritores de Arquivos Aber-

tos (TDAA) para manter em mem oria os descritores dos arquivos abertos. A
TDAA mantem informac oes relativas aos arquivos abertos por todos os proces-
sos no sistema. Isso e necessario porque normalmente e permitido que v arios
processos abram um mesmo arquivo simultaneamente. Cada entrada armazena

uma copia do descritor do arquivo mantido em disco, assim como algumas in-
formac
oes adicionais, necess
arias apenas enquanto o arquivo est a aberto. Por
exemplo, numero de processos utilizando o arquivo no momento.
As entradas da TDAA armazenam informac oes que n ao variam conforme

o processo que est
a acessando o arquivo. Entretanto, existem informac oes di-
retamente associadas com o processo que acessa o arquivo. Essas informac oes
n
ao podem ser mantidas na TDAA, pois como v arios processos podem aces-
sar o mesmo arquivo, elas possuir
ao um valor diferente para cada processo. Um
exemplo de informac
ao que depende do processo e a posic
ao corrente no arquivo.
56
Uma soluc ao tpica e criar, para cada processo, uma Tabela de Arquivos
Abertos por Processo (TAAP). Cada entrada ocupada na TAAP corresponde a
um arquivo aberto pelo processo correspondente. No mnimo, a TAAP contem
em cada entrada as seguintes informac oes: posic
ao corrente no arquivo, tipo de
acesso (leitura ou leitura e escrita) e apontador para a entrada correspondente
na TDAA. A figura 4.4 mostra as tabelas TDAA e TAAP. Toda TDAA como
as TAAP devem ficar na mem oria do sistema operacional, fora do acesso dos
processos de usuario.
Figura 4.4: TAAP vs. TDAA
Uma vez aberto um arquivo, o processo utiliza chamadas de sistema com

read e write para acessar o seu conte
udo. Nao e necess
ario, nem conveniente,
que a cada chamada de sistema, o processo forneca novamente o nome do ar-
quivo. Como resultado de um open com sucesso, o sistema de arquivos retorna
para o processo o n
umero da entrada na TAAP associada com o arquivo aberto.
Dessa forma, nas chamadas de sistemas ap os o open, o processo indica o ar-
quivo atraves do n
umero de sua correspondente entrada na TAAP. A partir da
TAAP, o sistema de arquivos pode imediatamente localizar o descritor no ar-
quivo TDAA. Muitos sistemas operacionais chamam esse n umero de handle do
arquivo.
Existem duas funcoes importantes que o sistema de arquivos deve realizar

na implementac ao das chamadas de sistema read e write. S ao elas a montagem
e desmontagem de blocos l ogicos e a localizac
ao dos blocos l
ogicos no disco. Es-
sas func
oes s
ao implementadas baseando-se em tres formas b asicas de alocac
ao
de arquivos: alocacao com areas contguas, alocacao encadeada e a alocac ao
indexada.
4.6.3 Cache de Sistema de Arquivos

Uma importante estrutura de dados presente na implementac ao de um sistema
de arquivos e a sua cache. A cache n ao oferece nenhuma funcionalidade nova,
isto e, a presenca ou ausencia de uma cache nao adiciona ou elimina nenhuma
57
func
ao, chamada de sistema ou operac
ao sobre arquivos. Entretanto, caches rep-
resentam um grande aumento no desempenho de qualquer sistema de arquivos,
pois o uso do disco tente a ser intenso em sistemas operacionais de prop osito
gerais. O objetivo do cache e manter na mem oria principal uma certa quanti-
dade de blocos do disco. Dessa forma, se algum bloco for requisitado para leitura
ou escrita, ele ser
a encontrado na memoria principal, evitando o acesso ao disco.
A cache do sistema de arquivos utiliza uma area da mem oria principal e e

controlada pelo sistema operacional. Na verdade, existem diversos locais onde
uma cache de disco pode ser mantida. E possvel haver uma cache global, uma
cache exclusiva para cada sistema de arquivos, etc.
A forma basica de operacao e bem simples. Toda vez que um bloco de disco
e necess
ario para leitura e/ou escrita, a cache e pesquisada. Se o bloco estiver
na cache, essa c
opia e usada. Se o bloco nao estiver na cache, ele e lido do disco,
colocado na cache e ent ao utilizado.
Uma quest ao importante e quando atualizar o disco apos um bloco presente

na cache ter sido alterado. Do ponto de vista de desempenho, o ideal e poster-
gar a atualizac
ao do disco ao maximo no sentido de minimizar as escritas em
disco. Por outro lado, caso ocorra uma pane do sistema, toda a informac ao na
cache ser
a perdida, o disco ficar
a desatualizado e, possivelmente, o sistema de
arquivos ficar
a corrompido. Existem diversas polticas que podem ser utilizadas.
Uma cache de sistema de arquivo pode possuir milhares de blocos, o que

torna inviavel uma pesquisa seq
uencial da mesma para localizar determinado
bloco. Dada a natureza din amica dessa estrutura e sua import ancia para o de-
sempenho do sistema como um todo, uma tabela hash e utilizada. O sistema de
arquivos fornece o n
umero da partic
ao e o n
umero do bloco, e uma func ao hash e
utilizada para determinar o endereco do bloco na cache, caso ele esteja na cache.
Eventualmente, a cache pode se encontrar completamente ocupada, sendo

necess ario liberar espaco para algum outro bloco. A soluc ao tpica e escolher
um bloco da cache, atualizar o seu conte udo no disco se necess
ario, declarar esse
bloco da cache como livre e utiliz a-lo para hospedar um novo bloco de disco. A
poltica para escolher o bloco da cache a ser liberado geralmente e a LRU (Least
Recently Used ).
4.6.4 Gerenciamento do espaco livre

Uma das tarefas do sistema de arquivos e gerenciar o espaco livre nos discos.
Em outras palavras, determinar quais setores do disco est ao livres e podem
ser alocados para aumentar o tamanho de um arquivo. Uma forma simples de
gerenciar o espaco livre em disco e por meio de um mapa de bits. A figura 4.5
mostra esse mecanismo.
Cada bit presente no mapa representa um bloco fsico do disco. Os bits sao
considerados numerados da direita para esquerda, isto e, o bit menos significa-
tivo do primeiro byte e o bit n
umero zero. Bit ligado indica bloco ocupado,
58
Figura 4.5: Mapa de bits para gerenciamento de espaco livre
e bit desligado indica bloco livre. O endereco do bloco representado por um

determinado bit e definido pela pr
opria posic
ao do bit dentro do mapa.
Para alocar mais um bloco fsico para um arquivo, basta percorrer o mapa
de bits ate encontrar um bit zero. O bit e ent ao ligado para indicar que o
respectivo bloco agora esta ocupado. Quando um arquivo e destrudo e seus
blocos liberados, basta desligar os bits correspondentes. O mapa de bits deve
ser mantido na mem oria principal para que a busca seja r
apida.
O espaco livre em disco tambem pode ser gerenciado por meio de uma lista
contendo os n umeros de todos os blocos fsicos livres (Lista de Blocos Livres).
Como essa lista e grande no caso de um disco quase vazio, ela deve ser mantida
no pr oprio disco. Para acelerar o processo de alocac ao e liberac
ao de blocos
fsicos, alguns blocos da lista sao copiados para a mem oria principal. Logo, so-
mente ser a necessario acessar o disco quando todos os enderecos de blocos livres
copiados para a mem oria principal tiverem sido alocados. Ou ainda, quando
remoc oes de arquivos liberarem blocos fsicos em tal quantidade que alguns blo-
cos de enderecos tenham que ser escritos em disco. Alguns sistemas operacionais
atualizam periodicamente a lista de enderecos em disco para minimizar a cor-
rupc ao do sistema de arquivos em caso de falha no computador.
4.6.5 Diret
orios
Os diret
orios s
ao as estruturas do sistema de arquivos que contem a informac ao
quais arquivos existem no disco. Um diret orio pode ser entendido como sendo
um conjunto de arquivos ou um conjunto de referencias a arquivos. Existem
diversas formas de estruturar os diret orios de um sistema. A mais simples e ter
um unico diretorio para o disco inteiro. Nesse caso, o diretorio corresponde a
uma lista de todos os (possivelmente milhares) arquivos do disco. Essa soluc ao,
conhecida como diret orio linear, e aceit
avel apenas para sistemas de arquivo
muito pequenos. Por exemplo, pode ser utilizada para discos flexveis de pe-
quena capacidade.
59
Para sistemas multiusu arios, o diret

orio linear e problem atico, pois os ar-
quivos de diferentes usu arios ficam misturados. Esse problema pode ser re-
solvido com uma estrutura de diret orios organizada em dois nveis. O diret orio
principal contem uma entrada para cada usu ario do sistema. Essa entrada n ao
corresponde a um arquivo, mas sim a um subdiret orio que, por sua vez, contem
os arquivos do usu ario correspondente. Tambem e necess ario criar no diret
orio
principal uma entrada para conter os arquivos do sistema. As entradas do di-
ret
orio principal s
ao usualmente chamadas de subdiret orios.
E possvel estender o conceito de subdiret

orios de tal forma que os usuarios
tambem possam criar livremente os seus pr oprios subdiretorios. Dessa forma,
cada usuario tem a liberdade de organizar os seus arquivos de forma lhe for
mais conveniente. O resultado e um sistema de diret orios organizado na forma
de
arvore conforme a figura 4.6.
Figura 4.6: Diret

orio organizado em forma de
arvore
Em um sistema de diret orios organizado na forma de arvore, qualquer ar-

quivo ou subdiret orio pode ser identificado de forma n ao ambgua por meio
do caminho (pathname) para atingi-lo a partir da raiz da arvore. Facilmente,
aarvore de diret orio cresce ate uma altura tal que passa a ser desconfort avel
fornecer sempre o caminho completo ate cada arquivo ou diret orio. O conceito
de diretorio corrente facilita a identificac
ao de arquivos nesse contexto. Dessa
forma, um arquivo pode ser identificado por seu caminho absoluto, que inicia a
raiz da
arvore, ou pelo seu caminho relativo, que inicia no diret orio corrente do
usuario em questao.
Uma flexibilidade adicional presente em muitos sistemas operacionais est a

na possibilidade de incluir o mesmo arquivo ou subdiret
orio em varios diret
orios.
Dessa forma, o mesmo arquivo passa a ter diversos nomes absolutos (mesmo na
arvore, cada arquivo possui diversos nomes relativos, uma vez que o caminho

relativo depende do diret orio corrente em quest
ao. Essa facilidade e denomi-
nada de link e efetivamente transforma a estrutura de diret orios em um grafo.
60
4.6.6 Implementa
c
ao de diret
orios
A forma mais simples de implementar diret orios e consider
a-lo como arquivos
especiais, cujo conteudo e manipulado pelo pr oprio sistema operacional. Dessa
forma, todo o mecanismo de alocac ao, liberac
ao e localizac
ao de blocos fsicos no
disco, disponvel para arquivos, tambem e usado para os diret orios. Diret orios
passam a ser arquivos cujo conte udo e definido pelo sistema operacional e cujo
acesso e controlado por parte do usuario.
Como diret orios s

ao implementados como arquivos, cada diret orio possui
tambem seu descritor. Os diret orios s
ao implementados como conjunto de de-
scritores de arquivos, ou conjuntos de enderecos de descritores de arquivos.
Quando diret orios s
ao implementados como conjunto de descritores de arquivos,
o conteudo de um diret orio corresponde aos descritores dos arquivos e dos sub-
diret
orios contidos naquele diret orio, conforme a figura 4.7. Nesse caso, o nome
do arquivo ou subdiret orio faz parte do seu descritor.
Figura 4.7: Diret

orios contendo descritores de arquivos
Outra possibilidade e separar um conjunto de blocos da partic ao para ar-

mazenar exclusivamente os descritores de arquivos e de subdiret orios. Esse
conjunto de blocos forma um vetor de descritores, no qual cada descritor pode
ser identificado pelo n
umero da partic
ao e pela posic
ao nesse vetor. Essa estru-
tura de dados forma o que e normalmente conhecido como um flat file system,
pois os descritores n
ao incluem nomes, n ao existe nenhuma estruturacao dos ar-
quivos em diretorios, apenas um diretorio u
nico (vetor) e arquivos identificados
pela posic
ao do vetor.
Em qualquer solucao, cada diretorio nada mais e que uma tabela. Existem
diversas implementac
oes possveis para tabelas que podem ser usadas na im-
plementac
ao de um diretorio. Entre elas, destaca-se a lista n
ao ordenada, lista
ordenada e a tabela hash.
4.7 Sistemas Operacionais Distribudos

Um sistema distribudo e uma colec
ao de computadores independentes que pare-
cem ao usu
ario como um u nico computador. Essa definic
ao implica hardware
61
formado por m aquinas autonomas e software fornecendo a abstrac

ao de uma
maquina u
nica. As principais vantagens s
ao:
Economicas: aproveitar m aquinas potencialmente ociosas; mais barato

v
arios processadores interconectados do que um supercomputador.
Distribuic
ao inerente: algumas aplicac
oes s
ao distribudas por natureza.
Toler
ancia a falhas: em caso de falha de uma m
aquina, o sistema como
um todo pode sobreviver, apresentando apenas uma degradac ao de de-
sempenho.
Crescimento incremental: o poder computacional pode ser aumentado

atraves da inclus
ao de novos equipamentos.
Flexibilidade: sistemas distribudos s
ao mais flexveis do que m
aquinas
isoladas, por isso muitas vezes sao utilizados ate mesmo que nao se es-
teja buscando desempenho. E essa flexibilidade que permite que varios
usuarios compartilhem dados e perifericos.
E as desvantagens:
Pouco software de alto nvel disponvel para sistemas distribudos.

Dificuldades para evitar acesso indevido (seguranca).
A rede de interconex
ao pode causar problemas ou n
ao dar vaz
ao a de-
manda.
Sistemas distribudos consistem de v arias CPUs interconectadas. No en-

tanto, ha v
arias formas diferentes no qual esse hardware pode estar organizado.
Dentre as v arias classificac
oes existentes, Flynn propoe uma taxonomia con-
siderando o n umero de fluxo de instruc oes e o n
umero de fluxo de dados.
SISD(Single Instruction Single Data): fluxo de instruc

oes e dados u
nico e
a caracterstica dos uniprocessadores tradicionais
MIMD(Multiple Instructions Multiple Data): caracteriza-se por v arios
processadores interconectados. Tanembaum apresenta a seguinte subclas-
sificac
ao, onde os dois primeiros s
ao definidos em relac
ao a organizac
ao da
mem oria e os dois u
ltimos em relac
ao a forma de interconex ao:
Multiprocessador: maquinas MIMD com mem oria compartilhada (um

u
nico espaco de enderecamento virtual compartilhado por todas as
CPUs).
Multicomputador: m aquinas que n
ao possuem mem oria compartil-
hada, isto e, cada processador possui sua mem
oria privada.
Barramento: um u nico cabo, rede, barramento ou outro meio que
conecte todas as maquinas. Analogia: TV a cabo.
Switch: existem cabos individuais conectando m
aquina a m
aquina,
com v
arios padr
oes possveis.
62
Outra classificac
ao: Fortemente acoplado(Tightly Coupled): comunicac ao
r
apida entre os processadores (grande n
umero de bits por segundo). Fracamente
acoplado(Loosely Coupled): atraso para troca de mensagem entre m aquinas e
alto.
Com a criac
ao de novas arquiteturas de computadores, surgiram novas de-
mandas de software e, em especial, novas func
oes exigidas ao S.O. Pode-se con-
siderar como uma boa classificacao da evoluc
ao dos Sistemas Operacionais a
tabela abaixo. A tabela 4.1 apresenta uma comparac ao entre as caractersticas
dos S.O modernos
Gerac
ao Sistema Caracterstica Objetivo
1a SO Centralizado Gerenciamento de Processos Gerenciamento de
Gerenciamento de Mem oria recursos
Gerenciamento de E/S Mem oria estendida
Gerenciamento de Arquivos Virtualidade
2a SO de Rede Acesso Remoto Compartilhamento de
Troca de Informac oes recursos
Navegacao na rede Interoperabilidade
3a SO Distribudo Vis
ao global do Sistema de Vis
ao de computador
arquivos,
Unico em sistema
Espaco de nomes de M ultiplos
Tempo, Seguranca Computadores
Poder Computacional Transparencia
4a SO Cooperativo Aplicac
oes Distribudas Trabalho cooperativo
Aut
onomo Abertas e Cooperativas Autonomia
Tabela 4.1: Sistemas Operacionais
4.7.1 Estrutura
cao de Sistemas Distribudos
Estrutura
cao baseada na distribui
c
ao fsica
Dentre os varios modelos baseados da distribuic ao fsica, encontram-se o modelo
hier
arquico, o do cache de CPU, o usu ario servidor e o modelo de conjunto de
processadores.
No modelo hier arquico, os computadores s ao dispostos em uma rede sob a
forma de arvore, de maneira que quanto mais pr oximos estiverem da raiz, mais
potentes dever ao ser. O computador da raiz tratar a, de forma geral, do sistema
como um todo, enquanto que os computadores distantes da raiz tratar ao de
tarefas especficas e especializadas.
O modelo de cache de CPU consiste na utilizac ao de computadores de menor

porte como elementos que interligam terminais com uma grande CPU. Nesse
caso, uma parte do processamento ser a executada no computador ligado ao
terminal, e a outra parte no computador central.
O modelo usu ario-servidor(cliente/servidor) surgiu na medida em que os
computadores pequenos, crescendo em potencia e tendo seus precos reduzidos,
diminuram gradativamente a import ancia do computador central do modelo
cache de CPU.
63
Estrutura
cao L
ogica
Modelo de processos:
Esses processos podem encapsular tanto elementos ativos com natureza, con-
sistindo dos programas referentes às atividades do sistema e do usu
ario quanto
elementos naturalmente passivos correspondendo aos recursos e suas respecti-
vas operac
oes, confinados em gerenciadores de recursos. A comunicac
ao entre os
processos, implementada pelo sistema operacional, pode ocorrer de duas formas:
Chamada remota de procedimento: este tipo de comunicac ao entre pro-

cessos e bastante dependente da linguagem usada para implementac ao
do sistema, devendo satisfazer suas restric
oes com relac
ao a chamada de
procedimento e a passagem de par ametros.
Troca explcita de mensagem: este j a e mais flexvel do que o anterior,

suas restric
oes est
ao relacionadas com a existencia de ligac
oes implcitas
ou explcitas entre os processos e com a interpretacao da mensagem.
Modelo de objetos:
O modelo de objetos baseia-se no encapsulamento das v arias partes de um sis-
tema em elementos denominados objetos que s ao estruturados de forma a apre-
sentarem um conjunto de operac oes respons
aveis pelo seu comportamento. Para
conseguir acessar um objeto, um processo deve ter capacidade de faze-lo, usando
o conhecimento do nome do objeto e a posse da autorizac ao para cessar algu-
mas ou todas as suas operac oes. Cada objeto distribudo nao opera sozinho. A
princpio ele e construdo para trabalhar com outros objetos e, para isso, precisa
de uma especie de barramento. Tais barramentos fornecem infra-estrutura
para os objetos, adicionando novos servicos que podem ser herdados durante
a construcao do objeto, ou mesmo em tempo de execuc ao para alcancar altos
nveis de colaboracao com outros objetos independentes. CORBA e um exemplo
de barramento.
64
Captulo 5
Principais Processadores de
Mercado
5.1 Processadores Intel

5.1.1 Famlia Pentium
Pentium 4
O processador Pentium 4 da Intel foi lancado em novembro de 2000, usando a
microarquitetura x86 de setima gerac
ao da Intel, chamada Netburst, que veio
com um pipeline muito longo com a intenc ao de permitir clocks mais altos.
Os processadores Pentium 4 podem encontrados em tres vers oes de n
ucleos:
Willamette, Northwood e Prescott.
Os primeiros modelos de Pentium 4 utilizavam soquete 423, que, como o

pr
oprio nome j
a sugere, possua 423 terminais. Depois foram lancados modelos
de Pentium 4 com soquete 478, que, apesar de possurem mais contatos do que
os modelos anteriores (soquete 423), eram fisicamente menores. Os modelos de
Pentium 4 atuais utilizam um novo tipo de soquete, chamado Soquete 775.
Willamette
Os primeiros modelos de Pentium 4 eram baseados no n ucleo Willamette,
que tinha 8 KB de cache L1 para dados; 12 KB de cache L1 para instrucao;
256 KB de cache L2; trabalhava externamente a 400 MHz (100 MHz trans-
ferindo quatro dados por pulso de clock); padr ao de pinagem soquete 423
e 478; clock interno de 1,30 a 2 GHz; suporte a instrucoes MMX (oferece
um modelo de execuc ao SIMD (Single Instruction Multiple Data, ou seja,
fluxo u
nico de instruc
oes e m
ultiplos de dados) simples, capaz de efetuar
processamentos de dados inteiros, empacotados em registros de 64 bits.
As instruc
oes MMX melhoraram a execuc ao das assim chamadas tarefas
multimdias, como codificar e decodificar vdeo), SSE (Streaming SIMD
Extensions) e SSE2; tecnologia de construcao de 180 nan ometro.
Northwood
Em seguida vieram os modelos de Pentium 4 baseados no n
ucleo North-
65
wood. Este nucleo e cerca de 60% menor do que o nucleo Willamette dev-
ido ao seu processo de fabricac
ao de 130 nan
ometros. O nucleo Northwood
possui 8 KB de cache L1 para dados; 12 KB de cache L1 para instruc ao;
512 KB ou 2 MB de cache L2; barramento externo rodando a 400 MHz,
533 MHz ou 800 MHz (100 MHz, 133 MHz e 200 MHz transferindo quatro
dados por pulso de clock, respectivamente); clock interno de 1,60 a 3,4
GHz; suporte a instrucoes MMX, SSE e SSE2. Alguns modelos possuem
suporte a tecnologia Hyper-Threading.
Prescott
O n ucleo Prescott e construdo com tecnologia de 90 nanometros e uti-
lizado nos processadores Pentium 4 modernos. Ele pode ser encontrado
com 16 KB de cache L1 para dados; 12 KB de cache L1 para instruc ao;
512 KB, 1 MB ou 2 MB de cache L2; trabalha externamente a 533 MHz
ou 800 MHz (133 MHz e 200 MHz transferindo quatro dados por pulso
de clock, respectivamente); com clock interno de 2,26 a 3,80 GHz; suporte
as novas instruc
` oes MMX, SSE, SSE2 e SSE3. Alguns modelos possuem
suporte a tecnologia Hyper-Threading, XD, EM64T, SpeedStep (permite
que o sistema operacional ajuste o clock do processador, diminuindo-o ao
executar aplicativos que exigem menos poder e economizando energia) e
a VT (Virtualization Technology ), originalmente conhecida como Van-
derpool. A tecnologia VT permite que um processador funcione como se
fosse varios processadores trabalhando em paralelo de modo a permitir
que v arios sistemas operacionais sejam executados ao mesmo tempo em
uma mesma m aquina. Embora o clock de um Prescott seja o mesmo de
um Northwood, alguns softwares de teste mostraram que um Northwood e
ligeiramente mais veloz que um Prescott.
Prescott 2M
O Pentium 4 Extreme Edition foi lancado em novembro de 2003 e foi o
primeiro processador para desktop a possuir o cache L3 integrado, carac-
terstica esta presente apenas em processadores voltados para o mercado
corporativo.
Este processador possui 2 MB de cache L3 sendo acessado na mesma
frequencia de operacao interna do processador. Os primeiros modelos de
Pentium 4 Extreme Edition eram baseados no n ucleo Gallatin, que tinha
8 KB de cache L1 para dados; 12 KB de cache L1 para instruc ao; 512 KB
de cache L2 e 2 MB de cache L3; trabalhava externamente a 800 MHz
e 1066MHz (200 MHz ou 266 MHz transferindo quatro dados por pulso
de clock, respectivamente); clock interno de 3,20 a 3,46 GHz; suporte ` as

instrucoes MMX, SSE e SSE2; tecnologia Hyper-Threading; tecnologia de
construc ao de 130 nan ometros.
Os modelos de Pentium 4 Extreme Edition atuais s ao baseados no nucleo
Prescott 2M com tecnologia de 90 nan ometros. Possuem 16 KB de cache
L1 para dados; 12 KB de cache L1 para instruc ao; 2 MB de cache L2; n ao
possuem cache L3; trabalhava externamente a 1066 MHz (266 MHz trans-
ferindo quatro dados por pulso de clock); clock interno de 3,73 GHz; su-
porte ` as instruc
oes MMX, SSE, SSE2 e SSE3; tecnologia Hyper-Threading,
EM64T.
66
Pentium D e Pentium Extreme Edition

O processador Pentium D e a vers
ao de dois n
ucleos do Pentium 4, e o Pentium
Extreme Edition e a vers
ao do Pentium D com tecnologia HyperThreading ha-
bilitada. Os processadores Pentium D e Pentium Extreme Edition podem ser
encontrados em duas versoes de n
ucleos: Smithfield e Presler.
O Pentium D e o Pentium Extreme Edition s ao baseados na microarquitetura

x86 de setima geracao da Intel, chamada Netburst, ou seja, apesar do nome
diferente, eles s
ao internamente um Pentium 4 (ou melhor, dois processadores
Pentium 4 em um u nico encapsulamento). A diferenca b
asica entre o Pentium
D e o Pentium Extreme Edition e a ausencia da tecnologia HyperThreading nos
processadores Pentium D.
Smithfield
Os processadores Pentium D e Pentium Extreme Edition da serie 800 s ao
baseados no n ucleo Smithfield. O n ucleo Smithfield consiste na verdade
em duas pastilhas de silcio do n ucleo Prescott montadas em um u nico
processador.
As principais caractersticas dos processadores Pentium D da serie 800 s
ao:
tecnologia de n
ucleo duplo; 16 KB de cache L1 de dados por n ucleo; 12 KB
de cache L1 de instrucao por n
ucleo; 2 MB de cache L2 (1 MB por n ucleo);
barramento externo de 800 MHz (200 MHz transferindo quatro dados por
pulso de clock), 533 MHz no caso do Pentium D 805 (133 MHz transferindo
quatro dados por pulso de clock); clock interno de 2,66 a 3,20 GHZ para
o Pentium D e 3,20 GHz para o Extreme Edition; suporte ` as instruc
oes
SSE3; soquete 775; processo de fabricac ao de 90 nm; tecnologia EM64T,
XD e SpeedStep (modelos 840 e 830); e tecnologia Hyper-Threading nos
processadores Pentium Extreme Edition. Os processadores Pentium D
n
ao tem esta tecnologia.
Presler
Os processadores Pentium D e Pentium Extreme Edition da serie 900 s ao
baseados no nucleo Presler.
As principais caractersticas dos processadores Pentium D e Pentium Ex-
treme Edition da serie 900 s ao: tecnologia de n ucleo duplo; 16 KB de
cache L1 de dados por n ucleo; 12 KB de cache L1 de instruc
ao por n
ucleo;
4 MB de cache L2 (2 MB por n ucleo); barramento externo de 800 MHz
(200 MHz transferindo quatro dados por pulso de clock) nos processadores
Pentium D ou 1.066 MHz (266 MHz transferindo quatro dados por pulso
de clock) nos processadores Pentium Extreme Edition; clock interno de

2,80 a 3,60 GHZ para o Pentium D e 3,46 a 3,73 GHz para o Extreme
Edition; suporte `
as instrucoes SSE3; soquete 775; processo de fabricacao
de 65 nm; tecnologia EM64T, XD, VT e SpeedStep (modelos 840 e 830); e
tecnologia Hyper-Threading nos processadores Pentium Extreme Edition.
Os processadores Pentium D n ao tem esta tecnologia.
Pentium M
O Pentium M e o processador da Intel voltado para o mercado de notebooks e
utilizado pela plataforma Centrino. A plataforma Centrino da Intel e um con-
67
junto de tecnologias desenvolvidas para notebooks e e formada por tres compo-

nentes:
Processador Pentium M
Intel Chipsets 855 ou 915
Rede Wireless Intel/PRO
Um notebook so pode ser considerado Centrino se ele possuir todos esses

tres componentes. O processador Pentium M da Intel foi lancado em marco de
2003, usando a microarquitetura x86 de sexta gerac
ao da Intel, ou seja, a mesma
arquitetura usada pelos processadores Pentium Pro, Pentium II e Pentium III.
Podem ser encontrados em duas vers oes de n
ucleos: Banias e Dothan.
Banias
Os primeiros modelos de Pentium M eram baseados no n ucleo Banias,
que tinha 32 KB de cache L1 de instruc oes e 32 KB de cache L1 de
dados; 1 MB de cache L2; trabalhava externamente a 400 MHz (100 MHz
transferindo quatro dados por pulso de clock); clock interno de 1,10 a
1,50GHz; suporte as instrucoes SSE2; tecnologia Enhanced SpeedStep;
tecnologia de construc
ao de 0, 13m; padr
ao de pinagem soquete 478 e
479.
Dothan
O nucleo Dothan e construdo com tecnologia de 90 nan
ometros e utilizado
nos processadores Pentium M modernos. Ele possui 32 KB de cache L1
de instruc
oes e 32 KB de cache L1 de dados; 2 MB de cache L2; trabalha
externamente a 400 MHz ou 533 MHz (100 MHz e 133 MHz transferindo
quatro dados por pulso de clock, respectivamente); clock interno de 1,10
a 2,26 GHz; suporte as instruc oes SSE2; tecnologia Enhanced SpeedStep,
Execute Disable (alguns modelos); padr ao de pinagem soquete 478 e 479.
5.1.2 Famlia Celeron

O nome Celeron e utilizado pela Intel para designar sua linha de processadores de
baixo custo. Na verdade, o Celeron e uma vers ao econ omica dos processadores
topo de linha da Intel. Ou seja, o Celeron e uma vers ao ?capada? do Pentium
II, Pentium III ou do Pentium 4, com algumas caractersticas reduzidas ou
removidas. O Celeron diferencia-se do Pentium II, Pentium III ou do Pentium
4 em basicamente tres aspectos:
Tamanho do cache L2
Clock interno
Clock do barramento externo
Essas diferencas fazem com que o Celeron seja mais barato e tenha um de-
sempenho menor do que os processadores Pentium II, Pentium III e Pentium
4, sendo, portanto, destinado para o mercado de usu arios domesticos ou para
aqueles que nao necessitam de grande poder computacional.
68
Existem v arios modelos de Celeron, mas atualmente o comercializado pela

Intel e o Celeron D. O sufixo D e apenas para diferenci
a-lo das gerac
oes anteri-
ores.
O Celeron D e a vers
ao topo de linha dos processadores Celeron. Esse pro-
cessador e baseado no Pentium 4 com n ucleo Prescott e possui tecnologia de 65
e 90 nan
ometros.
O Celeron D possui 16 KB de cache L1 de dados, 256 e 512 KB de cache

L2, trabalha externamente a 533 MHz (133 MHz transferindo quatro dados por
pulso de clock), suporte ?s instrucoes multimdia SSE3, encapsulamento FC-
PGA e FC-LGA, padr ao de pinagem soquete 478 ou 775, e pode ser encontrado
com clocks de 2,13 GHz a 3,60 GHz. Por ser uma vers ao ?capada? do Pentium 4
Prescott, que permite alcancar com maior facilidade freq uencias mais elevadas,
o Celeron D n ao suporta a tecnologia Hyper-Threading, que permite simular
em um u nico processador fsico dois processadores l
ogicos, e nao possui n
ucleo
duplo.
Alguns processadores Celeron D possuem a tecnologia EM64T (Extended

Memory 64-bit Technology), que permite ao processador acessar mais memoria
RAM, e a tecnologia XD (eXecute Disable), que impede que determinados tipos
de vrus ataquem o micro.
Antes do Celeron D, vieram alguns outros modelos: Celeron SEPP (Conving-

ton), Celeron A (Medocino), Celeron PPGA (Mendocino), Celeron Coppermine,
Celeron Tualatin, Celeron Willamette, Celeron Northwood e o Celeron M.
5.1.3 Famlia Core

Core Duo
O Core Duo (conhecido anteriormente pelo nome-c odigo Yonah) e o primeiro
processador da Intel voltado para o mercado de notebooks a ter tecnologia de
dois nucleos, isto e, dentro dele h
a dois processadores completos. Curiosamente
este e tambem o primeiro processador da Intel adotado pela Apple.
Na realidade este processador e um Pentium M com dois nucleos de pro-

cessamento e construdo com tecnologia de 65 nm (O Pentium M e atualmente
construdo com tecnologia de 90 nm).
Apesar de ter dois nucleos de processamento dentro de um u nico proces-

sador, o tamanho do n ucleo do Core Duo e praticamente o mesmo do Pentium
M (nucleo Dothan). Isto significa que o custo para a Intel produzir um Core Duo
e quase o mesmo para produzir um Pentium M, que tem apenas um u nico n
ucleo.
O cache de mem oria L2 do Core Duo e de 2 MB compartilhado entre

os n
ucleos (a Intel chama esta implementac ao de cache L2 compartilhado de
Smart Cache, ou cache inteligente). No Pentium D 840, por exemplo, que e
um processador de n ucleo duplo, o tamanho do seu cache L2 e de 2 MB, sendo
1 MB destinado para cada n ucleo. Ou seja, no Pentium D existem dois cache
69
L2 de 1 MB, um por nucleo. J

a no Core Duo, existe apenas um cache L2 de 2
MB que e compartilhado entre os dois n
ucleos.
Com o cache compartilhado, a quantidade de mem oria cache que cada n

ucleo
utiliza n
ao e fixa. Com um cache L2 de 2 MB, em um dado momento um n ucleo
pode estar usando 1,5 MB de cache e o outro 512 KB (0,5 MB), por exemplo.
Se em um processador de n ucleo duplo com cache separado o cache L2 de um
nucleo acabe(isto e, seu 1 MB esta sendo totalmente usado), ele precisa ir `
a
lenta mem oria RAM buscar os dados, diminuindo o desempenho do sistema. No
caso do cache compartilhado, cada n ucleo pode simplesmente redimensionaro
seu cache L2.
Outra vantagem do cache L2 compartilhado e que se um n ucleo buscou um

dado ou uma instruc ao e a armazenou no cache L2, esta mesma informac ao
pode ser aproveitada pelo outro n ucleo. Em processadores de n ucleo duplo
com mem orias cache separadas o segundo n
ucleo teria de acessar este dado (ou
instruc
ao) atraves do barramento local do processador, isto e, pelo lado de
forado processador, usando o clock do barramento local, que e muito inferior
ao clock interno do processador, diminuindo o desempenho do sistema.
As principais caractersticas do Core Duo s

ao as seguintes: tecnologia de
nucleo duplo; Nome-c odigo: Yonah; 32 KB de cache L1 de instrucoes e 32 KB
de cache L1 de dados 2 MB de cache L2 compartilhado entre os dois n ucleos;
Soquete 478 ou 479; tecnologia de 65 nm; barramento externo de 667 MHz
(166 MHz transferindo quatro dados por pulso de clock); tecnologia de Virtual-
izac
ao; tecnologia Execute Disable; tecnologia Enhanced SpeedStep; suporte ` as
instruc
oes SSE3.
Podemos dividir a plataforma Centrino em tres famlias. A primeira famlia

e formada pelo processador Pentium M, chipset Intel 855/915 Express e rede
sem fio Intel PRO/Wireless. A segunda famlia e formada pelo processador
Intel Core Solo (vers ao do processador Intel Core Duo, mas com um u nico
nucleo de processamento ? ate o momento somente um modelo de Core Solo foi
lancado, T1300, rodando internamente a 1,66 GHz, externamente a 667 MHz, 2
MB de cache L2), chipset Intel 945 Express e rede sem fio Intel PRO/Wireless
3945ABG. J a a terceira famlia, tambem conhecida como Centrino Duo (antes
chamada Napa), traz para os notebooks o poder computacional dos proces-
sadores de dois nucleos e e formada pelo processador Intel Core Duo com clock
interno de 1,50 a 2,16 GHz, chipset 945 Express e rede Intel PRO/Wireless
3945ABG.
Core 2 Duo
O Core 2 e a gerac
ao mais recente de processadores lancada pela Intel (os
primeiros modelos foram lancados oficialmente em 27 de julho de 2006). A
chegada do Core 2 significa a substituic
ao da marca Pentium, que estava sendo
usada pela companhia desde 1993. Os modelos mais comuns e conhecidos dessa
linha se chamam Core 2 Duo (com n ucleo duplo), que substitui o Pentium 4 e o
Pentium D, mas existe tambem um modelo Core 2 Quad (com n ucleo quadruplo)
e os modelos Core 2 Extreme (high end), que substitui o Pentium Extreme
70
Edition.
O Core 2 Duo e o primeiro processador para desktop a usar a nova microar-

quitetura Core. O lancamento do processador Core 2 Duo (nome-c odigo Conroe
para desktop e Meron para port ateis) marca o incio de uma nova gerac
ao de
processadores baseados na nova microarquitetura Core, e declara de uma vez por
todas o fim da microarquitetura Netburst usada desde 2000 pelos processadores
Intel de 7a gerac
ao. Como a microarquitetura Core e baseada na arquitetura do
Pentium M e do Pentium III, podemos dizer que o Core 2 Duo e um processador
Intel de 6a gerac
ao.
A diferenca entre o Core 2 Duo e o Core 2 Extreme e que este ultimo tra-
balha com clocks mais elevados e tem o multiplicador de clock destravado, o
que permite fazer overclock alterando o multiplicador de clock do processador.
Cuidado para nao confundir o processador Core 2 Duo com o Core Duo. O
Core Duo (conhecido anteriormente pelo nome-c odigo Yonah) e o nome com-
ercial para um Pentium M com dois n ucleos de processamento construdo com
tecnologia de 65 nm. J
a o Core 2 Duo e o nome comercial para o processador de
nome-c odigo Merom (para notebooks) ou Conroe (para desktops), que utiliza a
nova microarquitetura Core da Intel.
As principais caractersticas tecnicas dos processadores da famlia Core 2

(Core 2 Duo e Core 2 Extreme) s ao as seguintes: arquitetura Core; 64 KB de
cache L1 (32 KB de dados + 32 KB de instruc oes) por n
ucleo; tecnologia de dois
nucleos (o Core 2 Extreme QX6700 tem tecnologia de quatro n ucleos); tecnolo-
gia de 65 nm; soquete 775; barramento externo de 800 MHz (200 MHz trans-
ferindo quatro dados por pulso de clock) ou 1.066 MHz (266 MHz transferindo
quatro dados por pulso de clock); 2 MB, 4 MB ou 8 MB (Extreme QX6700) de
cache de mem oria L2 compartilhado; tecnologia de Virtualizac ao (exceto o Core
2 Duo E4300); tecnologia Intel EM64T; instruc oes SSE3 e SSSE3 (atualizacao
da SSE3); Execute Disable; Intelligent Power Capability; tecnologia Enhanced
SpeedStep.
O modelos Core 2 Duo possuem clock interno de 1,80 a 2,66 GHz, o Core 2
Quad possuiu clock interno de 2,40 GHz e o Core 2 Extreme 2,66 e 2,93 GHz.
Existem os modelos Core 2 Duo para notebook com as caractersticas men-

cionadas anteriormente, mas com um barramento externo de 667 ou 533 MHz.
5.1.4 Xeon
Em 1998 a Intel estabeleceu uma distinc ao entre seus processadores voltados
para o mercado de servidores e estac oes de trabalho dos voltados para o mer-
cado de usu arios domesticos. Desde ent ao, a Intel passou a incluir o termo
Xeon(pronuncia-se zon) no nome dos processadores voltados para o mer-
cado de servidores e estac
oes de trabalho. Esses processadores reconhecem mais
mem oria RAM, permitem trabalhar em ambiente multiprocessado (isto e, com
placas-mae com v arios processadores instalados sobre ela) e possui um desem-
71
penho maior que os processadores voltados para o mercado domestico.
A Intel lancou vers

oes para o mercado de servidores e estac
oes de trabalho
dos seus processadores Pentium II e Pentium III, chamadas, respectivamente,
de Pentium II Xeon e Pentium III Xeon. Assim, o processador Pentium II era
direcionado para o mercado de usu arios domesticos enquanto que o Pentium II
Xeon era um processador voltado para o mercado de servidores e estac oes de
trabalho. A mesma coisa acontece com o Pentium III e Pentium III Xeon. No
caso do Pentium 4, em vez do nome escolhido ter sido Pentium 4 Xeon, optou-se
pelo nome Xeon. Ou seja, o Xeon e um processador voltado para o mercado de
servidores e estac
oes de trabalho baseado no Pentium 4. Atualmente, existem
os modelos Xeon Core 2 Duo e Core 2 Quad.
Pentium 4 Xeon
Este processador deveria se chamar Pentium 4 Xeon, mas a Intel optou pelo
nome Xeon. Como comentamos anteriormente, o Xeon e um processador voltado
para o mercado de servidores e estacoes de trabalho baseado no Pentium 4,
sendo, portanto, um processador Intel de 7a gerac
ao. Como vimos, os proces-
sadores anteriores da serie Xeon usavam a arquitetura Intel de 6a gerac
ao (a
mesma do Pentium Pro).
A diferenca entre os processadores Xeon MP e Xeon e que o primeiro per-

mite multiprocessamento simetrico com quatro ou mais processadores, enquanto
que o Xeon permite multiprocessamento com no m aximo dois processadores.
Antigamente, o processador Xeon era chamado Xeon DP(multiprocessamento
simetrico com ate dois processadores), sendo posteriormente renomeado para
apenas Xeon.
Os processadores Xeon possuem 8 KB de mem oria cache L1 para dados (16

KB nos modelos que possuem a tecnologia de 64 bits EM64T) e um cache L1
de execuc
ao de 150 KB. O cache L2 pode ser de 512 KB, 1 MB ou 2 MB, sendo
que alguns modelos possuem um cache L3, que pode ser de 1 MB, 2 MB, 4 MB
ou 8 MB. O barramento externo pode ser de 667, 1066 ou 1333 MHz. Alguns
modelos possuem suporte ` as instruc
oes SSE3, e `
as tecnologias XD, EM64T e
Hyper-Threading.
Os modelos Xeon DP 53xx possuem suporte a tecnologia Quad-Core e n

ao
suportam a tecnologia Hyper-Threading.
Xeon MP
Como ja explicamos, a diferenca entre o Xeon MP e o Xeon e a quantidade de
processadores suportados no modo de multiprocessamento simetrico: o Xeon
suporta ate dois processadores em uma mesma placa-mae, enquanto que o Xeon
MP suporta ate quatro processadores por barramento.
72
Na realidade e possvel construir servidores com mais de quatro proces-

sadores Xeon MP em uma mesma placa-m ae. Para isso, no entanto, os pro-
cessadores devem ser agrupados de quatro em quatro ? j a que eles s
o suportam
ate quatro processadores por barramento ? devendo haver uma conex ao entre
os chipsets. Por exemplo, em um servidor com oito processadores Xeon MP,
os quatro primeiros processadores estarao interligados atraves do mesmo barra-
mento, enquanto os outros quatro processadores estar ao interligados atraves de
um segundo barramento. A comunicac ao entre os barramentos locais sera feita
pelo chipset.
As principais caractersticas dos processadores Xeon MP s ao: soquete 603;

cache L1 de execucao de 150 KB; cache L1 de dados de 8 KB ou de 16 KB
nos modelos com suporte ` a tecnologia EM64T; multiprocessamento simetrico
diretamente com ate quatro processadores; tecnologia Hyper-Threading. Alguns
modelos possuem suporte ` as instruc
oes SSE3, e `
as tecnologias XD, EM64T.
Xeon N
ucleo Duplo (50xx e 7xxx)
A tecnologia de n ucleo duplo traz dois processadores inteiros dentro de um
mesmo inv olucro. Como os processadores Xeon de n ucleo duplo modelos 50xx
e 7xxx tem a tecnologia HyperThreading ? que simula a existencia de dois pro-
cessadores em cada n ucleo ? o sistema operacional reconhece cada processador
Xeon de nucleo duplo como sendo quatro processadores. Assim, em um servidor
com dois processadores Xeon de n ucleo duplo, o sistema operacional reconhecer
a
oito processadores (quatro n ucleos, dois por processador, e dois processadores
l
ogicos por n
ucleo).
Todos os processadores Xeon de n ucleo duplo possuem as seguintes carac-

tersticas: soquete 604 (modelos 7xxx) ou 771 (modelos 50xx); Mesma arquite-
tura interna no Pentium 4 (Netburst); instruc oes SSE3; cache L1 de dados de 16
KB e cache de execuc ao de 150 KB; suporte a multiprocessamento simetrico com
ate dois processadores por placa-m ae; barramento externo de 667, 800 ou 1066
MHz; tecnologia Execute Disable; tecnologia EM64T; tecnologia HyperThread-
ing; tecnologia de Virtualizacao nos modelos 7xxx e 50xx; tecnologia Demand-
Based Switching (DBS), exceto nos modelos 5060 e 5063; tecnologia Enhanced
SpeedStep; tecnologia de construc ao 90 nan ometros ou 65 nanometros.
Xeon N
ucleo Duplo (51xx)
Intel lancou recentemente uma nova serie de processadores Xeon (51xx) baseada
na nova microarquitetura Core, a mesma usada pelos processadores Core 2 Duo.
Esta nova serie era conhecida anteriormente por seu nome-c odigo, Woodcrest.
Tenha em mente que os processadores Xeon de nucleo duplo de outras series

(50xx e 7xxx) s
ao baseados na microarquitetura do Pentium 4 (Netburst) e por
isso possuem a tecnologia HyperThreading, que nao est
a presente na microar-
quitetura Core.
73
Todos os processadores Xeon da serie 51xx possuem as seguintes carac-

tersticas: tecnologia de n
ucleo duplo; tecnologia de 65 nm; soquete 771; in-
strucoes SSE3; cache L1 dividido, sendo 32 KB para dados e 32 KB para in-
strucoes por n
ucleo; 4 MB de cache L2 compartilhado entre os n ucleos; barra-
mento externo de 1066 ou 1333 MHz; tecnologia EM64T; tecnologia de Virtual-
izac
ao; tecnologia Execute Disable; tecnologia Demand-Based Switching (DBS),
nos modelos 5160, 5150, 5148 e 5140; tecnologia Enhanced SpeedStep; tecnolo-
gia Dual Independent Bus (DIB), onde cada n ucleo tem seu pr
oprio barramento
externo em vez de ter apenas um barramento compartilhado entre nos n ucleos
para a comunicac ao com os outros dispositivos do micro.
5.1.5 Itanium
O projeto de processadores de 64 bits da Intel j
a se arrasta por muitos anos.
O primeiro processador lancado usando essa tecnologia foi o Itanium e recente-
mente a Intel lancou mais um processador IA-64, o Itanium 2.
Esses dois processadores possuem caractersticas de hardware bastante pe-

sadas. O Itanium tem os dois caches de mem oria (L1 e L2) dentro do pr
oprio
processador, como ocorre com os demais processadores atualmente, e ainda um
cache extra (L3) dentro de seu cartucho, podendo esse circuito ter 2 MB ou
4 MB, dependendo da vers ao do processador. Ele consegue acessar ate 16 EB
(Exabytes, 1 EB = 26 0) de mem oria RAM e usa um barramento externo de
64 bits rodando a 266 MHz, atingindo uma taxa de transferencia de 2,1 GB/s.
Esse processador usa uma mistura de soquete com cartucho.
J
a o Itanium 2 tem uma mem oria cache L1 de 32 KB, uma mem oria cache
L2 de 256 KB e uma mem oria cache L3 de 1,5 MB ou de 3 MB, dependendo
do modelo. Os mais atuais possuem uma cache L3 de 6, 8, 12, 18 ou 24 MB
dependendo do modelo. Seu barramento externo e de 128 bits, rodando a 400
ou 533 MHz. Possuem suporte a tecnologia Dual-Core, EM64T, VT.
Esses dois processadores sao voltados exclusivamente para o mercado de

servidores de alto desempenho. Isso deixa a AMD em grande vantagem, j a que
havera processadores de 64 bits da AMD voltados para usuarios comuns (como
o Clawhammer ).
Outra vantagem da arquitetura de 64 bits da AMD sobre a arquitetura de 64

bits da Intel e que a arquitetura da Intel n

ao roda nativamente c odigo de 32 bits
usado pelos programas atuais, ao contr ario do que ocorre nos processadores da
AMD, que rodam diretamente esse tipo de c odigo. Isso significa que para rodar
sistemas operacionais e aplicativos de 32 bits, os processadores IA-64 (Itanium,
Itanium 2 e futuros processadores) precisam traduzir as instruc oes de 32 bits
em instrucoes equivalentes de 64 bits. Isso faz com que haja uma demora na
execucao da instruc
ao, pois h
a tempo perdido com essa convers ao. O resultado
disso e
obvio: em alguns casos pode ocorrer de sistemas operacionais e progra-
mas de 32 bits rodarem mais lentamente nos processadores IA-64 da Intel do
que em processadores de 32 bits como o Pentium 4 e o Athlon XP.
74
Mas, como esses processadores da Intel foram destinados ao mercado de

servidores, isso n
ao tem muita importancia, j
a que m
aquinas usando esses pro-
cessadores com certeza rodarao programas e sistemas escritos diretamente com
instruc
oes de 64 bits. Mas como essa e uma nova tecnologia, n ao so e de-
morado reescrever programas antigos como escrever novos programas para essa
nova plataforma. E claro que esse mesmo problema existe nos processadores
da AMD, isto e, possivelmente demorar a algum tempo ate existirem sistemas
operacionais e programas escritos usando c
odigo de 64 bits desses processadores.
Mas, por outro lado, eles podem rodar diretamente codigo de 32 bits, facilitando
a entrada desses processadores no mercado.
5.2 AMD
5.2.1 Sempron
O Sempron e o processador da AMD voltado para o mercado low-end, ou seja,
ele e destinado a usu
arios que n
ao precisam de grande poder computacional e
que estao mais preocupados com preco do que com desempenho. O concorrente
do Sempron e Celeron D da Intel.
O processador Sempron est a disponvel em tres vers

oes de soquete: 462
(Socket A), 754 e AM2 (940 pinos). Os processadores Sempron soquete 462 sao
vers
oes mais simples do Athlon XP, enquanto que os processadores Sempron
soquete 754 e soquete AM2 s
ao versoes mais simples do Athlon 64.
Como o Sempron soquete 462 usa uma arquitetura interna completamente

diferente dos processadores Sempron soquete 754 e soquete AM2, uma com-
parac
ao direta entre esses dois processadores n
ao e possvel.
A nomenclatura PR(Performance Rating) usada pelo Sempron s o serve

para a comparacao entre modelos de Sempron usando o mesmo tipo de soquete.
N
ao e possvel comparar a nomenclatura PR do Sempron com a do Athlon
XP ou com a do Athlon 64. Por exemplo, um Sempron 3000+ n ao e necessaria-
mente mais rapido do que um Athlon XP 2800+ ou do que um Athlon 64 2800+.
Soquete 462
Os processadores Sempron soquete 462 s

ao, na realidade, processadores Athlon
XP com barramento externo de 333 MHz (166 MHz transferindo dois dados por
pulso de clock) e 256 KB de mem
oria cache L2 (ou 512 KB no caso do modelo
3000+).
Essa categoria de Sempron possui as demais caractersticas do Athlon XP,

tais como: 64 KB de cache L1 de instruc oes e 64 KB de cache L1 de dados;
256 KB ou 512 KB de cache de mem oria L2; suporte às instruc
oes MMX,
3DNow!, SSE e SSE2 (mas n ao `
as instruc
oes SSE3); processo de fabricac
ao de
130 nanometro.
75
Soquete 754
Os processadores Sempron soquete 754 s ao na realidade processadores Athlon
64 com menos mem oria cache e sem as extens
oes de 64 bits, sendo que modelos
lancados mais recentemente passaram a contar com as extens oes de 64 bits.
As principais caractersticas dos processadores Sempron soquete 754 s ao:

64 KB de cache de L1 de instruc oes e 64 KB de cache L1 de dados; 128
KB ou 256 KB de cache de mem oria L2; barramento HyperTransport (bar-
ramento externo para acesso ao chipset Northbridge. Esta tecnologia permite
o processador comunicar-se com a mem oria RAM e com os demais circuitos
do micro ao mesmo tempo, pois existe outro barramento externo para acesso
a mem
` oria RAM. Antigamente, era apenas um barramento de acesso externo)
trabalhando a 800 MHz (este clock pode tambem ser referenciado como 1.600
MHz) para os modelos atuais; configurac ao de memoria single channel; suporte
a instruc
oes SSE3 nos modelos que tem as extensoes de 64 bits habilitadas; pro-
cesso de fabricac
ao de 90 nanometros.
Soquete AM2
Ao contrario dos processadores Sempron soquete 754, que trabalham apenas
na configurac
ao de um u
nico canal (single channel), os processadores Sempron
soquete AM2 podem utilizar a configurac ao de dois canais (dual channel), do-
brando a taxa de transferencia no acesso à mem oria desde que voce use dois
ou quatro m odulos de memoria em seu micro. Lembre-se que os processadores
Sempron soquete 754 aceitam somente mem orias DDR, enquanto que os pro-
cessadores Sempron soquete AM2 aceitam somente mem orias DDR2.
As principais caractersticas tecnicas do Sempron AM2 s ao as seguintes: 64

KB de cache de L1 de instrucoes e 64 KB de cache L1 de dados; 128 KB ou 256
KB de cache de mem oria L2; barramento HyperTransport trabalhando a 800
MHz (3.2 GB/s). Este clock pode tambem ser referenciado como 1.600 MHz;
o controlador de mem oria integrado suporta mem orias DDR2-400, DDR2-533
e DDR2-667 na configurac ao de dois canais (dual channel), o que significa que
o processador acessa a mem oria a 128 bits, se dois ou quatro m odulos forem
usados; conjunto de instruc oes SSE3; extens oes de 64 bits habilitadas; processo
de fabricac
ao de 90 nanometros.
concorrente
Existem os modelos de Semprom chamados Mobile Semprom. E

direto do Pentium M. O Mobile Semprom possui as seguintes caractersticas:
64 KB de cache de L1 de instrucoes e 64 KB de cache L1 de dados; 128KB ou
256KB de cache L2 incorporado ao processador; Northbridge integrado; protecao
avancada contra vrus; suporte a instruc
oes SSE2; processo de fabricac
ao 90
nanometros.
5.2.2 Athlon 64
Os processadores mais novos da AMD encontrados no mercado atualmente s ao
baseados na arquitetura do Athlon 64, tambem conhecida como x86-64 ou ham-
76
mer. Os modelos de Athlon 64 s

ao o Athlon 64, Athlon 64 FX e o Athlon 64 X2.
Esses tres processadores mais o Sempron s

ao voltados para o mercado de
desktops. O Athlon 64 e voltado para o mercado mid-range (usu arios entusi-
astas ou aqueles que necessitam de um poder computacional maior do que o
proporcionado pelo Sempron) e o Athlon 64 FX e o Athlon 64 X2 s ao voltados
para o mercado high-end (alto desempenho). Existem tres outros processadores
baseados na arquitetura do Athlon 64: Athlon 64 Mobile e Turion 64, que s ao
voltados para o mercado de notebooks, e o Opteron, que e voltado para o mer-
cado de servidores.
A principal caracterstica da arquitetura do Athlon 64 e a presenca do con-

trolador de mem oria dentro do pr oprio processador e n ao no chipset, como
acontece com outros processadores. Por causa desta arquitetura a comunicac ao
entre o processador e os m odulos de mem oria e feita atraves de um barramento
dedicado, enquanto que a comunicac ao entre o processador e o chipset e feita
atraves de um barramento independente, chamado HyperTransport.
Processadores da AMD baseados na arquitetura do Athlon 64 podem ser

encontrados com os seguintes padr
oes de pinagem:
Soquete 754
Usado pelas primeiras vers oes de Athlon 64, alguns modelos de Sempron
e Turion 64. Seu controlador de mem oria usa somente um canal (single
channel), o que significa que o processador acessa a mem
oria a 64 bits;
Soquete 939
Usado pelos processadores Athlon 64, Athlon 64 FX, Athlon 64 X2 e o
Opteron. Seu controlador de mem oria usa dois canais (dual channel),
o que significa que o processador acessa à mem oria a 128 bits, se dois
modulos de mem oria forem usados.
Soquete 940
Usado pelos primeiros processadores Athon 64 FX e pelo Opteron. Seu
controlador de mem oria usa dois canais (dual channel), o que significa que
o processador acessa a mem oria a 128 bits, se dois m
odulos forem usados
(ou um n umero par de m odulos de mem oria for usado). E necessaria a
utilizac
ao de mem
orias do tipo ECC;
Soquete AM2
Usado pelos novos processadores Athlon 64, Athlon 64 FX e Athlon 64

X2. Nesses processadores o controlador de mem oria integrado suporta
memorias DDR2-533, DDR2-667 e DDR2-800 na configurac ao de dois
canais (dual channel), o que significa que o processador acessa a memoria
a 128 bits, se dois m
odulos forem usados. Lembre-se que o controlador
de mem oria dos processadores soquete 754, 939 e 940 suportam apenas
memorias DDR;
Soquete F
Este soquete de 1.207 pinos criado para os novos modelos do Opteron
tambem e usado pelos processadores Athlon 64 FX utilizados na plataforma
77
Quad FX da AMD (Athlon 64 FX modelos 7x). Os processadores que uti-

lizam este soquete trabalham no modo SMP (multiprocessamento simetrico),
podendo trabalhar com mais de um processador em paralelo. Assim
como os processadores soquete AM2, nesses processadores o controlador
de mem oria integrado tambem suporta mem orias DDR2-533, DDR2-667
e DDR2-800 na configurac ao de dois canais (dual channel), o que significa
que o processador acessa a mem oria a 128 bits, se um n umero par de
m odulos de mem oria for usado.
O controlador de mem oria integrado nos novos processadores Athlon 64 so-

quete AM2 e Athlon 64 FX soquete F suporta mem orias DDR2-533, DDR2-667 e
DDR2-800. O problema, no entanto, e como o clock do barramento de mem oria
e obtido. Em vez de ser gerado atraves do clock base do processador (clock
HTT, que e de 200 MHz), e usada uma divisao do clock interno do processador.
O valor desta divis
ao e metade do valor do multiplicador do processador.
Por exemplo, um processador AMD64 com um multiplicador de clock 12x

ter
a um divisor do barramento de memoria de 6. Este processador trabalhar
a
a 2,4 GHz (200 MHz x 12) e sua mem oria funcionar
a a 400 MHz (DDR2-800,
2.400 MHz / 6). Tenha em mente que as mem orias DDR e DDR2 s ao rotuladas
com o dobro dos seus clocks reais.
O problema e quando o multiplicador de clock do processador e um numero

mpar. Para um processador AM2 com um multiplicador de clock 13x teori-
camente o divisor do seu barramento de mem oria seria de 6,5. Como o barra-
mento de mem oria do AMD64 n ao trabalha com divisores quebradoseste valor
e arredondado para o pr oximo n
umero inteiro, sete neste caso. Enquanto este
processador funcionar a a 2,6 GHz (200 MHz x 13) seu barramento de mem oria
funcionara a 371 MHz (742 MHz DDR) e n ao a 400 MHz (800 MHz DDR),
fazendo com que o processador n ao alcance a largura de banda m axima que as
mem orias DDR2 podem fornecer.
Outras caractersticas encontradas nos processadores baseados na arquite-

tura do Athlon 64 s ao as seguintes: O processador n ao e vendido com base
em seu clock de operacao, mas sim atraves de um indicativo de desempenho
chamado performance rating(PR); podem acessar ate 1 TB de mem oria RAM
(barramento de enderecos de 40 bits, 240 = 1 TB); suporte `
as instruc
oes MMX,
3Dnow!, SSE e SSE2 (SSE3 apenas nos modelos mais novos); tecnologia EVP
(Enhanced Vrus Protection, tambem conhecida como NX Bit Disable); tec-
nologia CoolnQuiet (tecnologia que permite reduzir o barulho, o calor e o

consumo de energia).
Athlon 64
O Athlon 64 pode ser encontrado em vers
oes para o soquete 754, soquete 939 e
o novo soquete AM2. E pode ser encontrado com diferentes vers oes de n
ucleo
(90 nan
ometros ou 130 nanometros). O concorrente direto do Atlhon 64 e o
Pentium 4.
As principais caractersticas tecnicas do Athlon 64 s

ao as seguintes: 64 KB
78
de cache de L1 de instruc
oes e 64 KB de cache L1 de dados; 512 KB ou 1 MB
de cache de mem oria L2; barramento HyperTransport trabalhando a 800 MHz
(3,2 GB/s) ou a 1 GHz (4 GB/s). Esses clocks podem tambem ser referenciados
como 1.600 MHzou 2.000 MHz, respectivamente; configurac ao de mem oria
DDR dual channel nos modelos soquete 939 e AM2 (precisa de dois m odulos de
modulos de mem oria para usar este recurso); conjunto de instruc
oes SSE3 em
alguns modelos.
Athlon 64 X2
O Athlon 64 X2 e um Athlon 64 com tecnologia de n ucleo duplo, ou seja, ele
possui dois processadores dentro de um s
o. Todos os processadores Athlon 64
X2 s
ao encontrados para soquete 939 e AM2. O principal corrente do Athlon
64 X2 e o Pentium D Dual Core.
As principais caractersticas tecnicas do Athlon 64 X2 s

ao as seguintes: 64
KB de cache de L1 de instrucoes e 64 KB de cache L1 de dados por n ucleo; 512
KB ou 1 MB de cache de mem oria L2 por n ucleo; barramento HyperTransport
trabalhando a 1 GHz (4 GB/s). Esse clock pode tambem ser referenciado como
2.000 MHz; configuracao de mem oria DDR dual channel em todos os modelos;
conjunto de instruc
oes SSE3 em alguns modelos.
Athlon 64 FX
Originalmente a diferenca entre o Athlon 64 e o Athlon 64 FX era a quanti-
dade de mem oria cache L2 (512 KB no Athlon 64 vs. 1 MB no Athlon 64 FX)
e maior flexibilidade para overclock, j
a que ele vinha com o multiplicador de
clock destravado.
As principais caractersticas tecnicas do Athlon 64 FX sao as seguintes: 64

KB de cache de L1 de instruc oes e 64 KB de cache L1 de dados por n ucleo;
1 MB de cache de L2; barramento HyperTransport trabalhando a 800 MHz
(3,2 GB/s) ou 1 GHz (4 GB/s); configurac ao de memoria DDR dual channel
em todos os modelos; conjunto de instruc oes SSE3 em alguns modelos; n ucleo
duplo nos modelos terminados em um n umero par. O Athlon 64 FX-60 foi o
primeiro Athlon 64 FX de n ucleo duplo lancado. Esta tecnologia faz com que
o processador possua dois processadores completos em seu interior; O Athlon
64 FX-62 e baseado no novo soquete AM2 e, portanto, o seu controlador de

mem oria suporta as mem orias DDR2.
5.2.3 Turion 64
Lancado para ser o principal concorrente do Pentium M da Intel, o Turion 64 da
AMD e um processador de baixo consumo voltado para o mercado de notebooks.
O Turion 64 e baseado na arquitetura do Athlon 64 e a principal diferenca

entre o Turion 64 e o Athlon 64 Mobile e o consumo de energia. Uma outra
79
diferenca entre eles e a quantidade de mem

oria cache L2, que e de 1 MB nos
processadores Athlon 64 Mobile, enquanto que os processadores Turion 64 po-
dem ter mem oria cache L2 de 512 KB ou 1 MB, dependendo do modelo.
Tanto o Turion 64 quanto o Athlon 64 Mobile possuem a tecnologia Pow-

erNow! da AMD, que e similar a tecnologia CoolnQuiet usado pelos proces-
sadores desktop. Esta tecnologia altera o clock e a tens
ao de alimentac
ao do
processador de acordo com a carga de trabalho que esteja sendo realizada, de
modo a economizar bateria.
As principais caractersticas do Turion 64 sao as seguintes: o processador

nao e vendido com base em seu clock de operacao, mas atraves de um n
umero
de modelo; 64 KB de cache de L1 de instruc oes e 64 KB de cache L1 de dados;
512 KB ou 1 MB de cache de mem oria L2; barramento HyperTransport trabal-
hando a 800 MHz (3,2 GB/s); configurac ao de mem oria DDR single channel;
soquete 754; podem acessar ate 1 TB (terabyte) de mem oria RAM; suporte
as instruc
` oes MMX, 3Dnow!, SSE e SSE2 e SSE3; tecnologia PowerNow!; tec-
nologia EVP (Enhanced Virus Protection), tambem conhecida como NX Bit
Disable; tecnologia de 90 nan ometros.
Os processadores Turion 64 est

ao disponveis em duas series: ML, que tem
consumo maximo (TDP, Thermal Design Power) de 35 W, e MT, que tem con-
sumo maximo de 25 W.
Turion 64 X2
O Turion 64 X2 e um Turion 64 com tecnologia de dois n
ucleos e com suporte as
memorias DDR2 na configuracao de dois canais (dual channel), o que significa
que o processador pode acessar a memoria a 128 bits.
O Turion 64 X2 e o primeiro processador para notebook da AMD com tec-

nologia de dois n
ucleos e a usar o novo padr
ao de pinagem soquete S1, que uti-
liza 638 pinos em vez dos 754 pinos usados no soquete do Turion 64. Portanto,
fisicamente um Turion 64 X2 e menor do que um Turion 64 por ter menos pinos.
Enquanto que o concorrente do Turion 64 e o Pentium M, os concorrentes

do Turion 64 X2 s
ao os processadores da Intel Core Duo e Core 2 Duo (nome-
c
odigo Merom).
As principais caractersticas do Turion 64 X2 sao as seguintes: 64 KB de

cache de L1 de instruc oes e 64 KB de cache L1 de dados por n ucleo; 256 ou
512 KB de cache de mem oria L2 por n
ucleo; barramento HyperTransport tra-
balhando a 800 MHz (3,2 GB/s); configurac ao de memoria DDR2 dual channel;
soquete S1; podem acessar ate 1 TB (terabyte) de mem oria RAM; suporte às
instruc
oes MMX, 3Dnow!, SSE e SSE2 e SSE3; tecnologia PowerNow!; tecnolo-
gia de Virtualizac
ao; tencnologia EVP (Enhanced Vrus Protection); tecnologia
de 90 nan ometros.
80
5.2.4 Opteron
O Opteron e o processador da AMD voltado para o mercado de servidores de
rede. Ele e baseado na arquitetura do Athlon 64. Os principais concorrentes
s
ao o Intel Xeon e Intel Itanium.
Existem duas diferencas principais entre o Opteron e os outros processadores

baseados na arquitetura do Athlon 64. Primeiro, v arios modelos de Opteron
permitem o multiprocessamento simetrico (SMP), ou seja, permitem trabalhar
com mais de um processador na placa-m ae, enquanto que os outros proces-
sadores n
ao.
Os processadores Opteron sao identificados atraves de um numero de mod-

eloe o primeiro dgito deste n
umero indica qual e o grau de processamento
simetrico que o processador aceita: os modelos de Opteron comecando com
1nao permitem multiprocessamento simetrico, enquanto que os modelos comecando
com 2permitem multiprocessamento simetrico com ate 2 processadores e os
modelos comecando com 8permitem multiprocessamento simetrico com ate 8
processadores.
Processadores Opteron com suporte a mem orias DDR usam um n umero

de modelo de tres dgitos, enquanto que processadores Opteron com suporte a
memorias DDR2 usam um n umero de modelo de quatro dgitos.
A segunda diferenca principal e no n

umero de barramentos HyperTransport
suportados. Todos os processadores baseados na arquitetura do Athlon 64 e
os processadores Opteron iniciados com 1tem apenas um barramento Hy-
perTransport. Processadores Opteron iniciados com 2tem dois barramentos
HyperTransport (ou tres, no caso dos processadores Opteron de quatro dgitos),
enquanto que processadores Opteron iniciados com 8tem tres barramentos
HyperTransport.
Os processadores Opteron podem ser encontrados para v

arios tipos de so-
quete:
Soquete 939
Existem alguns modelos de Opteron da serie 1 para este soquete. Eles
n
ao passam de modelos de Athlon 64 ou de Athlon 64 X2 (se tiver dois
n
ucleos) com outro nome. Estes modelos trabalham com mem orias DDR
comuns;
Soquete 940
Estes modelos necessitam mem orias DDR registradas(isto e, com buffer),
que e um tipo especialde memoria para servidores;
Soquete AM2
Existem alguns modelos de Opteron da serie 1 para este soquete. Eles
n
ao passam de modelos de Athlon 64 X2 com outro nome (porem com a
tecnologia de virtualizacao, n
ao presente no Athlon 64 X2). Estes modelos
trabalham com mem orias DDR2 comuns;
81
Soquete F
Estes modelos trabalham com mem orias DDR2 registradas(isto e, com
buffer), que e um tipo especialde mem oria para servidores.
Processadores Opteron que trabalham com mem

orias DDR2 tambem s
ao
chamados de Opteron de Segunda Gerac
ao.
Em todos os modelos de Opteron o controlador de mem oria usa dois canais

(dual channel), ou seja, o processador acessa a memoria a 128 bits, se dois
modulos forem usados (ou se um n umero par de modulos de mem oria forem
usados).
As principais caractersticas tecnicas do Opteron s ao as seguintes: suporte

a multiprocessamento Simetrico; 64 KB de cache de L1 de instruc oes e 64 KB
de cache L1 de dados; 1 MB de cache de mem oria L2 por n
ucleo; barramento
HyperTransport trabalhando a 800 MHz (3,2 GB/s) ou 1 GHz (4 GB/s); con-
figurac
ao de memoria em dois canais (voce precisa instalar dois ou um n umero
par de m odulos de mem oria para usar este recurso); podem acessar ate 1 TB
(terabyte) de mem oria RAM; suporte ` as instruc
oes MMX, 3Dnow!, SSE e SSE2
(SSE3 apenas nos modelos mais novos); tencnologia EVP (Enhanced Vrus Pro-
tection); tecnologia de virtualizacao AMD-V nos modelos de quatro dgitos.
Os seguintes modelos de Opteron s

ao encontrados: Opteron Modelos 1xx
(DDR) (soquete 940); Opteron Modelos 2xx (DDR) (soquete 940); Opteron
Modelos 8xx (DDR) (soquete 940); Opteron Modelos 1xxx (DDR2) (soquete
AM2); Opteron Modelos 2xxx (DDR2) (soquete F); Opteron Modelos 8xxx
(DDR2) (soquete F).
82
Parte II
L
ogica de Programa
cao
83
Captulo 6
Orientac
ao a Objetos
6.1 Introduc
ao
A analise e o projeto orientados a objetos tem como meta identificar o melhor
conjunto de objetos para descrever um sistema de software. O funcionamento
deste sistema se da por meio do relacionamento e troca de mensagens entres os
objetos.
Na programac ao orientada a objetos, implementa-se um conjunto de classes
que definem os objetos presentes no sistema de software. Cada classe determina
o comportamento (definido nos metodos) e os estados possveis (atributos) de
seus objetos, assim como o relacionamento com outros objetos.
As linguagens de programac ao que d
ao suporte a orientac
ao a objetos s
ao:
Smaltalk, Perl, Python, Ruby, PHP, ColdFusion, C++, Object Pascal, Java,
JavaScript, ActionScript, Delphi e C#.
6.2 Conceitos fundamentais

1. Objetos
Os objetos do mundo real compartilham duas caractersticas: possuem um
estado e tem um comportamento. Por exemplo, cachorro tem um estado
(nome, cor, raca) e um comportamento (latindo, comendo, lambendo).
Analogamente, objetos de software s ao modelados de acordo com os ob-
jetos do mundo real, ou seja, possuem estado e comportamento (objeto e
uma abstracao do mundo real). Um objeto de software armazena seu es-
tado em variaveis e implementa seu comportamento com metodos. Estas

vari
aveis e metodos s
ao formalmente chamados de vari aveis de inst
ancia
e metodos de instancia a fim de distingu-los de vari
aveis e metodos de
classe.
As vari
aveis de um objeto fazem parte do seu nucleo (centro). Os metodos
envolvem e escondem o nucleo do objeto de outros componentes da aplicacao,
1. Empacotar as vari
aveis de um objeto sobre protecao de seus metodos e
chamado de encapsulamento. O encapsulamento e utilizado para esconder
detalhes de implementacao pouco importante. Este e um dos princpios
fundamentais da programac ao orientada a objetos.
84
Figura 6.1: Representac

ao de um objeto
` vezes, por raz

As oes de eficiencia ou implementac
ao, um objeto deseja
expor algumas de suas vari aveis ou esconder alguns de seus metodos. Esta
capacidade de controlar quais componentes podem acessar seus metodos
e suas vari
aveis e chamada de Controle de Acesso.
Cada objeto tem sua identidade que significa que dois objetos s ao dis-
tintos mesmo que eles apresentem exatamente as mesmas caractersticas
(atributos iguais). Esta identificac
ao de objeto deve ser u
nica, uniforme e
independente do conte udo do objeto.
A estrutura de dados de um objeto e representada em termos de atributos
(tambem chamados de campos (fields)), ou seja, os dados ou informac
oes
do objeto.
A 1 mostra um exemplo da representac ao de objeto do mundo real para o
objeto de software. Os atributos Raio, x e y s
ao as vari
aveis de inst
ancia.
Em Java, para declarar uma variavel de classe basta acrescentar a palavra
static. O mesmo vale para o metodo.

ao do objeto do mundo real para o objeto de software
2. Metodos
uma rotina que e executada por um objeto ao receber uma mensagem.
E
Os metodos determinam o comportamento dos objetos de uma classe e
s
ao an
alogos `
as func
oes ou procedimentos da programac
ao estruturada. O
envio de mensagens (chamado de metodos) pode alterar o estado de um
objeto.
3. Atributos
Os atributos s
ao os elementos que definem a estrutura de uma classe. Os
85
atributos tambem sao conhecidos como vari aveis de classe, e podem ser
divididos em dois tipos b asicos: atributos de inst
ancia e de classe. Os
valores dos atributos de instancia determinam o estado de cada objeto.
Um atributo de classe possui um estado que e compartilhado por todos os
objetos de uma classe. Atributos de classe podem ser chamados tambem
de atributos est
aticos ou constantes.
As mensagens enviadas a um objeto (chamada de metodo) podem mudar
o valor de um ou mais atributos, alterando o estado de um objeto.
4. Classes
Uma classe e um modelo (prot otipo) que defini as vari
aveis (estado) e os
metodos (comportamento) comuns a todos os objetos do mesmo tipo. Na
classe s
ao definidas as vari
aveis e implementados os metodos. Os objetos
s
ao criados a partir de suas classes.
As classes nao s
ao diretamente suportadas em todas as linguagens de ob-
jetos, e n
ao s
ao necess
arias para que a linguagem seja orientada a objetos.
Alem dos metodos e atributos de uma classe, outros possveis membros
s
ao:
Construtor: define o comportamento no momento da criac ao de um ob-
jeto de uma classe; Destrutor: define o comportamento no momento da
destruic
ao do objeto de uma classe. Normalmente utilizado para liberar
recurso (mem oria) do sistema; Propriedade: define o acesso a um estado
do objeto; Evento: define um ponto em que o objeto pode chamar outros
procedimentos de acordo com seu comportamento e estado interno;
Obs.: Lembrar sempre que a classe define as caractersticas comuns e os
objetos s
ao inst
ancias dessa classe, com estado pr
opria.
5. Mensagens
Objetos se comunicam entre si por meio do envio de mensagens. Quando
um objeto A deseja que o objeto B realize um dos seus metodos (de B), o
objeto A envia uma mensagem para o objeto B. Algumas vezes, o objeto
que recebe a mensagem precisa de mais informac oes para saber exata-
mente o que fazer. Por exemplo, quando voce quer trocar as marchas de
uma bicicleta, deve-se indicar qual a marcha desejada. Esta informac
ao
acompanha a mensagem como um par ametro.
Assim, tres componentes fazem parte de uma mensagem:
o objeto para onde a mensagem e enderecada (bicicleta); o nome do
metodo a realizar (mudar marcha); par

ametro(s) necess
arios para realizar
o metodo (segunda marcha);
A mensagem, tambem, pode ser direcionada diretamente a uma classe por
meio da invocac
ao de um metodo din
amico.
6. Heranca
A heranca e um mecanismo que permite criar novas classes a partir de
classes j
a existentes, aproveitando-se das caractersticas existentes na classe
a ser extendida. Com a heranca e possvel criar classes derivadas (sub-
classes) a partir de classes bases (superclasses).
86
As subclasses herdam todas as caractersticas de suas superclasses, como

suas vari
aveis (estado) e seus metodos (comportamento). Entretanto, as
subclasses n
ao estao limitadas ao comportamento herdado de sua super-
classe. As subclasses podem adicionar variaveis e metodos a aqueles her-
dados.
As subclasses, tambem, podem redefinir (override) metodos herdados e
oferecer implementac
oes especializadas para estes metodos.
O conceito de heranca pode ser aplicado para mais de um nvel. A
arvore de heranca, ou hierarquia de classe, pode ser t
ao profunda quanto
necess ario. Os metodos e vari
aveis s
ao herdados por meio dos nveis. Em
geral, quanto mais baixa na hierarquia for a posic ao da classe, mais es-
pecfico e o seu comportamento.
Como benefcios do conceito de heranca, podemos citar:
Subclasses oferecem comportamentos especializados a partir de elementos
b
asicos comuns, oferecidos pela superclasse. A utilizac ao do conceito de
heranca e muito interessante, pois promove um grande reuso e reaproveita-
mento de c odigo existente; Programadores podem definir classes abstratas
que determinam comportamentos genericos. A superclasse abstrata define
e pode implementar parcialmente o comportamento de uma classe, mas a
maioria das informac oes da classe fica indefinida ou n
ao e implementada.
A heranca m ultipla ocorre quando uma classe pode estender caractersticas
de varias 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 codificac ao confusa o que dificulta a
manutenc ao do codigo. A linguagem Java n ao suporta heranca multipla,
apenas heranca simples. J a a linguagem C++ oferece suporte ` a heranca
multipla.
Uma linguagem ao utilizar heranca m ultipla est
a sujeita a dois proble-
mas: colis
ao de nomes (nomes identicos nas classes superiores) e heranca
repetida (classe herda de uma classe superior que herda de uma classe
comum);
7. Polimorfismo
Segundo a terminologia de orientac
ao a objetos, polimorfismo significa que
uma mesma mensagem enviada a diferentes objetos resulta em um com-
portamento que e dependente da natureza do objeto que est a recebendo a
mensagem. Ou seja, duas ou mais classes derivadas de uma mesma super-
classe podem invocar metodos que tem a mesma assinatura (nome, lista
de parametros e retorno), mas comportamentos distintos, especializado
para cada classe derivada, usando para tanto uma referencia a um objeto
do tipo superclasse.
A decisao sobre qual metodo deve ser selecionado, de acordo com o tipo da
classe derivada, e tomada em tempo de execuc ao por meio do mecanismo
de ligac
ao tardia. No caso do polimorfismo, e necessario que os metodos
tenham exatamente a mesma identificac ao, sendo utilizado o mecanismo
de redefinic
ao de metodos. A seguir um exemplo de polimorfismo.
87
public abstract class OperacaoMatematica

{
public abstract double calcular(double x, double y);
}
public class Soma extends OperacaoMatematica

{
public double calcular(double x, double y)
{
return x+y;
}
}
public class Subtracao extends OperacaoMatematica

{
public double calcular(double x, double y)
{
return x-y;
}
}
public class Contas

{
public static void mostrarCalculo(OperacaoMatematica operacao, double x, double y)
{
system.out.println("O resultado
e: " + operacao.calcular(x, y);
}
public static void main( String args[] )

{
//Primeiro calculamos uma soma
Contas.mostrarCalculo(new Soma(), 5, 5); //Imprime o resultado e: 10
Contas.mostrarCalculo(new Subtracao(), 5, 5); //Imprime o resultado
e: 0
}
}
Note que, embora o metodo calcular tenha sido chamado duas vezes no in-
terior de mostrarCalculo, o comportamento apresentado variou de acordo
com a classe ao qual ele representava no momento.
Os benefcios do polimorfismo s
ao: a clareza e manutenc
ao do c
odigo, a
divis
ao da complexidade e aplicac
oes flexvies.
Algumas linguagens promovem o polimorfismo principalmente por meio
do uso de classes abstratas e interfaces, como e o caso da linguagem Java.
8. Sobrecarga
A sobrecarga e um tipo de polimorfismo que permite a existencia de v
arios
metodos de mesmo nome, porem com assinaturas levemente diferentes, ou
seja, variando no n
umero e tipo de argumentos e o valor de retorno. Ficara
a cargo de o compilador escolher de acordo com as listas de argumento os
procedimentos ou metodos a serem executados. Por exemplo:
88
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;
}
}
9. Interfaces
Uma interface e uma colec
ao de definic
oes de metodos abstratos (sem im-
plementac
ao). E utilizada para os objetos interagirem entre si. A classe
que implementa a interface deve implementar todos os metodos definidos
na interface. Uma interface, tambem, pode incluir declarac oes de con-
stantes.
Apesar de uma classe abstrata implementar metodos abstratos, n ao se
pode confundir interface com classe abstrata. As classes abstratas n ao
podem ser instanciadas, e estas so s
ao utilizadas como superclasses. Por
exemplo, comida no mundo real. N ao existe uma inst ancia (objeto) do
tipo comida. O que existe s
ao inst
ancias de cenouras, mac as, bananas, etc.
Comida representa o conceito abstrato e nao e capaz de criar uma inst
ancia
pr
opria. As classes abstratas podem possuir metodos implementados.
Em Java, para definir uma interface utiliza-se a palavra interface. Emb-
ora, uma classe nao possa conter mais de uma superclasse, a classe pode
implementar mais de uma interface. Por este motivo, muitas das vezes as
interfaces s
ao apresentadas como uma alternativa para heranca m ultipla
de classes.
10. Pacotes
Para tornar as classes mais f aceis 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 orio,
ou seja, as classes e as interfaces de um mesmo pacote devem estar em um
mesmo diret orio.
A utilizac
ao de pacotes proporciona as seguintes vantagens:
Fica mais facil para outros programadores determinar quais classes e in-
terfaces est
ao relacionadas; Os nomes das classes de um pacote nao irao
89
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.
Em Java, para criar um pacote coloca-se a palavra chave package no incio
do arquivo onde a classe ou interface e definida.
Obs.: Apenas os membros (classe, vari
aveis e metodos) p
ublicos s
ao acessveis
fora do pacote onde foram definidos.
Obs.: Para uma linguagem ser considerada verdadeiramente orientada a
objetos, a linguagem de programac ao deve oferecer, no mnimo, as carac-
tersticas de: encapsulamento, heranca e polimorfismo.
6.3 Princpios de programa

cao orientada a ob-
jetos
Basicamente, os princpios de programacao orientada a objetos s
ao:
Classes, objetos e inst
ancias; Campos, metodos e propriedades; Sobrecarga;
Heranca e classes hier
arquicas; Polimorfismo; Interfaces.
6.4 Tratamento de exce

coes
O termo excec ao e usado para designar um evento que ocorre durante a execuc ao
de um programa que desvia o fluxo normal de instruc oes. Em outras palavras,
uma excec ao e uma condic ao provocada por uma situac ao excepcional que requer
uma ac ao especfica imediata. Muitos tipos de erros podem causar excec oes:
problemas que variam desde erros serios de hardware, tal como uma falha no
disco rgido, a erros simples de programac ao, tal como tentar acessar um ndice
inexistente de um vetor, divis ao por zero, um objeto n ao inicializado, etc.
Erros causam excec oes, mas podem existir excec oes que nao sao erros. Por
exemplo, numa func ao que le dados de um arquivo, a chegada ao final do arquivo
e uma condic ao excepcional que pode ser considerada como excec ao.
Linguagens como ADA, C++, JAVA e EIFFEL possuem mecanismos pr oprios
de tratamento de excec oes que facilitam a vida dos programadores tornando
ainda o c odigo mais legvel uma vez que separam o c odigo principal do c odigo
de tratamento do erro.
Quando uma excec ao ocorre, ela necessita ser tratada. A unidade ou bloco
de codigo que manipula a excec ao e denominada tratador de excec ao e a ac
ao
de indicar a ocorrencia de excec ao e transferir o controle para o tratador de

excec
ao e denominada sinalizac ao da excecao.
Tratadores de excec ao se comportam como procedimentos chamados implici-
tamente pela ocorrencia de uma excec ao. Como tratadores de excec ao nao s
ao
chamados diretamente, eles n ao possuem nome. Em sua definic ao costumam
conter vari aveis locais e bloco de c odigo de tratamento. J a as excecoes devem
possuir nome bem definido para que possam ser identificadas.
Caso o tratador que capturou a excec ao n ao tenha conhecimento suficiente
para tratar a excec ao ele pode lancar a excec
ao para um nvel superior (propagac ao
da excecao). Assim pode-se gerar uma cadeia de propagac ao ate que um trata-
dor capture a excec ao ou ate atingir-se o nvel mais alto da hierarquia dos
90
tratadores onde normalmente um tratador padr ao sera executado na sada do

programa.
Outra quest ao importante e o ponto de retorno ap os a execuc
ao do bloco
de codigo do tratador. Isto depender a do modelo de continuac ao adotado pelo
mecanismo de tratamento de excec ao. Em geral, adota-se um dos seguintes
modelos de continuac ao:
Terminacao: assume que o erro e crtico e que n ao existem condic oes de
retornar ao ponto onde a excec ao foi gerada, retornando o controle para o nvel
superior. Nesta alternativa a unidade onde ocorreu a excec ao e todas as unidades
na pilha de chamada de subprogramas ate onde o tratador de excec ao foi execu-
tado sao encerradas, continuando-se a execuc ao do programa na unidade onde
o tratador foi encontrado, ap os a regi
ao de tratamento; Retomada: assume-se
que o erro pode ser corrigido e a execuc ao pode retornar para o bloco onde
ocorreu a excecao. Portanto, o retorno e feito para o bloco gerador do erro.
Embora, em princpio, essa solucao pareca ser a mais apropriada, a experiencia
tem mostrado que essa alternativa raramente e efetiva.
Normalmente, as linguagens tem adotado o modelo de terminac ao. Em Java,
a excec
ao e um tipo especial de objeto que e criado quando algo sai de errado
em um programa. Ap os criar uma excecao, o ambiente de execuc ao envia este
objeto ao seu programa, numa ac ao denominada levantar uma excec ao. E re-
sponsabilidade do programa capturar esta excec ao. Para capturar uma excec ao
utilizam-se as clausulas try (blocos de codigos protegidos) e catch (tratadores
de excec
oes). Para passar para frente a excecao, utiliza-se a palavra trhows. As
excec
oes em Java s ao inst
ancias da classe Exception (superclasse) ou de suas
herdeiras.
91
Parte III
Metodologia de
Desenvolvimento
92
Captulo 7
Ciclo de Vida
Um modelo de ciclo de vida ou modelo de processo pode ser visto como uma
representacao abstrata de um esqueleto de processo, incluindo tipicamente algu-
mas atividades principais, a ordem de precedencia entre elas e, opcionalmente,
artefatos requeridos e produzidos. De maneira geral, um modelo de processo de-
screve uma filosofia de organizacao de atividades, estruturando as atividades do
processo em fases e definindo como essas fases est ao relacionadas. Entretanto,
ele n
ao descreve um curso de ac oes preciso, recursos, procedimentos e restric
oes.
Ou seja, ele e um importante ponto de partida para definir como o projeto deve
ser conduzido, mas a sua adoc ao n
ao e o suficiente para guiar e controlar um
projeto de software na pr atica.
Ainda que os processos tenham de ser definidos caso a caso, de maneira
geral, o ciclo de vida de um software envolve, pelo menos, as seguintes fases:
Planejamento O objetivo do planejamento de projeto e fornecer uma estru-
tura que possibilite ao gerente fazer estimativas razo aveis de recursos,
custos e prazos. Uma vez estabelecido o escopo de software, com os req-
uisitos esbocados, uma proposta de desenvolvimento deve ser elaborada,
isto e, um plano de projeto deve ser elaborado configurando o processo
a ser utilizado no desenvolvimento de software. A ` medida que o projeto
progride, o planejamento deve ser detalhado e atualizado regularmente.
Pelo menos ao final de cada uma das fases do desenvolvimento (an alise
e especificac
ao de requisitos, projeto, implementac
ao e testes), o planeja-
mento como um todo deve ser revisto e o planejamento da etapa seguinte
deve ser detalhado. O planejamento e o acompanhamento do progresso
fazem parte do processo de gerencia de projeto.
An
alise e Especifica cao de Requisitos Nesta fase, o processo de levanta-
mento de requisitos e intensificado. O escopo deve ser refinado e os req-
uisitos mais bem definidos. Para entender a natureza do software a ser
construdo, o engenheiro de software tem de compreender o domnio do
problema, bem como a funcionalidade e o comportamento esperados. Uma
vez capturados os requisitos do sistema a ser desenvolvido, estes devem
ser modelados, avaliados e documentados. Uma parte vital desta fase e
a construc
ao de um modelo descrevendo o que o software tem de fazer (e
nao como faze-lo).
93
Projeto Esta fase e responsavel por incorporar requisitos tecnol

ogicos aos req-
uisitos essenciais do sistema, modelados na fase anterior e, portanto, re-
quer que a plataforma de implementac ao seja conhecida. Basicamente,
envolve duas grandes etapas: projeto da arquitetura do sistema e projeto
detalhado. O objetivo da primeira etapa e definir a arquitetura geral do
software, tendo por base o modelo construdo na fase de an alise de req-
uisitos. Essa arquitetura deve descrever a estrutura de nvel mais alto
da aplicac
ao e identificar seus principais componentes. O prop osito do
projeto detalhado e detalhar o projeto do software para cada componente
identificado na etapa anterior. Os componentes de software devem ser su-
cessivamente refinados em nveis maiores de detalhamento, ate que possam
ser codificados e testados.
Implementa c
ao O projeto deve ser traduzido para uma forma passvel de
execuc
ao pela m
aquina. A fase de implementac
ao realiza esta tarefa, isto
e, cada unidade de software do projeto detalhado e implementada.
Testes inclui diversos nveis de testes, a saber, teste de unidade, teste de in-
tegrac
ao e teste de sistema. Inicialmente, cada unidade de software im-
plementada deve ser testada e os resultados documentados. A seguir, os
diversos componentes devem ser integrados sucessivamente ate se obter o
sistema. Finalmente, o sistema como um todo deve ser testado.
Entrega e Implanta c
ao uma vez testado, o software deve ser colocado em
producao. Para tal, contudo, e necessario treinar os usu
arios, configurar
o ambiente de produc ao e, muitas vezes, converter bases de dados. O
proposito desta fase e estabelecer que o software satisfaz os requisitos
dos usu arios. Isto e feito instalando o software e conduzindo testes de
aceitac
ao. Quando o software tiver demonstrado prover as capacidades
requeridas, ele pode ser aceito e a operacao iniciada.
Opera
cao nesta fase, o software e utilizado pelos usu
arios no ambiente de
produc
ao.
Manutenc
ao Indubitavelmente, o software sofrer a mudancas ap
os ter sido en-
tregue para o usuario. Alterac
oes ocorrerao porque erros foram encon-
trados, porque o software precisa ser adaptado para acomodar mudancas
em seu ambiente externo, ou porque o cliente necessita de funcionalidade
adicional ou aumento de desempenho. Muitas vezes, dependendo do tipo
e porte da manutencao necess
aria, essa fase pode requerer a definic
ao de
um novo processo, onde cada uma das fases precedentes e re-aplicada no

contexto de um software existente ao inves de um novo.
Os modelos de processo, de maneira geral, contemplam as fases An alise e Especi-

ficac
ao de Requisitos, Projeto, Implementac
ao, Testes e Entrega e Implantacao.
A escolha de um modelo de processo e fortemente dependente das caractersticas
do projeto. Assim, e importante conhecer alguns modelos de ciclo de vida e em
que situacoes s
ao aplic
aveis.
94
7.1 Modelo seq

uencial linear
Algumas vezes chamado de ciclo de vida cl
assico ou modelo em cascata, o modelo
seq
uencial linear requer uma abordagem sistem atica seq
uencial para o desem-
penho do software. Abrange as seguintes atividades:
Modelagem e engenharia do sistema. Estabelecimento de todos os requi-
sitos do sistema, alocacao de algum desses requisitos para o software.
An
alise de requisitos de software. O processo de definic ao de requisitos e
intensificado e focalizado especificamente no software. Os requisitos do
sistema do spftware s ao documentados e revistos com o cliente.
Projeto. Traduz os requisitos para uma representac ao do software, que pode
ser avaliada quanto à qualidade, antes que a codificac
ao tenha incio. En-
foca quatro atributos distintos: estrutura de dados, arquitetura do soft-
ware, representac
oes da interface e detalhes procedimentais (algoritmicos).
Gera
cao de c
odigo. O projeto e traduzido para linguagem de m
aquina.
Teste. S
ao conduzidos para descobrir erros e garantir que entradas definidas
produzir
ao resultados reais, que concordam com os resultados exigidos.
Manuten
cao. O software ir
a inevitavelmente sofrer modificac
oes. A manutenc
ao
reaplica cada uma das fases precedentes a um programa existente.
O modelo seq
uencial linear e o mais amplamente usado. Entre os problemas
encontrados quando esse modelo e aplicado s
ao:
1. Modificac
oes podem causar confusao `
a medida que o projeto prossegue,
pois o modelo acomoda interac
ao apenas indiretamente.
2. Exige que o cliente estabeleca todos os requisitos explicitamente.
3. Uma vers ao execut
avel do programa s
o ficar
a disponvel quando o projeto
terminar.
7.2 Modelo em V
O modelo em V e uma variac ao do modelo em cascata que procura enfatizar
a estreita relac
ao entre as atividades de teste (teste de unidade, teste de in-
tegrac
ao, teste de sistema e teste de aceitac
ao) e as demais fases do processo,
como mostra a figura 7.1.

O modelo em V sugere que os testes de unidade s ao utilizados basicamente
para verificar a implementacao e o projeto detalhado. Uma vez que os testes
de integracao est
ao focados na integrac
ao das unidades que comp oem o soft-
ware, eles tambem s ao usados para avaliar o projeto detalhado. Assim, testes
de unidade e integrac ao devem garantir que todos os aspectos do projeto do
sistema foram implementados corretamente no c odigo. Quando os testes de in-
tegrac
ao atingem o nvel do sistema como um todo (teste de sistema), o projeto
da arquitetura passa a ser o foco. Neste momento, busca-se verificar se o sis-
tema atende aos requisitos definidos na especificac ao. Finalmente, os testes de
aceitac
ao, conduzidos tipicamente pelos usu arios e clientes, valida os requisitos,
95
confirmando que os requisitos corretos foram implementados no sistema (teste

de validac
ao). A conex
ao entre os lados direito e esquerdo do modelo em V
implica que, caso sejam encontrados problemas em uma atividade de teste, a
correspondente fase do lado esquerdo e suas fases subsequentes podem ter de
ser executadas novamente para corrigir ou melhorar esses problemas.
Figura 7.1: O modelo em V
Os modelos seq uenciais pressup

oem que o sistema e entregue completo, ap
os
a realizac
ao de todas as atividades do desenvolvimento. Entretanto, nos dias
de hoje, os clientes n
ao est
ao mais dispostos a esperar o tempo necessario para
tal, sobretudo, quando se trata de grandes sistemas. Dependendo do porte do
sistema, podem se passar anos ate que o sistema fique pronto, sendo invi avel
esperar. Assim, outros modelos foram propostos visando a, dentre outros, re-
duzir o tempo de desenvolvimento. A entrega por partes, possibilitando ao
usuario dispor de algumas funcionalidades do sistema enquanto outras est ao
sendo ainda desenvolvidas, e um dos principais mecanismos utilizados por esses
modelos, como veremos a seguir.
7.3 Modelo de prototipagem

O paradigma de prototipagem comeca com a definic ao dos requisitos. Um projeto
r
apido e realizado e concentra-se na representac ao daqueles aspectos que ficar ao
visveis pelo cliente. O prot
otipo e criado e avaliado e e ajustado para satisfazer
as necessidades do cliente.
Idealmente, o prot otipo serve como um mecanismo para identificac ao dos

requisitos do software. A prototipagem pode ser problem atica, pois o cliente ve
o que parece ser uma vers ao execut avel do software, ignorando que o prot otipo
apenas consegue funcionar precariamente.
7.4 Modelo RAD

O desenvolvimento rapido de aplicaca
o (rapid application development, RAD e
um modelo incremental que enfatiza o ciclo de desenvolvimento extremamente
curto. Abrange as seguintes fases:
96
Modelagem do neg
ocio. O fluxo de informac
ao entre as func
oes do neg
ocio
e modelado.
Modelagem dos dados. O fluxo de informac
ao e refinado num conjunto de
objetos de dados.
Modelagem do processo. Os objetos de dados s ao tranformados para con-
seguir o fluxo de informac
ao necess
ario para implementar uma funcao do
neg
ocio. Descric
oes do processamento s ao criadas.
Gera
cao da aplicacao. O RAD considera o uso de tecnicas de quarta gerac
ao.
O processo RAD trabalha para reusar componentes de programas exis-
tentes ou criar componentes reus
aveis.
Teste e entrega. Os componentes novos devem ser testados e todas as inter-
faces devem ser exaustivamente exercitadas.
As desvantagens do RAD s
ao:
1. O RAD exige desenvolvedores e clientes compromissados com atividades
continuamente r
apidas.
2. Nem todos tipo de de aplicac
ao s
ao apropriados para o RAD.
3. Quando riscos tecnicos s
ao elevados o RAD n
ao e adequado.
7.5 Modelos de processo de software evolucion

arios
7.5.1 Modelo incremental
Este modelo e uma extens ao do modelo espiral sendo porem mais formal e
rigoroso. O desenvolvimento de um produto comercial de software e uma grande
tarefa que pode ser estendida por v arios meses, possivelmente um ano ou mais.
Por isso, e mais pr atico dividir o trabalho em partes menores ou iterac oes. Cada
iterac
ao resultar a num incremento. Iterac oes sao passos em fluxo de trabalho e
incrementos s ao crescimentos do produto.
O princpio subjacente ao processo incremental e iterativo e que a equipe
envolvida possa refinar e alargar paulatinamente a qualidade, detalhe e ambito
do sistema envolvido.
Por exemplo, numa primeira iterac ao deve-se identificar a vis
ao global e de-
terminar a viabilidade econ omica do sistema, efetuar a maior parte da an alise
e um pouco de desenho e implementac ao. Numa segunda gerac ao, deve-se con-
cluir a an alise, fazer uma parte significativa do desenho e um pouco mais de
implementac ao. Numa terceira iterac ao, deve-se concluir o desenho, fazer-se
parte substancial da implementac ao, testar e integrar um pouco, etc. Ou seja,
a principal consequencia da aproximac ao iterativa e que os produtos finais de
todo o processo v ao sendo amadurecidos e completados ao longo do tempo, mas
cada iteracao produz sempre um conjunto de produtos finais.
A cada iterac ao sao realizadas as seguintes tarefas:
An
alise. Refinamento de requisitos, refinamento do modelo conceitual.
Projeto. Refinamento do projeto arquitetural, projeto de baixo nvel.
97
Implementa
cao. Codificac
ao e testes.
Transi
cao para produto. Ddocumentac
ao, instalac
ao, . . ..
Vantagens do processo incremental e iterativo:

Possibilidade de avaliar mais cedo os riscos e pontos crticos do projeto, e
identificar medidas para os eliminar ou controlar.
Reduc
ao dos riscos envolvendo custos a um unico incremento. Se a equipe
que desenvolve o software precisar repetir a iterac
ao, a organizac
ao perde
somente o esforco mal direcionado de uma iterac ao, nao o valor de um
produto inteiro.
Definic
ao de uma arquitetura que melhor possa orientar todo o desenvolvi-
mento.
Disponibilizac
ao natural de um conjunto de regras para melhor controlar
os inevit
aveis pedidos de alterac
oes futuras.
Permite que os v arios intervenientes possam trabalhar mais efetivamente
pela interac
ao e partilha de comunicac
ao da resultante.
7.5.2 Modelo espiral

O modelo original em espiral organiza o desenvolvimento como um processo it-
erativo em que v arios conjuntos de fases se sucedem ate se obter o sistema final.
Um ciclo se inicia com a determinac ao de objetivos, alternativas e restric
oes
(primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabeleci-
mento de uma estrategia para alcancar os objetivos. Na segunda tarefa, an alise
e avaliac
ao de alternativas, identificac
ao e soluc
ao de riscos, executa-se uma
analise de risco. Prototipac
ao e uma boa ferramenta para tratar riscos. Se o
risco for considerado inaceit
avel, 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 e avaliado e se prepara para iniciar um
novo ciclo.
Variac
oes do modelo espiral consideram entre tres e seis tarefas ou setores
da espiral, que podem ser:
comunicac
ao com o cliente;
planejamento;
an
alise de risco;
engenharia;
construc
ao e liberac
ao;
avaliac
ao do cliente.
O modelo espiral e, atualmente a abordagem mais realstica para desen-
volvimento de software em grande escala, e usa uma abordagem que capacita
a empresa que presta o servico, e o cliente a entender e reagir aos riscos em
cada etapa evolutiva. Este tipo de modelo exige consider avel experiencia na
determinac
ao de riscos e depende dessa experiencia para ter sucesso.
98
Vantagens deste modelo:

O modelo em espiral permite que ao longo de cada iterac
ao se obtenham
vers
oes do sistema cada vez mais completas, recorrendo à prototipagem
para reduzir os riscos.
Este tipo de modelo permite a abordagem do refinamento seguido pelo
modelo em cascata, mas que incorpora um enquadramento iterativo que
reflete, de uma forma bastante realstica, o processo de desenvolvimento.
Desvantagens:
Pode ser difcil convencer grandes clientes (particularmente em situac
oes
de contrato) de que a abordagem evolutiva e control avel.
A abordagem deste tipo de modelo exige consider avel experiencia na avaliac
ao
dos riscos e baseia-se nessa experiencia para o sucesso. Se um grande risco
n
ao for descoberto, poder ao ocorrer problemas.
Este tipo de modelo e relativamente novo e n
ao tem sido amplamente
usado.
importante ter em conta que podem existir diferencas entre o prot
E otipo
e o sistema final. O prot
otipo pode n
ao cumprir os requisitos de desem-
penho, pode ser incompleto, e pode refletir somente alguns aspectos do
sistema a ser desenvolvido.
O modelo em espiral pode levar ao desenvolvimento em paralelo de m ultiplas
partes do projeto, cada uma sendo abordada de modo diferenciado, por
isso e necess
ario o uso de tecnicas especficas para estimar e sincronizar
cronogramas, bem como para determinar os indicadores de custo e pro-
gresso mais adequados.
7.5.3 Modelo espiral ganha-ganha

As melhores noegociac oes buscam um resultado ganha-ganha. Isto e, o cliente
ganha obtendo um produto ou sistema que satisfaz ` a maior parte das necessi-
dades do cliente, e o desenvolvedor ganha trabalhando com orcamentos e prazos
de entrega realsticos e possveis de serem cumpridos.
O modelo espiral ganha-ganha define um conjunto de atividades de nego-
ciac
ao no comeco de cada passagem, em torno da espiral. Ao inves de uma u nica
atividade de comunicac ao com o cliente,as seguintes atividades s
ao definidas:
1. Identificac
ao dos principais interessados do sistema ou do subsistema.
2. Determinac
ao das condic
oes de lucro do interessado.
3. Negociac
ao das condic
oes de ganho do interessado para reconcili
a-las no
ambito das condic
oes ganha-ganha para todos os envolvidos.
Alem da enfase na negociac
ao inicial, o modelo espiral ganha-ganha introduz
tres marcos de processo, chamados pontos de ancoragem, que ajudam a esta-
belecer quendo um ciclo e completado em torno da espiral e fornecem marcos
de decis ao antes do projeto de software presseguir. Esses pontos de ancoragem
s
ao:
99
Objetivos de ciclo de vida (life cycle objectives, LCO). Define um con-

junto de objetivos para cada atividade principal.
Arquitetura do ciclo de vida (life cycle architecture, LCA). Estabelece

objetivos que precisam ser satisfeitos, `
a medida que a arquitetura do sis-
tema, e do software, e definida.
Capacidade operacional inicial (initial operational capability, IOC). Representa

um conjunto de objetivos associado com a preparac
ao do software para
instalac
ao e distribuic
ao.
7.5.4 Modelo de desenvolvimento concorrente

O modelo de desenvolvimento concorrente e representado como uma serie de
grandes atividades tecnicas, tarefas e seus estados associados. Ele define uma
serie de eventos que podem disparar transicoes de um estado para outro, para
cada uma das atividades da engenharia de software. E freq
uentemente usado
como um paradigma para o desenvolvimento de aplicac oes Cliente/Servidor.
Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma
visao exata de como est
a o estado do projeto.
7.6 Desenvolvimento baseado em componentes

O desenvolvimento baseado em componentes incorpora caractersticas de tec-
nologias orientadas a objetos no modelo espiral. A atividade de engenharia
comeca com a identificac
ao de classes candidatas. Se a classe existe, ela ser
a re-
utilizada. Se a classe n
ao existe, ela ser
a desenvolvida nos moldes do paradigma
de orientac
ao a objetos.
7.7 Modelo de m
etodos formais
O modelo de metodos formais compreende um conjunto de atividades que de-
terminam uma especificacao matem atica para o software. Uma variante dessa
abordagem e denominada engenharia de software cleanroon (Sala Simpa). Uti-
lizando metodos formais eliminam-se muitos problemas encontrados nos outros
modelos, como p.ex., ambig uidade, incompletitude e inconsistencia, que podem
ser corrigidas mais facilmente de forma n ao ad hoc, mas atraves de an alise
matem atica.
7.8 T
ecnicas de quarta gera
cao
As tecnicas de quarta gerac
ao concentram-se na capacidade de se especificar o
software a uma m aquina em um nvel que esteja pr
oximo `
a linguagem natural.
Engloba um conjunto de ferramentas de software que possibilitam que:
O sistema seja especificado em uma linguagem de alto nvel.

O c
odigo fonte seja gerado automaticamente a partir dessas especificac
oes.
Atividades das tecnicas de quarta gerac

ao englobam:
100
Obten
cao dos Requisitos. O cliente descreve os requisitos os quais s
ao traduzi-
dos para um prot
otipo operacional. Os principais problemas s ao:
O cliente pode estar inseguro quanto aos requisitos.

O cliente pode ser incapaz de especificar as informac
oes de um modo
que uma ferramenta 4GL possa realizar.
As 4GLs atuais n ao s
ao sofisticadas suficientemente para acomodar
a verdadeira linguagem natural.
Estrat
egia de projeto. : Para pequenas aplicac oes e possvel mover-se do
passo de obtencao dos requisitos para o passo de implementac ao usando
uma Linguagem de 4G. Para grandes projetos e necess ario desenvolver
uma estrategia de projeto. De outro modo ocorrerao os mesmos problemas
encontrados quando se usa abordagem convencional (baixa qualidade).
Implementac
ao usando 4GL. Os resultados desejados s ao representados de
modo que haja gerac
ao autom atica de c
odigo. Deve existir uma estrutura
de dados com informacoes relevantes e que seja acessvel pela 4GL .
Teste. O desenvolvedor deve efetuar testes e desenvolver uma documentac ao

significativa. O software desenvolvido deve ser construdo de maneira que
a manutenc ao possa ser efetuada prontamente.
101
Captulo 8
An
alise Comparativa de
Processos de
Desenvolvimento
Um processo de desenvolvimento de software pode ser visto como um guia para

o desenvolvimento e deve estabelecer: as atividades a serem realizadas durante
o desenvolvimento de software, sua estrutura e organizac ao (decomposic ao e
precedencia de atividades), incluindo a definicao de um modelo de ciclo de vida;
os artefatos requeridos e produzidos por cada uma das atividades do processo;
os procedimentos (metodos, tecnicas e normas) a serem adotados na realizac ao
das atividades; os recursos necess arios para a realizac
ao das atividades, dentre
eles recursos humanos, recursos de hardware e recursos de software, incluindo
as ferramentas a serem utilizadas para apoiar a aplicac ao dos procedimentos na
realizac
ao das atividades; e roteiros para a elaborac
ao dos principais documentos
(artefatos) gerados no desenvolvimento. Entre as principais metodologias em
uso no mercado de software atualmente est ao RUP e XP.
De maneira geral, o ciclo de vida de um software envolve, pelo menos, as
atividades de planejamento, levantamento de requisitos, an alise, projeto, imple-
mentac ao, testes, implantacao, operac
ao e manutencao.
Uma vez que o software e sempre parte de um sistema (ou neg ocio) maior,
o trabalho comeca pelo estabelecimento dos requisitos para todos os elementos
do sistema e, na seq uencia, procede-se a alocac
ao para software de algum sub-
conjunto destes requisitos. Esta etapa e a Engenharia de Sistemas e antecede a
todas as demais relacionadas.
8.1 RUP - Rational Unified Process

O Processo Unificado proposto pela Rational (Rational Unified Process RUP)
foi criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma
forma sistematica para se obter reais vantagens no uso da Linguagem de Mod-
elagem Unificada (Unified Modeling Language UML). De fato, ele n ao e ex-
atamente um processo: e uma infraestrutura generica de processo que pode ser
102
especializada para uma ampla classe de sistemas de software, para diferentes

areas de aplicac
ao, tipos de organizacao, nveis de competencia e tamanhos de
projetos.
O RUP est a fundamentado em tres princpios b asicos: orientacao a casos
de uso, arquitetura e iteracao. Ele e dito dirigido a casos de uso, pois s ao os
casos de uso que orientam todo o processo de desenvolvimento. Com base no
modelo de casos de uso, s ao criados uma serie de modelos de an alise, projeto
e implementac ao, que realizam estes casos de uso. E centrado em arquitetura,
pois defende a definicao de um esqueleto para a aplicac ao (a arquitetura), a
ganhar corpo gradualmente ao longo do desenvolvimento. Finalmente, o RUP e
iterativo e incremental, oferecendo uma abordagem para particionar o trabalho
em porcoes menores ou mini-projetos. Esses tres conceitos s ao igualmente im-
portantes. A arquitetura prove a estrutura para guiar o desenvolvimento do
sistema em iteracoes, enquanto os casos de uso definem as metas e conduzem o
trabalho de cada iteracao.
O ciclo de vida adotado no RUP e tipicamente evolutivo. Contudo, uma
forma de organizac ao em fases e adotada para comportar os ciclos de desen-
volvimento, permitindo uma gerencia mais efetiva de projetos complexos. Ao
contrario do tradicionalmente definido como fases na maioria dos modelos de
ciclo de vida planejamento, levantamento de requisitos, an alise, projeto, im-
plementacao e testes, s
ao definidas fases ortogonais a estas, a saber:
Concepc
ao nesta fase, e estabelecido o escopo do projeto e suas fronteiras,
determinando os principais casos de uso do sistema. Esses casos de uso
devem ser elaborados com a precis ao necess
aria para se proceder estima-
tivas de prazos e custos. As estimativas devem ser globais para o projeto
como um todo e detalhadas para a fase seguinte. Assim, a enfase nesta
etapa recai sobre o planejamento e, por conseguinte, e necess ario levan-
tar requisitos do sistema e preliminarmente analisa-los. Ao termino dessa
fase, s
ao examinados os objetivos do projeto para se decidir sobre a con-
tinuidade do desenvolvimento;
Elaborac
ao o prop osito desta fase e analisar mais refinadamente o domnio do
problema, estabelecer uma arquitetura de fundac ao s
olida, desenvolver um
plano de projeto para o sistema a ser construdo e eliminar os elementos
de projeto que oferecem maior risco. Embora o processo deva sempre
acomodar alterac oes, as atividades da fase de elaborac ao asseguram que
os requisitos, a arquitetura e os planos estao suficientemente estaveis e que
os riscos est
ao suficientemente mitigados, de modo a se poder prever com
precisao os custos e prazos para a conclus ao do desenvolvimento.

Construc
ao durante esta fase, um produto completo e desenvolvido de maneira
iterativa e incremental, para que esteja pronto para a transic
ao `
a comu-
nidade usu aria.
Transi
cao nesta fase, o software e disponibilizado `
a comunidade usu
aria. Ap
os
o produto ter sido colocado em uso, naturalmente surgem novas consid-
erac
oes que vao demandar a construc ao de novas vers
oes para permitir
ajustes do sistema, corrigir problemas ou concluir algumas caractersticas
que foram postergadas.
103
importante realcar que dentro de cada fase, um conjunto de iterac

E oes,
envolvendo planejamento, levantamento de requisitos, an alise, projeto e imple-
mentacao e testes, e realizado. Contudo, de uma iterac
ao para outra e de uma
fase para a pr oxima, a enfase sobre as varias atividades muda, como mostra
a figura 8.1, em que a cor preta indica grande enfase, enquanto a cor branca
indica muito pouca enfase. Na fase de concepc ao, o foco principal recai sobre
o entendimento dos requisitos e a determinac ao do escopo do projeto (plane-
jamento e levantamento de requisitos). Na fase de elaborac ao, o enfoque est a
na captura e modelagem dos requisitos (levantamento de requisitos e an alise),
ainda que algum trabalho de projeto e implementac ao seja realizado para pro-
totipar a arquitetura, evitando certos riscos tecnicos. Na fase de construc ao, o
enfoque concentra-se no projeto e na implementac ao, visando evoluir e rechear
o prototipo inicial, ate obter o primeiro produto operacional. Finalmente, a
fase de transicao concentra-se nos testes, visando garantir que o sistema pos-
sui o nvel adequado de qualidade. Alem disso, usu arios devem ser treinados,
caractersticas ajustadas e elementos esquecidos adicionados.
Figura 8.1: A enfase principal de cada uma das fases
Alem dos conjuntos de iterac oes em cada fase, as fases em si podem ocorrer
de forma iterativa. Como mostra a figura 8.2, elas n ao necessariamente tem a
mesma durac ao. O esforco realizado em cada uma varia fortemente em func ao
das circunst
ancias especficas do projeto.
Figura 8.2: O modelo de ciclo de vida proposto no RUP
104
8.2 XP - Extreme Programming

A metodologia XP (Extreme Programming) e destinada a grupos pequenos de
desenvolvimento, e em projetos de durac ao de ate 36 meses. Os principais papeis
nesta metodologia s ao: Programador - foco da metodologia; Coach - respons avel
por quest oes tecnicas do projeto, maior conhecimento do processo,valores e
praticas XP. Verifica o comportamento da equipe; Tracker - Coletar sinais vi-
tais do projeto uma ou 2 vezes por semana e mantem todos informados; Gerente
- responsavel pelos assuntos administrativos,mantem um forte relacionamento
com o cliente.
Entre as principais caracteristicas da metodologia XP est ao: (i) Metaforas

- Utilizac
ao de compara oes e analogias para facilitar entendimento; (ii)Design
Simples do Sistema; (iii)Testes Automatizados - Testes de Unidade e de Aceitac ao;
(iv)Refactoring - Todo desenvolvedor tem o dever de melhorar um c odigo que es-
teja funcionado porem mal escrito; (v)Programaca o de Dupla- Todo codigo deve
ser implementado em dupla; (vi)Propriedade Coletiva do C odigo; (vii)Semana
de 40 horas - Evitar trabalhar a mais. Incialmente se obtem resultados, mas
depois h a o desgaste; (viii)Integrac
ao contnua - Eliminar erros graves de in-
tegrac
ao; (ix)Releases Curtos - Release e um conjunto de funcionalidade bem
definidas e que representam algum valor para o cliente. Um projeto XP pode
ter um ou mais releases no seu ciclo; (x)Story Cards - Cartoes escritos pelos
usuarios onde sao descritas funcionalidades do sistema; (xi)CRC - Linguagem
para Modelagem de Classes do XP. Utiliza os story cards.
8.3 Scrum
Scrum e um processo para construir software incrementalmente em ambientes
complexos, onde os requisitos n ao s
ao claros ou mudam com muita freq uencia.
Em Rugby, Scrum e um time de oito integrantes que trabalham em conjunto
para levar a bola adiante no campo. Ou seja: times trabalhando como uma
unidade altamente integrada com cada membro desempenhando um papel bem
definido e o time inteiro focando num u nico objetivo.
O objetivo do Scrum e fornecer um processo conveniente para projetos e
desenvolvimento orientado a objetos. A metodologia e baseada em princpios
semelhantes aos de XP: equipes pequenas, requisitos pouco est aveis ou descon-
hecidos, e iterac
oes curtas para promover visibilidade para o desenvolvimento.
No entanto, as dimens oes em Scrum diferem de XP.
Scrum divide o desenvolvimento em sprints de 30 dias. Equipes pequenas,

de ate 7 pessoas, sao formadas por projetistas, programadores, engenheiros e
gerentes de qualidade. Estas equipes trabalham em cima de funcionalidade (os
requisitos, em outras palavras) definidas no incio de cada sprint. A equipe toda
e responsavel pelo desenvolvimento desta funcionalidade.
Todo dia, e feita uma reuni
ao de 15 minutos onde o time exp oes `
a gerencia
o que sera feito no proximo dia, e nestas reuni oes os gerentes podem levantar
os fatores de impedimento, e o progresso geral do desenvolvimento.
Scrum e interessante porque fornece um mecanismo de informac ao de status
que e atualizado continuamente, e porque utiliza a divis ao de tarefas dentro
da equipe de forma explicita. Scrum e XP s ao complementares pois Scrum
105
prove pr
aticas
ageis de gerenciamento enquanto XP prove pr
aticas integradas
de engenharia de software.
8.4 Crystal
Crystal/Clear faz parte, na realidade, de um conjunto de metodologias criado
por Cockburn. As premissas apresentadas para a existencia deste conjunto s
ao:
Todo projeto tem necessidades, convenc

oes e uma metodologia diferentes.
O funcionamento do projeto e influenciado por fatores humanos, e h
a
melhora neste quando os indivduos produzem melhor.
Comunicacao melhor e lancamentos frequentes reduzem a necessidade de

construir produtos intermediarios do processo.
Crystal/Clear e uma metodologia direcionada a projetos pequenos, com

equipes de ate 6 desenvolvedores. Assim como com SCRUM, os membros da
equipe tem especialidades distintas. Existe uma forte enfase na comunicac ao
entre os membros do grupo. Existem outras metodologias Crystal para grupos
maiores.
Toda a especificac
ao e projeto s
ao feitos informalmente, utilizando quadros
publicamente visveis. Os requisitos s
ao elaborados utilizando casos de uso, um
conceito similar `
as est
orias de usu
ario em XP, onde s ao enunciados os requisitos
como tarefas e um processo para sua execuc ao.
As entregas das novas vers oes de software s ao feitos em incrementos regu-
lares de um mes, e existem alguns subprodutos do processo que s ao respons-
abilidade de membros especficos do projeto. Grande parte da metodologia e
pouco definida, e segundo o autor, isto e proposital; a ideia de Crystal/Clear e
permitir que cada organizac ao implemente as atividades que lhe parecem ade-
quadas, fornecendo um mnimo de suporte u til do ponto de vista de comunicacao
e documentos.
8.5 Feature Driven Development (FDD)

Metodo
agil e adaptativo
Foco nas fases de desenho e construc
ao.
Interage com outras metodologias.

N
ao exige nenhum processo especfico de modelagem.
Possui desenvolvimento iterativo.
Enfatiza aspectos de qualidade durante o processo e inclui entregas freq

uentes
e tangveis.
Suporta desenvolvimento agil com r

apidas adaptac
oes `
as mudancas de
requisitos e necessidades do mercado.
O FDD consiste de 5 processos principais:
106
Desenvolver um modelo compreensvel (Develop an overall model).

Construir uma lista de funcionalidades (Build a features list).
Planejar por funcionalidade (Plan By Feature).

Projetar por funcionalidade (Design by feature).
Construir por funcionalidade (Build by feature).
8.6 Dynamic Systems Development Method (DSDM)

Progenitor do XP. E um arcabouco para desenvolvimento r apido de aplicac
oes
(RAD). Fixa tempo e recursos ajustando a quantia de funcionalidades. Funciona
com pequenas equipes. Suporta mudancas nos requisitos durante o ciclo de vida.
Consiste em cinco fases:
Estudo das possibilidades (Feasibility study).
Estudo dos neg

ocios (Business study).
Iterac
ao do modelo funcional (Functional model iteration).
Iterac
ao de projeto e construc
ao (Design and build iteration).
Implementac
ao final (Final implementation).
Pr
aticas:
Usu
ario sempre envolvido.
Equipe do DSDM autorizada a tomar decis

oes.
Foco na frequente entrega de produtos.
Adaptac
ao ao neg
ocio e o criterio para entregas.
Construa o produto certo antes de voce constru-lo corretamente.
Desenvolvimento iterativo e incremental.
Mudancas s
ao reversveis utilizando pequenas iterac
oes.
Requisitos s
ao acompanhados em alto nvel.
Testes integrados ao ciclo de vida.
8.7 Adaptive Software Development (ASD)

iterativo e incremental. Funciona bem em sistemas grandes e complexos. E
E
uma
Arcabouco para evitar o caos. O cliente deve estar sempre presente. E
metodologia voltada para o desenvolvimento de aplicac
oes em conjunto (Joint
Application development - JAD).
Possui tres ciclos de fase:
107
Especular (Speculate). Fixa prazos e objetivos e define um plano baseado

em componentes.
Colaborar (Collaborate). Construc

ao concorrente de v
arios componentes.
Aprender (Learn). Repetitivas revis oes de qualidade e foco na demostranc ao
das funcionalidades desenvolvidas (Learning loop). Ha presenca do cliente
e de especialistas do domnio.
Os ciclos duram de 4 a 8 semanas. E orientado a miss oes (Mission-driven),

pois atividades s
ao justificadas atraves de uma miss ao, que pode mudar ao longo
do projeto. E baseado em componentes e interativo. Os prazos s ao pre-fixados
(time-boxed), pois forca os participantes do projeto a definir severamente de-
cis
oes do projeto. Uma propriedade interessante e a toler ancia a mudancas
(Change-tolerant). As mudancas s ao frequentes, ent ao e sempre melhor es-
tar pronto a adapt a-las do que control a-las. Isso e feito atraves de constante
avaliac
ao de quais componentes podem mudar.
108
Captulo 9
Engenharia de Requisitos
9.1 O Processo de Engenharia de Requisitos

As descric
oes das funcoes que um sistema deve incorporar e das restric oes que
devem ser satisfeitas s ao os requisitos para o sistema. Isto e, os requisitos de
um sistema definem o que o sistema deve fazer e as circunst ancias sob as quais
deve operar. Em outras palavras, os requisitos definem os servicos que o sistema
deve fornecer e dispoem sobre as restric oes `
a operac
ao do mesmo.
Requisitos sao, normalmente, classificados em requisitos funcionais e n ao
funcionais. Requisitos funcionais, como o pr oprio nome indica, apontam as
func
oes que o sistema deve fornecer e como o sistema deve se comportar em de-
terminadas situacoes. Ja os requisitos n
ao funcionais descrevem restric
oes sobre
as func
oes oferecidas, tais como restric
oes de tempo, de uso de recursos etc. Al-
guns requisitos nao funcionais dizem respeito ao sistema como um todo e n ao a
funcionalidade especfica. Dependendo da natureza, os requisitos n ao funcionais
podem ser classificados de diferentes maneiras, tais como requisitos de desem-
penho, requisitos de portabilidade, requisitos legais, requisitos de conformidade
etc.
Os processos de engenharia de requisitos variam muito de uma organizac ao
para outra, mas, de maneira geral, a maioria dos processos de Engenharia de
Requisitos e composta das seguintes atividades:
Levantamento (ou Descoberta ou Elicita c
ao) de Requisitos Nesta fase,
os usu
arios, clientes e especialistas de domnio s
ao identificados e trabal-
ham junto com os engenheiros de requisitos para descobrir, articular e
entender a organizacao como um todo, o domnio da aplicac ao, os proces-

sos de neg
ocio especficos, as necessidades que o software deve atender e
os problemas e deficiencias dos sistemas atuais.
An
alise de Requisitos visa a estabelecer um conjunto acordado de requisitos
consistentes e sem ambiguidades, que possa ser usado como base para
o desenvolvimento do software. Para tal, diversos tipos de modelos sao
construdos.
Documenta c
ao de Requisitos e a atividade de representar os resultados da
Engenharia de Requisitos em um documento (ou conjunto de documentos),
contendo os requisitos do software.
109
Verifica
cao e Valida c
ao de Requisitos A verificac ao de requisitos avalia se
o documento de Especificac ao de Requisitos est a sendo construdo de
forma correta, de acordo com padr oes previamente definidos, sem con-
ter requisitos ambguos, incompletos ou, ainda, requisitos incoerentes ou
impossveis de serem testados. J a a validac
ao diz respeito a avaliar se esse
documento est a correto, ou seja, se os requisitos e modelos documentados
atendem ` as reais necessidades e requisitos dos usu arios / cliente.
Ger
encia de Requisitos se preocupa em gerenciar as mudancas nos requisi-
tos j
a acordados, manter uma trilha dessas mudancas, gerenciar os rela-
cionamentos entre os requisitos e as dependencias entre o documento de
requisitos e os demais artefatos produzidos no processo de software, de
forma a garantir que mudancas nos requisitos sejam feitas de maneira
controlada e documentada.
9.2 T
ecnicas de Levantamento de Requisitos
9.2.1 Observa
c
ao
A observacao possibilita um contato pessoal e estreito do pesquisador com o
fenomeno pesquisado, o que apresenta uma serie de vantagens. As tecnicas de
observac
ao s
ao extremamente u teis para descobriraspectos novos de um prob-
lema. Isto se torna crucial nas situac oes em que nao existe uma base te orica
s
olida que oriente a coleta de dados. Ao mesmo tempo em que o contato direto
e prolongado do pesquisador com a situac ao pesquisada apresenta as vantagens
mencionadas, envolve tambem uma serie de problemas. Algumas crticas s ao
feitas ao metodo de observacao, primeiramente por provocar alterac oes no am-
biente ou no comportamento das pessoas observadas. Outra crtica e a de que
este metodo se baseia muito na interpretacao pessoal. Alem disso ha criticas no
sentido de que o grande envolvimento do pesquisador leve a uma vis ao distorcida
do fenomeno ou a uma representac ao parcial da realidade.
9.2.2 Entrevista
Entrevista e uma tecnica de elicitac
ao de requisitos muito usada. O engenheiro
de requisitos ou analista discute o sistema com diferentes usu arios , a partir da
qual elabora um entendimento de seus requisitos. H a, basicamente, 2 tipos de
entrevista: a) entrevistas fechadas onde o engenheiro de requisitos procura as
perguntas para um conjunto um pre-definido de quest oes; b) entrevistas abertas
onde nao ha agenda predefinida e o engenheiro de requisitos discute, de modo

aberto, o que os usu arios querem do sistema. Entrevistas podem ser efetivas
para desenvolver um entendimento do problema e para elicitar muitos requisitos
gerais do sistema. Usu arios finais s
ao usualmente felizes para descreverem seus
trabalhos e as dificuldades que eles enfrentam de forma relativamente natural,
entretanto eles podem ter expectativas n ao realistas sobre o suporte que o com-
putador dar a. Portanto, entrevistas sao muito menos efetivas para entendimento
do domnio da aplicac
ao e para o entendimento das quest oes organizacionais as
quais afetam os requisitos.
110
9.2.3 An
alise de Protocolo
A an alise de protocolo pede a` pessoa se engajar em alguma tarefa e corrente-
mente falar sobre esta tarefa, explicando o seu pensamento do processo. Usu arios
alegam que esse tipo de linguagem pode ser considerada uma verbalizac ao di-
reta do processo cognitivo especfico. A an alise de protocolo nao e um guia
confiavel sobre o que as pessoas est ao pensando, ela est a sujeita a problemas
de interpretacoes pelos analistas. A restric
ao em estudar protocolos e que as
pessoas podem produzir linguagens que oferece um perfil de atividade cogni-
tiva autonoma. Segundo (Goguen, 1997), mesmo se fosse possvel conseguir um
perfil de atividade cognitiva autonoma da pessoa, tal objeto seria inapropriado
para o processo de requisitos, porque o cliente n ao tem qualquer modelo mental
pre-existente do sistema desejado. Os clientes tem conhecimento sobre neg ocios
e necessidades organizacionais, enquanto o time de requisitos tem conhecimento
sobre as possibilidade tecnicas.
9.2.4 JAD
JAD e uma marca registrada da IBM. O tema principal do JAD e colocar
autoridades representativas e gerenciais juntas dentro de um workshop estrutu-
rado para promover decis oes. Segundo (Damian, 1997) JAD consiste de 5 fases:
definic
ao do projeto, pesquisa, preparac
ao para a sess
ao JAD, a sessao JAD, o
documento final. As fases de definic ao de projeto e pesquisa no processo JAD
lidam com a coleta de informac oes. A sessao JAD e entao usada para validar
as informacoes recolhidas nas fases anteriores. O processo JAD concentrase na
sessao JAD, e deste modo JAD contribui para a elicitac ao de requisitos como
significado para validar as informacoes j
a colhidas. Na sess
ao JAD, as pessoas
certas tem que estar envolvidas, e a presenca de um facilitador pode ajudar a
manter a sess ao focalizada e minimizar ataques e defesas emocionais improdu-
tivas. JAD promove cooperac ao, entendimento, e trabalho em grupo entre os
varios grupos de usuarios e o pessoal de sistemas de informac
ao.
9.2.5 PD
Tradicionalmente valores democr aticos, os quais tem sido levados em conta no
processo de projeto, tem sido somente aqueles concentrados em fatores tecnicos
e economicos. Mas com o uso do PD fatores tecnicos-sociais tem sido levados em
conta. O projeto deveria ser feito com o usu ario. Aprendizado m utuo deveria
ser uma parte importante do trabalho em um grupo de projeto, n ao sendo
meramente uma visita aos laborat orios de pesquisa. Trabalhadores e clientes s
ao
inteligentes e criativos, contribuidores produtivos para as organizacoes, desde

que sejam encorajados a expressarem seus desejos, aplicarem sua esperteza e
exercitarem suas capacidades de tomar decis oes, assumindo responsabilidades
do impacto de suas ac oes.
9.2.6 QFD
O termo qualidade e definido como um conjunto de meios para produzir eco-
nomicamente produtos ou servicos, os quais satisfacam os requisitos do cliente.
QFD e um conceito que prove meios de interpretar requisitos do cliente em req-
uisitos tecnicos, apropriados para cada est
agio do desenvolvimento e produc ao
111
do produto(Damian, 1997). As fases iniciais do QFD podem ser descritas como

sendo simplesmente um sistema de identificac ao e priorizac
ao das necessidades
do cliente obtidas de cada recurso avaliado. QFD e um conceito que aplica-se
bem para a elicitac
ao de requisitos, especialmente num modelo de elicitac ao
onde a voz do cliente e o guia para a criac
ao de requisitos.
9.2.7 CRC
Como definido em (Zhu, 1998), CRC e uma sess ao de grupo, que e similar ao
JAD, onde os papeis dos participantes e o papel do facilitador sao claramente
definidos. Em CRC, participantes consistem nao somente de usu arios e facilita-
dor, mas tambem de outras pessoas envolvidas indiretamente no sistema. CRC
e diferente de JAD e QFD pois ele foca-se no usuario operativo.
9.2.8 Prototipa
cao
Este metodo para elicitac
ao de requisitos utiliza-se do uso de uma tecnica de
prototipac
ao para a avaliac
ao do usu ario. O conjunto inicial de requisitos e
usado como base para criar o Prot otipo de Interface do Usu ario com o sis-
tema inicial (simplificado). Para essa criac ao, o projetista precisa manter o
prot
otipo tao simples quanto possvel. O ponto forte desta atividade e apre-
sentar muitas alternativas para o usu ario antes de se gastar muito esforco para
qualquer prototipo em particular. Ap os a aceitac
ao do prot
otipo pelos usu
arios,
os desenvolvedores precisam criar um documento de especificac ao dos requisitos
paralelo ao prototipo de interface (McConnel, 1998).
9.2.9 Cen
arios
Usuarios finais e outros agentes do sistema acham a utilizac ao de cen arios mais
f
aceis para relacionar-se aos exemplos da vida real do que descric oes abstratas
das func
oes realizadas pelo sistema. Por essa raz ao, e freq
uentemente u til desen-
volver um conjunto de interacao dos cen arios, e usar estes para elicitar e clarear
requisitos de sistema. Cen arios s
ao exemplos de sess oes de interac
ao as quais
s
ao concentradas com um tipo u nico de interac
ao entre um usu ario final e o sis-
tema. Usu arios finais simulam suas interacoes usando cen arios. Eles explicam
para o time de engenheiros de requisito o que eles est ao fazendo e a informac ao
da qual eles precisam do sistema para descrever a tarefa descrita no cen ario.
9.2.10 FAST
Tecnicas facilitadas de especificac

ao de aplicac
oes (facilitated application spec-
ification techniques). Consiste nos seguintes passos:
1. Reunioes iniciais entre o cliente e o desenvolvedor (sess

ao de perguntas e
respostas). Produzem como resultado a solicitac ao de produto.
2. Sao selecionados local, hor

ario e data para o FAST e e escolhido um facil-
itador.
3. A solicitac
ao de produto e distribuda para todos os participantes antes
da data da reuni ao.
112
solicitado a cada participante que faca uma lista dos objetos que s
4. E ao
parte do ambiente , uma lista de servicos (processos ou func oes), uma
lista de restric
oes (custo, tamanho, regras de neg
ocio) e criterios de de-
sempenho.
5. Quando a reuni ao a FAST comeca, o primeiro t

opico de discuss
ao e a
necessidade e a justificativa do produto.
6. Cada um apresenta suas listas, crticas e debates s

ao proibidos nesta etapa.
7. Uma lista combinada que elimina objetos redundantes e produzida, mas

n
ao apaga nada.
8. A lista e modificada com uma discuss

ao dirigida pelo facilitador. O pro-
duto e a lista de consenso.
9. A equipe e subdividida em equipes menores; cada uma trabalha para

produzir miniespecificaco
es, ou seja, detalham cada objeto da lista de
consenso.
10. As equipes apresentam suas miniespecificac
oes e a lista e modificada no-
vamente atraves de discuss
oes.
11. Cada participante da reuni

ao cria os criterios de validac
ao para os elemen-
tos da lista.
12. Uma lista de consenso de criterios de validac

ao e criada.
13. Alguem fica respons
avel em redigir o rascunho completo das especificac
ao.
9.3 An
alise de Requisitos
A analise de requisitos e uma atividade de engenharia de software que vence
o especo entre a engenharia de requisitos, no nvel de sistema, e o projeto de
software. As atividades de engenharia de requisitos resultam na especificac ao
das caractersticas operacionais do software (func ao, dados e comportamento).
A analise de requisitos constroi modelos de domnio que fornecem ao projetista
uma vis ao do software.
A especificac
ao de requisitos e produzida no auge da tarefa de an
alise. Alguns
padroes sugerem que uma especificac ao de requisitos deve conter:
Introdu
cao. Declara as metas e objetivos do software.
Descri
cao da informa c
ao. Fornece uma descric
ao detalhada do problema que
o software deve resolver. O conte
udo, fluxo e estrutura da informac
ao s
ao
documentados.
Descri
cao funcional. Uma narrativa de processamento e fornecida para cada
func
ao.
Descri
cao comportamental. Examina a operac ao do software como consequencia
de eventos externos e caractersticas de controle geradas internamente.
113
Crit
erios de valida c
ao. Informa como devemos reconhecer uma implementacao
bem-sucedida e quais classes de testes devem ser conduzidas para validar
a func
ao, o desempenho e as restric
oes.
Bibliografia e ap endice. A bibliografia contem todos os documentos que se
relacionam ao software. O apendice contem informacoes que suplementa
as especificac
oes.
9.3.1 M
etodos de an
alise
Entre os mais importantes metodos de an alise, tres se destacam: A an
alise estru-
turada, a an
alise essencial e a an
alise orientada a objetos. A seguir discutiremos
suas principais caractersticas.
An
alise estruturada
A An alise Estruturada adota uma visao de desenvolvimento baseada em um
modelo entrada-processamento-sada. No paradigma estruturado, os dados sao
considerados separadamente das func
oes que os transformam e a decomposic
ao
funcional e usada intensamente.
An
alise essencial
Os metodos orientados a funcoes conduzem o desenvolvimento de software estru-
turando as aplicac oes segundo a otica das func
oes (ac
oes) que o sistema dever
a
realizar. Os metodos orientados a dados, por sua vez, enfatizam a identificac ao
e estruturac ao dos dados, subjugando a an alise das func
oes para um segundo
plano. Esses metodos tem origem no projeto de bancos de dados e, geralmente,
tem no modelo de Entidades e Relacionamentos (ER) sua principal ferramenta.
A an alise essencial e uma metodologia estruturada, sendo uma evoluc ao da
analise estruturada. Essa metodologia procurou conciliar as abordagens ori-
entadas a dados e a func oes em um u nico metodo, utilizando modelos para
dados, func oes e controles (DFDs, DERs e Diagramas de Transic ao de Estados,
respectivamente) como ferramentas para a modelagem de sistemas.
An
alise orientada o objeto
A orientac
ao a objetos pressup
oe que o mundo e composto por objetos, onde
um objeto e uma entidade que combina estrutura de dados e comportamento
funcional. No paradigma orientado a objetos, os sistemas s ao estruturados a
partir dos objetos que existem no domnio do problema, isto e, os sistemas s

ao
modelados como um n umero de objetos que interagem.
9.3.2 Modelagem da an
alise
DFDs
Ferramenta de modelagem utilizada para descrever a transformac ao de entradas
em sadas. Representa um sistema como uma rede de processos interligados
entre si por fluxos de dados e dep a ferramenta de modelagem
ositos de dados. E
mais importante da an alise estruturada. Junto com o DER, e a ferramenta mais
importante da an alise essencial. Seus componentes s ao:
114
Processo. Tambem chamado de func ao, bolha ou transformac

ao, o processo
representa as transformac
oes realizadas sobre os dados em um sistema e
correspondem a func
oes ou procedimentos que um sistema tem que prover.
representado graficamente por crculos e deve ter um nome composto
E
por um verbo e um objeto.
Fluxo de dados. Representa uma colec ao de itens de dados em movimento. E

representado graficamente atraves de uma seta entrando ou saindo de um
processo, com a ponta indicando o sentido do fluxo. Deve ter associado
um nome o mais significativo possvel, de modo a facilitar a validac
ao do
diagrama com os usu arios. Esse nome deve ser um substantivo que facilite
a identificac
ao da colecao de dados transportada.
Dep
osito de dados. O dep osito de dados e utilizado para modelar um repositorio
de uma colec
ao de pacotes de dados em repouso. E representado grafica-
mente por duas linhas paralelas com um nome que represente seu conte udo
e que normalmente e o plural do nome dos pacotes transportados pelos
fluxos para dentro e para fora do dep osito.
Terminador ou entidade externa. Entidades externas ou terminadores s ao

fontes ou destinos de dados do sistema. Representam os elementos do am-
biente com os quais o sistema se comunica. Tipicamente, uma entidade
externa e uma pessoa (p.ex. um cliente), um grupo de pessoas (p. ex. um
departamento da empresa ou outras instituic
oes) ou um outro sistema que
interaja com o sistema em quest ao. Uma entidade externa deve ser iden-
tificada por um nome e representada por um ret angulo. Assim como no
caso dos depositos de dados, em diagramas complexos, podemos desenhar
um mesmo terminador mais de uma vez, para se evitar o cruzamento de
linhas de fluxos de dados ou para impedir que longas linhas de fluxos de
dados saiam de um lado a outro do diagrama.
Quando o software e complexo, devemos organizar o DFD em nveis. Dois

DFDs especiais est
ao presentes em qualquer modelo funcional:
Contexto. Mostra o sistema como uma caixa-preta, trocando informac

oes (fluxos
de dados) com entidades externas ao sistema.
Nvel 0 - Geral ou de Sistema. E uma decomposic ao do diagrama de con-

texto, mostrando o funcionamento do sistema em quest ao, isto e, as grandes
func
oes do sistema e as interfaces entre elas. Os processos nesse diagrama
recebem os n necess
umeros 1, 2, 3, etc. . . E ario assegurar a coerencia en-
tre os diagramas de contexto e de nvel 0, isto e, assegurar que os fluxos

de dados entrando ou saindo do diagrama efetivamente reproduzem as en-
tradas e sadas do diagrama de contexto. Neste diagrama, devem aparecer
os depositos de dados necess arios para a sincronizacao dos processos.
Dicion
ario de Dados
O dicionario de dados e uma listagem organizada de todos os elementos de
dados pertinentes ao sistema, com definic
oes precisas para que os usu
arios e
desenvolvedores possam conhecer o significado de todos os itens de dados. Ex-
emplificando para uma estrutura de dados nome: nome = ttulo-cortesia +
115
primeiro-nome + (nome-intermedi
ario) + u ltimo-nome, ttulo-cortesia = [Sr.
Sra. Srta. Dr. Professor] etc. . .
Aspectos de an
alise essencial
O modelo comportamental determina o comportamento interno do sistema para
que este possa interagir corretamente com o ambiente. Ap
os a construc
ao do
modelo comportamental, teremos os seguintes artefatos:
Diagrama de Entidades e Relacionamentos.
Diagramas de Fluxos de Dados Preliminar (DFD Particionado por Eventos).

Para cada evento do sistema, deve ser construdo um DFD.
Diagramas de Fluxos de Dados Organizados em Nveis Hier arquicos.

Representa os processos em nveis hier
arquicos, a partir do diagrama zero.
Diagramas de Transi c
ao de Estados. Representa o comportamento das en-
tidades e relacionamentos com atributos ao longo do tempo. Ser a con-
strudo um DTE para cada entidade ou relacionamento com atributo do
DER que possuir comportamento significativo, isto e, possuir mais de um
estado ao longo de seu ciclo de vida.
Dicionario de Dados. Descreve os dados representados no DER, nos DFDs

e nos DTEs.
Especificac
ao da L ogica dos Processos (Mini-especifica c
oes). Descreve
a l
ogica dos processos do DFD que n ao foram detalhados em diagramas
de nvel inferior (l
ogica dos processos primitivos).
Como podemos perceber, a an alise essencial faz uso praticamente das mesmas
tecnicas de modelagem da analise estruturada, a saber a modelagem de dados
(utilizando modelos de entidades e relacionamentos), a modelagem funcional
(utilizando Diagramas de Fluxo de Dados - DFDs) e a modelagem de controle
(utilizando diagramas de transic ao de estados). Isso e bastante natural, j a
que a an alise essencial e, de fato, uma extens ao da analise estruturada. Na
realidade, a principal diferenca entre a an alise essencial e a an
alise estruturada
esta na estrategia para atacar o problema: a primeira defende uma abordagem
baseada em eventos, onde a an alise de eventos passa a ser um passo fundamental,
a segunda e baseada apenas na decomposic ao top-down da funcionalidade do
sistema.
9.4 Gerenciamento de Requisitos

Gerenciar requisitos consiste de procedimentos para coletar, verificar e avaliar
mudancas, de forma melhor administr o considerado uma das primeiras
a-las. E
areas chave para melhoria de qualidade. No gerenciamento de requisitos um

conceito importante e o de rastreabilidade. A rastreabilidade pode ser vista
como a habilidade de acompanhar e descrever a vida de um requisito em ambas
as direc
oes. Rastrear envolve identificar links entre requisitos, fontes dos requi-
sitos e design do sistema. As ferramentas mais utilizadas para rastreamento de
116
requisitos s
ao as Matrizes de Rastreabibilidade (Traceability Matrix ), que usual-
mente correlacionam requisitos com casos de testes, e tecnicas de Referencias
Cruzadas. Entre os produtos de mercado utilizadas para realizar gerenciamento
e rastreamento de requisitos podemos citar o Rational RequisitePro, Caliber-RM,
RTS e RDT.
117
Captulo 10
M
etricas
Metricas devem ser coletadas de modo que os indicadores de processo e de

produto possam ser determinados. Indicadores de processo permitem ` a orga-
nizac
ao de engenharia de software ter ideia da efic
acia de um processo existente
(o paradigma, as tarefas de engenharia de software, os produtos de trabalho e os
marcos de tempo). J a os indicadores de projeto permitem ao gerente de projeto
de software:
Avaliar o status de um projeto em andamento.
Acompanhar riscos potenciais.
Descobrir
areas-problemas anter que elas se tornem crticas.
Ajustar fluxo de trabalho ou tarefas.
Avaliar a capacidade da equipe de projeto de controlar a qualidade dos
produtos do trabalho de software.
Em alguns casos, as mesmas metricas podem ser usadas para determinar
indicadores de projeto e de processo.
10.1 Metricas de processo e aperfei

coamento de
processo de software
Nos medimos a efic acia de um processo de software indiretamente. H a usos
publicos e privados de diferentes tipos de dados do processo. As metricas co-
letadas com base individual dever ser privadas e servir como indicador apenas
para o indivduo. Exemplo de metricas privadas incluem porporc ao de defeitos
(por indviduo e por m odulo) e erros encontrados durante o desenvolvimento.
Metricas publicas geralmente assimilam informac oes, que eram originalmente
privadas. Porporc oes de defeitos de projeto (absolutamente n ao atribuveis a
um certo indivduo), esforco, tempo transcorrido e dados relacionados s
ao coleta-
dos e avaliados numa tentativa de sescobrir indicadores, que possam aperfeicoar
o desempenho do processo organizacional.
Ha uma sutil diferenca entre erros e defeitos. Um defeito ocorre quando
atividades de garantia de qualidade deixam de descobrir um erro num produto
produzido durante o processo de software.
118
` medida que uma organizac

A ao sente-se mais confort
avel, coletanto e usando
metricas de processo de software, a derivac ao de indicadores simples d a lugar
a uma abordagem mais rigorosa, chamada melhoria estatstica do processo de
software (statistical software process improvemente, SPPI). Essencialmente, a
SSPI usa a an alise de falhas de software para coletar informac ao sobre todos
erros e defeitos. A analise de falhas funciona da seguinte maneira:
1. Todos os erros e defeitos s ao categorizados por origem (falha de especi-
ficac
ao, falha de l
ogica, n
ao atendimento a padroes).
2. O custo para corrigir cada erro e defeito e registrado.
3. A quantidade de erros e defeitos de cada categoria e contada e ordenada

de forma decrescente.
4. O custo total de erros e defeitos de cada categoria e calculado.
5. Os dados resultantes s
ao analisados, para descobrir as categorias que pro-
duzem um maior custo para a organizac ao.
6. S
ao desenvolvidos planos para modificar o processo, com o objetivo de
eliminar (ou reduzir a freq
uencia das) classes de erros e defeitos que s
ao
mais dispendiosas.
Para a organizacao dessas metricas s

ao utilizados o gr
afico de pizza que associa
os erros e defeitos `
as suas origens e o diagrama espinha de peixe.
10.2 M
etricas de projeto
As metricas de projeto s
ao usadas para evitar atrasos, avaliar a qualidade e n ao
ultrapassar os custos permitidos. A primeira aplicac ao das metricas de projeto,
na maioria dos projetos de software, ocorre durante a estimativa. Metricas
coletadas de projetos anteriores s
ao usadas como base e ` a medida que o projeto
prossegue, medidas de esforco e de tempo s ao comparadas com as estimativas
originais. Dessa maneira, o gerente do projeto monitora e controla o progresso.
` medida que o trabalho tecnico se inicia, outras metricas de projeto comecam
A
a ter importancia. A taxa de produc ao, representada em termos de p aginas de
documentac ao, horas de revisao, pontos por func ao e linhas de c odigo fonte
entregue, e medida. A ` medida que o software evolui, metricas tecnicas s ao
coletadas para avaliar a qualidade do projeto.
10.3 Medic
ao de software
As medicoes sao categorizadas em medidas diretas e indiretas. As medidas di-
retas do processo de engenharia de software incluem custo, linhas de c odigo
(lines of code, LOC) produzidas, velocidade de execucao, tamanho de mem oria
e defeitos relatados durante um certo perodo. Medidas indiretas do produto in-
cluem funcionalidade, qualidade, complexidade, eficiencia, confiabilidade, manuteni-
bilidade e muitas outras habilidades.
119
10.3.1 M
etricas orientadas a tamanho
Sao metricas baseadas em linhas de c
odigo. Metricas orientadas a tamanho
nao s
ao universalmente aceitas como o melhor modo de medir o processo de
desenvolvimento de software. Os opositores argumentam que essas metricas pe-
nalizam programas curtos e bem feitos e que medidas de LOC s ao dependentes
da linguagem de programacao. Por outro lado, existem muitos modelos de esti-
mativas que usam LOC ou KLOC como entrada chave e essas metricas podem
ser facilmente coletadas. As metricas orientadas a tamanho mais utilizadas
incluem:
Erros por KLOC (milhares de linha c
odigo).
Defeitos por KLOC.
$ por LOC.
P
aginas de documentac
ao por KLOC.
Erros por pessoa-mes.
LOC por pessoa-mes.
$ por p
agina de documentac
ao.
10.3.2 M
etricas orientadas a func
ao
Metricas de software orientadas a funcao usam uma medida da funcionalidade
entregue pela aplicacao como valor de normalizacao.
Pontos por func
ao s
ao calculados completando a tabela 10.1. Cinco carac-
tersticas do domnio da informac
ao s
ao determinadas e as contagens s ao reg-
istradas na tabela. Essas caractersticas s
ao definidas da seguinte maneira:
Quantidade de entradas do usu ario. S
ao contadas as entradas do usu
ario
que fornecem dados distintos.
Quantidade de sadas do usu
ario. S
ao contados telas, relat
orios, mensagens
de erros etc.
N
umero de consultas do usu ario. S
ao contadas consultas distintas. Uma
consulta e definida como um entrada que resulta na gerac
ao de alguma
resposta imediata.
Quantidade de arquivos. Cada grupo de dados l ogico (que pode ser parte
de uma base de dados maior ou um arquivo separado) e contado. Esses
grupos de dados tambem s

ao conhecidos como arquivos mestres l
ogicos.
Quantidade de interfaces externas. Todas as interfaces em linguagem de
maquina (p. ex., arquivos de dados em um meio de armazenamento), que
s
ao usadas para transmitir informac
ao a outro sistema s
ao contadas.
Uma vez coletados esses dados, um valor de complexidade e associado com
cada contagem. Para contar pontos por funcao (function points, FP), e usada
a seguinte relac
ao: P
FP = total da contagem [0, 65 + 0, 01 (Fi )]
Os Fi sao valores de ajuste de complexidade, baseados nas respostas das
seguintes perguntas:
120
Par
ametro de medic
ao Contagem Simples Medio Complexo Total
Quantidade de entradas do usu

ario x 3 4 6
Quantidade de sadas do usu
ario x 4 5 7
Quantidade de consultas do usu
ario x 3 4 6
N
umero de arquivos x 7 10 15
Quantidade de interfaces externas x 5 7 10
Tabela 10.1: Tabelas das caractersticas dos pontos de func

ao
1. O sistema requer salvamento (backup) e recuperac

ao (recovery)?
2. Comunicac
oes de dados s
ao necess
arias?
3. H
a func
oes de processamento distribudo?
4. O desempenho e crtico?
5. O sistema vai ser executado em um ambiente operacional existente, inten-
samente utilizado?
6. O sistema requer entradas de dados on-line?
7. A entrada de dados on-line exige que a transac ao de entrada seja con-
struda atraves de v
arias telas ou operac
oes?
8. Os arquivos mestre s
ao atualizados on-line?
9. As entradas, sadas, arquivos ou consultas s
ao complexas?
10. O processomento interno e complexo?
11. O c
odigo e projetado para ser reusado?
12. A convers
ao e a instalac
ao est
ao includas no projeto?
13. O sistema est
a projetado para instalac
oes m
ultiplas em diferentes orga-
nizac
oes?
14. A aplicac
ao est
a projetada para facilitar modificac
oes e para facilidade de
uso pelo usuario?
Cada uma dessas quest oes e respondida usando uma escala que varia entre 0 a
5. Os valores constantes e os fatores de peso podem ser ajustado empiricamente

para a equac
ao dos pontos de funcao. S
ao exemplos importantes de medidas de
produtividade, qualidade e outros atributos de software as metricas:
Erros por FP.
Defeitos por FP.
$ por FP.
P
aginas de documentacao por FP.
FP por pessoa-mes.
121
10.3.3 M
etricas de pontos por funcao estendidas
A medida de pontos por func ao foi originalmente projetada para ser usada
em aplicac oes de sistemas de informacao comerciais. A medida de pontos por
funcao ficou inadequada para muitos sistemas embutidos e de engenharia (que
enfatizam func ao e controle).
Uma extens ao de pontos por func
ao, chamada pontos por caracterstica uti-
lizada em eplicac oes de software de sistemas. Para calcular pontos por carac-
terstica, valores de domnio de informacao s
ao novamente contados e ponder-
ados. Alem disso, a metrica pontos por caracterstica trata uma nova carac-
tersitca do software: algoritmos.
Outra extens ao de pontos por funcao, para sistemas em tempo real e pro-
dutos de engenharia, foi desenvolvida pela Boeing. Essa abordagem integra a
dimens ao de dados do software com as dimens oes funcional e de controle para
forncer uma medida orientada a func ao, adequada a aplicacoes que enfatizam
as capacidades de func ao e controle. Essa extens ao e chamada de pontos por
funcao 3D. As tres dimensoes s
ao:
Dimensao de dados. Semelhante a contagem de pontos por func
ao tradi-
cional.
Dimens ao funcional. Considera a quantidade de operac
oes internas necess
arias
para transformar dados de entrada para transformar dados de entrada em
sada.
Dimens medida contando a quantidade de transic
ao de controle. E oes entre
estados.
10.4 M
etricas de qualidade de software
A medic
ao da qualidade de software e uma atividade de natureza subjetiva.
Qualidade de software e uma mistura complexa de fatores que vao variar com
cada aplicac
ao diferente e com os clientes que as encomendam. As principais
medidas sao mostradas a seguir:
Corre
cao. A medida mais comum e defeitos por KLOC. Para fins de avaliac
ao
de qualidade, defeitos sao contados durante um perodo padr
ao, tipica-
mente um ano.
Manutenibilidade. Uma metrica utilizada e o tempo medio para modicac ao

(mean-time-to-change, MTTC), que e o tempo despendido para analisar o

pedido de modificac ao, projetar uma modificac ao adequada, implementar
a modificac
ao, test
a-la e distribu-la para todos os usu
arios. Outra metrica
e chamada prejuzo - custo para corrigir defeitos encontrados depois que
o software foi entregue a seus usu arios finais.
Integridade. E a capacidade do sistema resistir `

a ataques (tanto acidentais
quanto intencionais). Ameaca e a probabilidade de um ataque ocorrer
a probabilidade de um ataque
dentro de um certo perodo. Seguranca. E
ser repelido.
P A integridade do sistema pode ser ent
ao definido como inte-
gridade = (1 ameaca) (1 seguranca).
122
Utiliza
cao. Se e amig avei ao uso. Pode ser medida em quatro t opicos: (1)
aptidao fsica ou intelectual necess
aria para aprender a lidar com o sistema,
(2) o tempo necess ario para se tornar moderadamente eficiente no uso
do sistema, (3) o aumento lquido de produtividade e (4) uma avaliac ao
subjetiva das atitudes dos usu arios com relac
ao ao sistema.
Outra medicao muito utilizada e a eficiencia na remoc
ao de defeitos defect
removal efficiency, DRE). A DRE e uma medida da capacidade de filtragem das
atividades de controle e garantia de qualidade de software, ` a medida que sao
aplicadas. A formula utilizada e DRE = E/(E + D). Onde E e a quantidade
de erros encontrados e D a quantidade de defeitos.
As principais formas de classificar fatores de qualidade sao apresentadas nas
subsec
oes a seguir.
10.4.1 Fatores de qualidade de McCall

Os fatores de qualidade de McCall concentram-se nos tres aspectos importantes
de um produto de software: suas caractersticas operacionais, sua habilidade de
passar por modificacoes e sua adaptabilidade a novos ambientes. A seguir s ao
listados esses aspectos e os seus respectivos fatores:
Opera
cao do produto. Correc
ao, confiabilidade, utilizac
ao, integridade e eficiencia.
Revis
ao do produto. Mantenabilidade, flexibilidade e testabilidade.
Transi
cao do produto. Portabilidade, reutilizac
ao e interoperabilidade.
difcil desenvolver medidas diretas desses fatores. Assim, um conjunto de
E
metricas e definido e usado para desenvolver expressoes para cada um dos fatores
de acordo com a seguinte relac ao: Fq = c1 m1 + c2 m2 ... + cn mn , em que
Fq e um fator de qualidade de software, cn s ao coeficientes de regress
ao, mn s
ao
as metricas que afetam o fator de qualidade. Infelizmente, muitas das metricas
definidas podem ser medidas apenas sunjetivamente. As metricas podem estar
em forma de checklist que e usada para atribuir um grau a atributos especficos
do software. O peso atribudo a cada metrica e dependente de produtos e
preocupac oes locais.
10.4.2 FURPS
A Hewlett-Packard desenvolveu um conjunto de fatores de qualidade que re-
cebeu a sigla FURPS: funcionalidade, utilizac
ao, confiabilidade, desempenho e
suportabilidade. Esses fatores podem ser definidos da seguinte maneira:
Funcionalidade. Avaliada pelo conjunto de caractersticas e capacidades do

programa.
Utiliza
cao. Avaliada considerando fatores humanos como estetica, consistencia
e documentacao.
Confiabilidade. Avaliada medindo a freq uencia e a severidade das falhas, a
precis
ao dos resultados de sada, o tempo medio entre falhas (MTTF), a
capacidade de recuperac
ao de falhas e previsibilidade do programa.
123
Desempenho. Medido pela velocidade de processamento, tempo de resposta,

consumo de recursos, throughput e eficiencia.
Suportabilidade. Combina a capacidade de estender o programa (estensibili-

dade), adaptabilidade e reparabilidade.
10.4.3 ISO 9126

A norma da ISO identifica seis atributos-chave de qualidade:
Funcionalidade. Grau com que o software satisfaz as necessidades declaradas

com os subatributos - adequabilidade, precis
ao, interoperabilidade, atendibil-
idade e seguranca.
Confiabilidade. Perodo de tempo em que o software esta disponvel para uso

com os subatributos - maturidade, toler
ancia a falha e recuperabilidade
Utiliza
cao. Grau em que o software e f acil de usar com os subatributos -
inteligibilidade, adestrabilidade e operabilidade.
Efici
encia. Grau em que o software faz uso otimizado dos recursos do sistema
com os subatributos - comportamento em relac
ao ao tempo e comporta-
mento em relac
ao aos recursos.
Mantenabilidade. Facilidade com a qual podem ser feitos reparos no soft-

ware com os subatributos - analisabilidade, mutabilidade, estabilidade e
testabilidade.
Portabilidade. Facilidade com a qual o software pode ser transposto de um

ambiente para outro com os subatributos - adaptabilidade, instabilidade,
conformidade e permutabilidade.
Esses fatores n
ao necessariamente se prestam a medidas diretas. No entanto,
fornecem de fato uma base valiosa para medidas indiretas e uma excelente lista
de verificac
ao para avaliar a qualidade de um sistema.
10.5 Estimativas
Muitas vezes, as estimativas s ao feitas usando-se a experiencia passada como
u
nico guia. Mas se um novo projeto for totalmente diferente dos projetos re-
alizados ate o momento? Assim, apenas a experencia passada talvez n ao seja
suficiente. Varias tecnicas de estimativa est

ao disponveis. Embora cada uma
tenha suas particularidades, todas tem os seguintes atributos:
1. O escopo do projeto deve estar estabelecido.
2. Metricas de software s
ao utilizadas e o hist
orico e usado como uma base
a partir da qual estimativas sao feitas.
3. O projeto e dividido em pequenas partes que s

ao estimadas individual-
mente.
124
10.5.1 COCOMO (Constructive Cost Model)

O COCOMO e o modelo de estimativa emprico mais utilizado na ind
ustria.
Existem tres modelos neste metodo:
COCOMO B asico. E um modelo estatico de valor simples que computa o
esforco (e custo) de desenvolvimento de software como uma funcao do
tamanho de programa expresso em linha de c odigo estimadas.
COCOMO Intermedi ario. Computa o esforco de desenvolvimento de soft-

ware como uma func ao do tamanho do programa e de um conjunto de
direcionadores de custo que incluem avaliac
oes subjetivas do produto, do
hardware, do pessoal e dos atributos do projeto.
COCOMO Avan cado. Incorpora todas as caractersticas da vers ao inter-

medi
aria, com uma avaliacao do impacto dos direcionadores de custo sobre
cada passo (an
alise, projeto, etc.) do processo de engenharia de software.
O COCOMO classifica os projetos em tres tipos:
Modelo org anico (ou convencional). Projetos de software simples, relati-
vamente pequenos, nos quais pequenas equipes com boa experiencia em
aplicac
oes trabalham num conjunto de requisitos nao tao rgidos. Outras
caractersticas: ambiente est
avel de desenvolvimento, algoritmos simples,
premio relativamente baixo para termino antes do prazo, tamanho relati-
vamente pequeno, projetos na faixa de 50.000 linhas de c odigo.
Modelo semidestacado (ou difuso). Projeto de software intermedi ario (em

tamanho e complexidade) onde a equipe mescla grande e pouca experiencia
com aplicac
oes, grande e pouca experiencia com a tecnologia, o tamanho
dos software varia ate 300.000 linhas de c
odigo.
Modelo embutido (ou restrito). Um projeto que deve ser desenvolvido den-
tro de um conjunto rgido de restric
oes operacionais, de hardware e de
software.
O COCOMO II, assim como o seu predecessor e na verdade uma hierarquia
de modelos que trata das seguintes
areas:
Modelo de composi
c
ao de aplica
c
ao. Usado durante os primeiros est
agios
do processo.
Modelo do primeiro est agio de projeto. Usado ap os os requisitos terem
sido estabilizados e a arquitetura b

asica do software ter sido estabelecida.
Modelo para o est

agio ap
os a arquitetura. Usado durante a construc
ao do
software.
O COCOMO II usa pontos por objeto. Como pontos por func ao, o pontos por
objeto e uma medida indireta de software que e calculada usando-se a contagem
da quantidade de telas (na interface com o usu ario, relat
orios e componentes.
Cada inst ancia de objeto em um dos tres nveis de complexidade (simples, medio,
difcil). Essencialmente, a complexidade e func ao da quantidade e fonte das
tabelas de dados do cliente e servidores, que s ao necess arias para gerar a tela ou
125
relat
orio, e da quantidade de vistas ou sec
oes apresentadas como parte da tela
ou relat
orio.
Deve-se notar que outros modelos de estimativa mais sofisticados (usando
FP e KLOC) tambem est ao disponveis como parte do COCOMO II.
126
Captulo 11
Testes
Teste e um processo de execuc ao de um programa com a finalidade de encontrar

um erro. Os teses podem ser planejados e projetados antes que qualquer c odigo
tenha sido gerado. Os primeiros testes planejados e executados geralmente
concentram-se nos componentes individuais. A ` medida que o teste progride, o
foco se desloca numa tentativa de encontrar erros em conjuntos integrados de
componente e finalmente em todo o sistema.
A testabilidade de software e a facilidade com que o programa pode ser
testado. Existem metricas que podem medir a testabilidade do software.
Quando o software para computador e considerado, teste caixa-preta refere-
se a testes que sao conduzidos na interface do software.
Um teste de caixa-branca e baseado num exame rigoroso do detalhe pro-
cedimental. Caminhos l ogicos internos do software s
ao testados, definindo ca-
sos de testes que exercitam conjuntos especficos de condicoes ou ciclos. Teste
caixa-branca completo e impossvel para grandes sistemas de software. Um
teste caixa-branca n ao deve, no entanto, ser descartado como n ao pr
atico. Um
n
umero limitado de caminhos l ogicos importantes pode ser selecionado e exerci-
tado. H a tres motivos importantes pelos quais se deve usar testes caixa-branca:
Os erros tendem a ocorrer em condic
oes ou controle que est
ao fora da
func
ao principal.
Freq
uentemente acreditamos que um caminho l ogico n
ao e prov
acel de ser
executado quando, na realidade, ele pode ser executado em base regular.
prov
E avel que um erro tipogr
afico exista tanto num caminho l
ogico ob-
scuro quanto num caminho principal.
11.1 Teste de caminho b

asico
Teste de caminho basico e uma tecnica de teste caixa-branca proposta inicial-
mente por Tom McCabe. O metodo de caminho b asico permite ao projetista
de casos de teste originar uma medida da complexidade l ogica de um projeto
procedimental e usar essa medida como guia para definir um conjunto b asico
de caminhos de execucao. Casos de testes derivados para exercitar o conjunto
b
asico executam garantidamente cada comando programa pelo menos uma vez
durante o teste.
127
O grafo de fluxo mostra mostra o fluxo de controle l ogico. Cada n o do

grafo de fluxo representa um ou mais comando procedimentais. As arestas
representam o fluxo de controle. As areas dlimitadas por arestras e n os s
ao
chamadas regi oes. Cada no que contem uma condic ao e chamado de n
o predicado
e e caracterizada por duas ou mais arestas saindo dele.
Complexidade ciclom atica e a metrica de software que fornce uma medida
quantitativa da complexidade l ogica do programa. O valor calculado para a
complexidade ciclom atica define o numero de caminhos independentes no con-
junto base de um programa e nos fornece um limite superior para a quantidade
de testes que deve ser conduzida para garantir que todos os comandos tenho
sido executados pelo menos uma vez.
Um caminho independente e qualquer caminho ao longo do programa que
introduz pelo menos um novo conjunto de comandos de processamento ou uma
nova condic ao. Um conjunto-base e um conjunto de caminhos em que todo
comando do programa ter a sido garantidamente executado pelo menos uma vez
e cada condicao ter
a sido executada no seu lado verdadeiro e no seu lado falso.
A complexidade ciclom atica e calculada de tres maneiras:
1. O n
umero de regi
oes do grafo de fluxo.
2. V (G) = E N + 2 em que E e o n
umero de arestas e N o n
umero de n
os.
3. V (G) = P + 1 em que P e o n
umero de n
os predicados.
Os seguintes passos podem ser aplicados para derivac
ao de casos de teste:
1. Usando o projeto ou c
odigo como base, desenhe o grafo de fluxo corre-
spondente.
2. Determine a complexidade ciclom
atica do grafo de fluxo resultante.
3. Determine um conjunto-base de caminhos linearmente independentes.
4. Prepare casos de teste que v
ao forcar a execuc
ao de cada caminho do
conjunto-base.
Uma matriz de grafo e uma matriz quadrada, cujo n umero de colunas e
linhas e igual ao numero de nos do grafo de fluxo. Adicionando um peso de
ligac
ao a cada entrada da matriz, a matriz de grafo pode tornar-se uma possante
ferramenta para avaliar a estrutura de controle do programa durante o teste.
Em sua forma mais simples, o peso da ligac ao e 1 (existe uma conexao) ou
0 (n ao existe uma conexao). Outros pesos podem ser atribudos com outras
propriedades:
A probabilidade de que uma ligac
ao (aresta) ser
a executada.
O tempo de processamento gasto durante o percurso de uma ligac
ao.
A mem
oria necess
aria durante o percurso de uma ligac
ao.
Os recursos necess
arios durante o percurso de uma ligac
ao.
Existem algoritmos que podem ser aplicados ` as matrizes de grafo. Usando
essaas tecnicas, a an
alise necess
aria para projetar casos de teste pode ser parcial
ou totalmente automatizada.
128
11.2 Teste de estrutura de controle

A tecnica de teste de estrutura de controle ampliam a cobertura da tecnica de
teste de caminho b asico e melhoram a qualidade do teste caixa-branca.
11.2.1 Teste de condic

ao
Teste de condic ao e um metodo de projeto de caso de teste que exercita as
condic
oes l
ogicas contidas em um m odulo de programa. Uma condic ao simples
e uma vari avel booleana ou uma express ao relacional, possivelmente precedida
por um operador de negac ao. Uma condic
ao composta e composta de duas ou
mais condicoes simples, operadores booleanos e parenteses.
Diversas estrategias para teste de condic
ao tem sido propostas. O teste de
desvio e provavelmente a estrategia de teste de condicao mais simples. Para
uma condic ao composta C, os ramos verdadeiro e falso de C e cada condic ao
simples de C precisam ser executadas pelo menos uma vez.
O teste de domnio requer que tres ou quatro testes sejam derivados para
uma express ao relacional. Para uma expressao relacional da forma
E1 < operador relacional > E2
tres testes s
ao necessarios para tornar o valor de E1 maior que, igual a, ou menor
que o de E2 .
Para uma express ao booleana com n vari aveis, todos os 2n possveis testes
s
ao necess arios (n > 0), mas e pr atica somente quando n e pequeno.
Caso uma express ao booleana seja singular (na qual cada vari avel ocorre
apenas uma vez), h a como gerar um conjunto de testes com menos do que 2n
testes tal que esse conjunto de testes garante a detecc ao de erros de operadores
booleanos m ultiplos e e tambem efetivo para detectar outros erros. Uma delas e
a tecnica de teste de desvio e operador relacional (branch and relational operator,
BRO). Ela usa restric oes de condic
ao para uma condic ao C. Uma restric ao de
condicao para C com n condic oes simples e definida como (D1 , D2 , . . . , Dn ),
em que Di (0 < i n) e um smbolo que especifica uma restric ao sobre o
resultado da i-esima condic ao simples da condic
ao C. Diz-se que uma restric ao
de condic ao D para uma condic ao C e coberta por uma execuc ao de C se,
durante a execuc ao de C, o resultado de cada condic ao simples de C satisfaz a
correspondente restric ao em D. N ao entendeu nada? Como exemplo, considere
a condicao:
C1 : B1 &B2
em que B1 e B2 s ao vari aveis booleanas. A restric ao de condicao para C1 e

da forma (D1 , D2 ), em que cada um de D1 e D2 e t ou f . O valor (t, f ) e
uma restric ao de condic ao para C1 . A estrategia de teste BRO exige que o
conjunto de restric oes {(t, t), (t, f ), (f, t)} seja coberto pelas execucoes de C1 .
Se C1 est a incorreto, pelo menos uma das condic oes do conjunto vai fazer C1
falhar. Outro exemplo: C2 : B1 &(E3 = E4 ) possui o conjunto de restric oes
{(t, =), (f, =), (t, <), (t, >)}, sendo E3 e E4 express oes aritmeticas.
129
11.2.2 Teste de fluxo de dados

O met odo de teste de fluxo de dados seleciona caminhos de teste de um pro-
grama de acordo com a localizac ao das definic
oes e do uso das vari aveis no
programa. Para ilustrar a abordagem de teste de fluxo de dados, considere que
cada comando de um programa e atribudo um n umero de comando u nico e
que cada func ao n
ao modifica seus par ametros ou vari aveis globais. Para um
comando com S como seu n umero de comando,
DEF (S) = {X/comando S contem uma definic ao de X}
U SO(S) = {X/comando S contem um uso de X}
Se o comando S e um comando se ou de ciclo, seu conjunto DEF e vazio e
seu conjunto USO e baseado na condic ao do comando S. A definic ao da vari avel
X no comando S e considerada como estando viva no comando S se existe um
caminho do comando S para o comando S que n ao contem qualquer outra
definic
ao de X.
Uma cadeia definic ao-uso (DU) da variavel X e da forma [X, S, S ] em que S

e S sao n umeros de comandos, X pertence a DEF (S) e U SO(S ), e a definic ao
de X no comando S est a viva no comando S .
A estrategia de teste DU exige que cada cadeia DU seja coberta pelo menos
uma vez. Foi mostrado que o teste DU n ao cobre todos os ramos em situac oes
raras. A abordagem de teste de fluxo de dados e efetiva para detecc ao de erros.
No entanto, os problemas de medida da cobertura e de selec ao dos caminhos
de teste s ao mais difceis do que os problemas correspondentes para o teste de
condicao.
11.2.3 Teste de ciclo

Teste de ciclo e uma tecnica de teste caixa-branca que focaliza exclusivamente
a validade de construcoes de ciclo. Quatro diferentes classes de ciclos podem
ser definidas:
Ciclos simples. O seguinte conjunto de teste pode ser aplicado a ciclos simples
em que n e o n
umero maximo de passagens permitidas no ciclo.
1. Pule o ciclo completamente.
2. Apenas uma passagem pelo ciclo.
3. Duas passagens pelo ciclo.
4. m passagens pelo ciclo em que m < n.
5. n 1, n, n + 1 passagens pelo ciclo.
Ciclos aninhados. Seria muito complicado adotar as mesmas tecnicas de cic-

los simples neste caso. Uma abordagem e sugerida:
1. Comece no ciclo mais interno. Ajuste todos os outros cilos para o
valores mnimos.
2. Conduze testes de ciclo simples para o ciclo mais interno enquanto
mantem os ciclos externo nos seus valores mnimos de iterac
ao.
3. Trabalhe em direcao ao extereior, conduzindo testes para o ciclo
seguinte.
4. Continue ate que todos os ciclos tenham sido testados.
130
Ciclos concatenados. A mesma abordagem para o ciclo simples a menos que

o mesmo contador e utilizado nos ciclos concatenados. Neste caso, e re-
comendada a abordagem a ciclos aninhados.
Ciclos desestruturados. Sempre que possvel essa classe de ciclos deve ser
reprojetada.
11.3 Teste caixa-preta

Um teste caixa-preta, tambem chamado de teste comportamental, focaliza os req-
uisitos funcionais do software. O teste caixa-preta tende a ser aplicado durante
os u
ltimos est
agios do teste.
11.3.1 M
etodos de teste baseados em grafo
Os objetos que est ao modelados no software e as relacoes que conectam esses
objetos sao utilizadas para criar um grafo. Os n os representam os objetos, as
arestas representam as ligac
oes, os pesos de n
o descrevem as propriedade de um
objeto, assim como os pesos das arestas representam propriedades das ligac oes.
Uma ligac ao direcionada (representada por uma seta) indica que a relacao se
move em apenas uma direc ao. Ligacoes paralelas s
ao usadas quando diversas
relac
oes s
ao estabelecidas entre os n
os.
Os metodos de teste de comportamento que podem fazer usos de grafos s ao:
Modelagem de fluxo de transa c
ao. Os n
os representam passos em alguma
transac
ao e as arestam representam conexoes l
ogicas.
Modelagem de estado finito. Os n os representam diferentes estados do soft-
ware observ
aveis pelo usu
ario e as aresta representam as transic
oes.
Modelagem do fluxo de dados. Os n os s
ao objetos de daods e as ligac
oes
s
ao transformac
oes que ocorrem para traduzir um objeto de dados em
outro.
11.3.2 Particionamento de equival

encia
O particionamento de equivalencia e um metodo de teste caixa-preta que divide
o domnio de entrada de um programa em classes de dados, das quais casos
de teste podem ser derivados. Uma classe de equivalencia representa um con-
junto de estados validos ou invalidos para condic
oes de entrada. Classes de
equivalencia podem ser definidas de acordo com as seguintes diretrizes:

1. Se uma condic
ao de entrada especifica um intervalo, uma classe de equivalencia
v
alida e duas inv
alidas s
ao definidas.
2. Se uma condic ao de entrada exige um valor especfico, uma classe de
equivalencia v
alida e duas inv
alidas s
ao definidas.
3. Se uma condicao de entrada especifica um membro de um conjunto, uma
classe de quivalencia v
alida e uma inv
alida s
ao definidas.
4. Se uma condic
ao de entrada e booleana, uma classe de equivalencia v
alida
e uma inv
alida s
ao definidas.
131
Um elemento pode ter mais de uma condic ao de entrada. Por exemplo,

considere uma entrada de senha , h a condic
ao de entrada booleana (pode estar
ou n
ao presente) e condic
ao de entrada de valor (cadeia de seis caracteres).
11.3.3 An
alise de valor limite
Um grande n umero de erros tende a ocorrer nas fronteiras do domnio de en-
trada. E por essa raz ao que a analise de valor-limite (boundary value analysis,
BVA) foi desenvolvida como tecnica de teste.
A BVA leva ` a selec
ao de casos de teste nas bordas da classe. Em vez de
focalizar somente as condic oes de entrada, a BVA deriva casos de teste tambem
para o domnio de sada.
Se uma condic ao de entrada especifica um intervalo ou um valor limitado
pelos valores a e b, casos de teste devem ser projetados com os valores a e b e
imediatamente acima e imediatamente abaixo de a e b. O mesmo vale para as
condic
oes de sada. Se as estruturas de dados tem limites prescritos, certifique-se
de projetar um caso de teste para exercitar a estrutura de dados no seu limite.
11.3.4 Teste de comparac

ao
Quando um software redundante e desenvolvido (para aplicac oes crticas), equipes
de engenheiros de software separadas desenvolvem vers oes independentes de uma
aplicac
ao usando a mesma especificac ao. Em tais situac oes, cada vers ao pode
ser testada com os mesmos dados de teste para garantir que todas fornecem
sada identica. Depois, todas as vers oes s
ao executadas em paralelo com com-
parac
ao em tempo real para garantir consistencia. Essas vers oes independentes
formam a base da tecnica de teste caixa-preta chamada teste de comparac ao ou
teste de emparelhamento.
Quando m ultiplas implementac oes da mesma especificac ao tivem sido pro-
duzidas, casos de teste projetadados usando outras tecnicas de caixa-preta
fornecem entradas a cada vers ao do software. Se a sada de cada vers ao e a
mesma, e considerado que todas as implementac oes estao corretas. Se a sada e
diferente, cada uma das aplicac oes e investigada para determinar se um defeito
em uma ou mais vers oes e responsavel pela diferenca.
O teste de comparac ao nao e a toda prova, se a especificac ao estiver errada,
todas as vers oes ir
ao provavelmente refletir o erro. Alem disso, se cada uma das
versoes independentes produzir resultados identicos mas incorretos, o teste de
comparac ao vai falhar na detecc ao do erro.
11.3.5 Teste de matriz ortogonal

Teste de matriz ortogonal pode ser aplicado a problemas nos quais o domnio
de entrada e relativamente pequeno, mas grande demais para acomodar teste
exaustivo. Quando o teste de matriz ortogonal ocorre, e criada uma matriz
ortogonal L9 de casos de teste. A matriz ortogonal L9 tem uma propriedade
de balanceamento (est ao distribudos uniformemente pelo domnio de teste).
A abordagem de teste de matriz ortogonal nos possibilita obter boa cobertura
de teste com muito menos casos de teste que a estrategia exaustiva. Outras
definic
oes s
ao importantes:
132
Se todos os casos de teste com um determinado argumento igual a 1, por

exemplo, falharem, trata-se de uma falha de modo singular.
Se existe um problema consistente quando nveis especficos de dois par

ametros
ocorrem simultaneamente, ele e chamado de falha de modo duplo. E a in-
terac
ao danosa entre dois par
ametros de teste.
Matrizes ortogonais so podem garantir a detecc

ao de falhas de modo sin-
gular e duplo. No entanto, muitas falhas de multimodo s ao tembem de-
tectadas por esses testes.
11.4 Teste de ambientes, arquiteturas e aplica

coes
especializadas
Podemos citar as tecnicas especializadas de testes:
Teste de GUI. Como muitas GUI modernas tem a mesma aparencia e fun-
cionamento, uma serie de testes padr
ao pode ser derivada. Devido ao
grande n
umero de operac
oes GUI, o teste deve ser conduzido usando fer-
ramentas automatizadas.
Teste de arquiteturas cliente/servidor. A natureza distribuda dificulta muito,

os teste s
ao consideravelmente mais difcil que em aplicac
oes isoladas.
Teste da documenta c
ao e dispositivos de ajuda. Pode ser abordado em
duas fases. A primeira fase, revisao e inspenc ao, examina o documento
quanto `
a clare editorial. A segunda fase, teste ao vivo, usa a documentacao
em conjunto com o uso do programa real. Nesta fase, os v arios metodos
de caixa-preta podem ser utilizados.
Teste de sistemas de tempo real. O projetista de casos de teste n ao tem

apenas que considerar casos de teste caixa-branca e caixa-preta, mas
tambem manipulacao de eventos (processamento de interrupcoes), a tem-
pestividade dos dados e o paralelismo das tarefas que manipulam os dados.
Uma estrategia global de quatro passoas pode ser proposta:
Teste de tarefa. Testes de caixa-branca e de caixa-preta s

ao projetados
e executados para cada tarefa.
Teste comportamental. E simulado o comportamento de um sistema
de tempo real e examinado seu comportamento como conseq uencia
de eventos externos.
Testes intertarefas. Tarefas assncornas que se comunicam sao testadas
com diferentes taxas de dados e carga de processamento para detectar
se erros de sincronizac
ao entre tarefas v
ao ocorrer.
Teste de sistema. O software e o hardware s ao integrados e todo um
conjunto de testes de sistema e conduzido numa tentativa de descobrir
erros na interface software-hardware.
133
11.5 Estrat
egia de teste de software
O projeto efetivo de caso de testes e importante, mas n ao suficiente para o
sucesso da atividade de testes. A estrategia, isto e, a serie planejada de re-
alizac
ao de testes, e tambem crucial. Basicamente, h a tres grandes fases de
teste:
Teste de unidade. Tem por objetivo testar a menor unidade do projeto (um
componente de software que n ao pode ser subdividido), procurando iden-
tificar erros de l
ogica e de implementac
ao em cada modulo separamente.
Teste de integra c
ao. Visa descobrir erros associados `
as interfaces entre os
modulos quando esses s
ao integrados para formar a estrutura do produto
de software.
Teste de sistema. Tem por objetivo identificar erros de func oes (requisitos
funcionais) e caractersticas de desempenho (requisito n
ao funcional) que
n
ao estejam de acordo com as especificacoes.
Tipicamente, os primeiros testes focalizam componentes individuais e apli-
cam testes caixa-branca e caixa-preta. Na integrac ao, o foco e o projeto e a ar-
quitetura do sistema. Finalmente, uma serie de testes de alto nvel e executada
quando o sistema estiver operacional, visando descobrir erros nos requisitos.
No teste de unidade, faz-se necess ario construir pequenos componentes para
permitir testar modulos invidualmente, os ditos drivers e stubs. Um driver e um
programa respons avel pela ativac
ao e coordenac
ao do teste de uma unidade. Ele
e responsavel por receber dados de teste fornecidos pelo testador, passar esses
dados para a unidade que est a sendo testada, obter os resultados produzidos e
apresenta-los ao testador. Um stub e uma unidade que substitui, na hora do
teste, uma outra unidade chamada pela unidade que est a sendo testada. Em
geral, um stub simula o comportamento de uma unidade chamada com o mnimo
de computac ao ou manipulac ao de dados.
A abordagem de integracao de m odulos pode ter impacto na quantidade de
drivers e stubs a ser construda. Sejam as seguintes abordagens:
Integrac
ao ascendente (bottom-up). Cada m odulo no nvel inferior da hi-
erarquia e testado individualmente. A seguir, s
ao testados m odulos que
chamam os previamentes testados. Neste caso, apenas drivers sao necess
arios.
Integrac
ao descendente (top-down). Comeca de cima para baixo. Apenas
stubs s
ao necess
arios.
Sanduche. Considera uma camada alvo no meio da hierarquia e utiliza abor-

dagens ascendente e descendente.
Big-bang. Testar individualemte cada modulo e depois integr
a-los de uma s
o
vez. Neste caso, tanto drivers quanto stubs s
ao necessarios para cada
modulo. Trabalhoso e suicida.
Os testes de sistema incluem diversos tipos de testes, realizados na seguinte
ordem:
Teste funcional. Verifica se o sistema integrado realiza as func
oes especifi-
cadas nos requisitos.
134
Teste de desempenho. Verifica se o sistema integrado atende os requisitos

n
ao funcionais do sistema (eficiencia, seguranca e confiabilidade).
Teste de aceita c
ao. Realizado pelos clientes. Assegura que o sistema solici-
tado e o que foi construdo.
Teste de instalac
ao. Necess ario quando os testes de aceitac
ao n
ao s
ao feitos
onde o software ser
a realmente instalado.
135
Captulo 12
UML
12.1 Diagrama de caso de uso

Diagramas de caso de uso descrevem relacionamentos e dependencias entre um
grupo de caso de uso e os atores participantes no processo. Um Caso de uso
descreve do ponto de vista dos atores um grupo de atividades num sistema
que produz um resultado concreto e tangvel. Casos de uso s ao descric
oes de
interac
oes tpicas entre os usu
arios de um sistema e o sistema propriamente dito.
Eles representam a interface externa do sistema e especificam um conjunto de
exigencias do que o sistema deve fazer.
Quando trabalhar com Casos de Uso, e importante lembrar-se de algumas
regras simples:
Cada Caso de Uso est
a relacionado com no mnimo um ator
Cada Caso de Uso possui um iniciador (isto e um ator)
Cada Caso de Uso liga-se a um resultado relevante (um resultado com
valor de neg
ocio)
Casos de uso tambem podem ter relacionamentos com outros casos de uso.
Os tres tipos mais comuns de relacionamento entre casos de uso s
ao:
inclui-se que especifica que um Caso de Uso toma lugar dentro de outro Caso
de Uso
estende que especifica que em determinadas situac
oes, ou em algum ponto
(chamado um ponto de extens

ao) um caso de uso ser
a estendido por outro.
Generaliza
cao especifica que um caso de uso herda as caractersticas do super
caso de uso, e pode sobrepor algumas delas ou adicionar novas de maneira
semelhante a heranca entre classes.
12.1.1 Ator
Um ator e uma entidade externa (fora do sistema) que interage com o sistema
participando (e freq
uentemente iniciando) um caso de uso. Atores podem ser
pessoas reais (por exemplo usu
arios do sistema), outro sistema de computador
ou eventos externos.
136
Atores nao representam as pessoa fsica ou sistemas, mas sua regra. Isto
significa que quando uma pessoa interage com o sistema de diferentes maneiras
(assumindo diferentes regras) ela ser
a representada por diversos atores. Por ex-
emplo, uma pessoa que fornece suporte ao cliente por telefone e recebe ordens do
cliente para o sistema pode ser representado por um ator da equipe de suporte.
12.1.2 Descri
cao do caso de uso
Descric
ao do caso de uso s
ao narrativas de texto do caso de uso. Elas usualmente
tomam a forma de uma nota ou um documento que e de alguma maneira ligado
ao caso de uso, e explana o processo ou atividades que tomar ao lugar no caso
de uso.
Figura 12.1: Exemplo de um diagrama de caso de uso
12.2 Diagrama de classe

Diagramas de classe mostram as diferentes classes que fazem um sistema e como

elas se relacionam. Os diagramas de classe s ao chamados diagramas est aticos
porque mostram as classes, com seus metodos e atributos bem como os rela-
cionamentos est aticos entre elas: quais classes conhecem quais classes ou quais
classes s
ao parte de outras classes, mas nao mostram a troca de mensagens entre
elas.
Na UML, atributos s ao mostrados com pelo menos seu nome, e podem
tambem mostrar seu tipo, valor inicial e outras propriedades. Atributos po-
dem tambem ser exibidos com sua visibilidade:
137
Figura 12.2: Exemplo de um diagrama de classe
+ indica atributos p
ublicos.
# indica atributos protegidos.
indica atributos privados
As operac oes tambem sao exibidas com pelo menos seu nome, e podem
tambem mostrar seus par ametros e valores de retorno.
Classes podem ter modelos, um valor que e usado para uma classe ou tipo n ao
especificado. O tipo de modelo e especificado quando uma classe e iniciada (isto
e um objeto e criado). Modelos existem no C + + moderno e foram introduzidos
no Java 1.5 onde eles sao chamados de genericos.
12.2.1 Associa
coes de classe
Classes podem relacionar-se (ser associada com) com outras de diferentes maneiras:
Generaliza
cao
EM UML, uma generalizac ao entre duas classes coloca-as numa hierarquia rep-
resentando o conceito de heranca de uma classe derivada de uma classe base.
Em UML, Generalizac oes sao representadas por uma linha conectando duas
classes, com uma seta no lado da classe base.
Associa
coes
S
ao o mecanismo que permite objetos comunicarem-se entre si. Elas descrevem
a conex
ao entre diferentes classes (a conex
ao entre os objetos atuais e chamada
138
Figura 12.3: Exemplo de generalizac

ao
conex ao do objeto, ou link. Associacoes podem ter um regra que especifica o

prop osito da associac
ao e pode ser uni ou bidirecional (indicadando se os dois
objetos participantes do relacionamento podem mandar mensagens para o outro,
ou se apenas um deles sabe sobre o outro). Cada ponta da associac ao tambem
possui uma valor de multiplicidade, que dita como muitos objetos neste lado da
associacao pode relacionar-se com o outro lado.
Em UML, associac oes s
ao representadas como linhas conectando as classes
participantes do relacionamento, e podem tambem mostrar a regra e a mul-
tiplicidade de cada um dos participantes. A multiplicidade e exibida como
um intervalo [min . . . max] de valores nao negativos, com um asterisco no lado
maximo representando infinito.
Figura 12.4: Exemplo de associac

ao
Agrega
cao
Agregac
oes s
ao um tipo especial de associac
ao no qual as duas classes partici-
pantes nao possuem em nvel igual, mas fazem um relacionamento todo-parte.
Uma agregac ao descreve como a classe que possui a regra do todo, e composta
(tem) de outras classes, que possuem a regra das partes. Para agregac oes, a
classe que age como o todo sempre tem uma multiplicidade de um.
Em UML, agregac oes s
ao representadas por uma associac ao que mostra
um romb oide no lado do todo. Representac ao visual de um relacionamento
Agregac
ao em UML.
Figura 12.5: Exemplo de agregac

ao
Composi
cao
Composic oes s
ao associac
oes que representam agregacoes muito fortes. Isto
significa que composic
oes formam relacionamentos todo-parte tambem, mas o
relacionamento e t
ao forte que as partes n
ao pode existir independentes.
Em UML, composic oes s
ao representadas por um romb oide s
olido no lado
do todo.
139
Figura 12.6: Exemplo de composic

ao
12.3 Diagramas de seq

uencia
Diagramas de seq uencia mostram a troca de mensagens entre diversos objetos,
numa situacao especfica e delimitada no tempo. Diagramas de seq uencia colo-
cam enfase especial na ordem e nos momentos nos quais mensagens para os
objetos sao enviadas.
Em diagramas de seq uencia, objetos s
ao representados atraves de linhas
verticais tracejadas, com o nome do objeto no topo. O eixo do tempo e tambem
vertical, aumentando para baixo, de modo que as mensagens s ao enviadas de um
objeto para outro na forma de setas com a operac ao e os nomes dos parametros.
Figura 12.7: Exemplo de diagrama de seq

uencia
Mensagens podem ser sncronas, o tipo normal de mensagem de chamada

em que o controle e passado para o objeto chamado ate o metodo ter terminado
sua execuc
ao, ou assncronas, em que o controle e passado diretamente para o
objeto chamado. Mensagens sncronas possuem uma caixa vertical no lado do
objeto chamado para mostrar o controle do fluxo do programa.
12.4 Diagramas de colabora

cao
Diagramas de colaborac
ao mostram as interac oes que ocorrem entre os objetos
participantes numa situac
ao especfica. A informac
ao e parecida com a mostrada
140
pelos diagramas de seq uencia, mas neste, a enfase e colocada em como as in-
terac
oes ocorrem no tempo, enquanto os diagramas de colaborac ao colocam os
relacionamentos entre os objetos e sua topologia em destaque.
Em diagramas de colaborac ao, as mensagens enviadas de um objeto para
outro sao representadas por setas, mostrando o nome da mensagem, par ametros,
e a sequencia da mensagem. Diagramas de colaborac ao sao especialmente in-
dicados para mostrar um fluxo ou situac ao especfica do programa e podem,
rapidamente, demonstrar ou explanar um processo na l ogica do programa.
Figura 12.8: Exemplo de diagrama de colaborac

ao
12.5 Diagramas de estado

Diagramas de Estado mostram os diferentes estados de um objeto durante sua
vida, e o estmulo que faz com que o objeto mude seu estado. Diagramas de
estado veem objetos como m aquinas de estado.
Estados sao os blocos construdos dos Diagramas de estado. Um estado per-
tence a exatamente uma classe e representa um resumo dos valores dos atributos
que uma classe pode tomar. Um estado UML descreve o estado interno de um
objeto para uma classe em particular
Observe que nem toda mudanca em um dos atributos de um objeto pode ser
representada por um estado, mas somente aquelas mudancas que podem afetar
significativamente o trabalho do objeto.
Existem dois tipos especiais de estados: inicial e final. Eles s
ao especiais
porque nenhum evento pode fazer com que um objeto retorne para seu estado
inicial, e da mesma maneira nenhum evento pode tirar um objeto de seu estado
final, uma vez que ele j
a o tenha alcancado.
141
Figura 12.9: Exemplo de diagrama de estado

142
12.6 Diagramas de atividade

Uma atividade e um passo simples num processo. Uma atividade e um estado no
sistema com atividade interna e, pelo menos, uma transic ao de sada. Atividades
podem tambem ter mais de uma transic ao de sada se elas possuem condic oes
diferentes.
O diagrama de atividade descreve a seq uencia de atividades num sistema
com a ajuda das atividades. Diagramas de atividade s ao uma forma especial de
diagramas de estado, que somente (ou principalmente) contem atividades.
Diagramas de atividade sao similares aos diagramas de fluxo de procedi-
mentos, com a diferenca de que todas as atividades s ao claramente anexas aos
objetos.
Diagramas de atividade s ao sempre associados a uma classe, uma operac ao
ou um caso de uso.
Diagramas de atividade suportam atividades seq uenciais bem como parale-
las. A execucao paralela e representada pelos cones Forquilha/Esperar, e para
as atividades executadas em paralelo, n ao e importante a ordem na qual elas se
executam (elas podem ser executadas ao mesmo tempo ou uma ap os a outra).
Atividades podem formar hierarquias, isto significa que uma atividade pode
ser composta por diversas atividades em detalhe, na qual as transic oes de en-
trada e sada devem corresponder ` as transic
oes de entrada e sada do diagrama
de detalhe.
Figura 12.10: Exemplo de diagrama de atividade
143
12.7 Elementos auxiliares

Existem dois elementos em UML que nao possuem nenhum valor real semantico
para o modelo, mas auxiliam a elucidar partes do diagrama. Estes elementos
s
ao:
Linhas de texto. S
ao u
teis para adicionar informac
oes curtas de texto ao di-
agrama. S
ao textos livres.
Notas. S
ao u teis para adicionar informac
oes mais detalhadas sobre um objeto
ou situacao especfica. Elas possuem a grande vantagem de poderem ser
ancoradas a elementos UML para mostrar que a nota pertence a um objeto
especfico ou situacao.
Caixas. S
ao ret
angulos de forma livre que podem ser usados para agrupar itens,
tornando os diagramas mais legveis.
12.8 Diagramas de componente

Diagramas de componente mostram os componentes do software (sejam com-
ponentes de tecnologias como KParts, componentes CORBA ou Java Beans ou
apenas secoes do sistema que sao claramente distintas) e os artefatos de que eles
s
ao feitos como arquivos de c odigo fonte, bibliotecas de programacao ou tabelas
de bancos de dados relacionais.
Componentes podem possui interfaces (isto e classes abstratas com operac oes)
que permitem associac oes entre componentes.
12.9 Diagramas de distribui

cao
Diagramas de distribuicao mostram as inst ancias dos componentes de tempo
de execuc
ao e suas associac
oes. Eles incluem n
os que s
ao recursos fsicos, tipi-
camente um computador simples. Eles tambem mostram interfaces e objetos
(inst
ancias da classe).
144
Captulo 13
Ger
encia de Configura
cao e
Mudancas
A gestao da configurac
ao do software e uma atividade guarda-chuva e e aplicada
ao longo de todo o processo de software. O gerenciamento de configurac ao e de
solicitac
oes de mudanca envolve os seguintes itens:
Identificac
ao dos itens de configurac
ao;
Restric
ao das mudancas nesses itens;
Auditoria das mudancas nesses itens;
Definic
ao e o gerenciamento das configurac
oes desses itens.
Os metodos e ferramentas utilizadas para o controle das mudancas e consid-

erado com o Sistema de Gerenciamento de Mudancas de uma organizac ao. Ele
e contem informacoes chaves sobre os processos de desenvolvimento, promoc ao,
implantac
ao e manutencao de produtos da organizac ao e armazenam a base de
ativos e de artefatos potencialmente reutiliz
aveis resultantes da execuc
ao desses
processos. Sendo assim, ele e parte integrante dos processos gerais de desen-
volvimento.
Sem o controle dos in umeros artefatos produzidos pelas muitas pessoas que
trabalham em um projeto, s ao criados artefatos conflitantes, gerando um grande
desperdcio para a organizacao. Os principais problemas s ao a atualizac
ao si-
mult
anea, a notificac
ao limitada e a existencia de v
arias vers
oes. A seguir, cada
uma delas e descrita em detalhes.
Atualizac
ao simultanea:
Quando dois ou mais membros da equipe trabalham separadamente no
mesmo artefato, o ultimo membro a fazer mudancas desfaz o trabalho re-
alizado pelo anterior. O problema b asico e que se um sistema n
ao permite a
atualizac
ao simult
anea, isso leva as mudancas em serie e diminui o ritmo do
processo de desenvolvimento. Entretanto, com a atualizac ao simultanea,
o desafio e detectar se ocorreram atualizac oes simultaneamente e resolver
145
quaisquer problemas de integrac

ao quando essas mudancas forem incor-
poradas.
Notificac
ao limitada:
Quando um problema e corrigido nos artefatos compartilhados por v
arios
desenvolvedores e alguns deles n
ao s
ao notificados da mudanca.
Varias vers
oes:
A maioria dos programas de grande porte e desenvolvida em v arias vers
oes
evolutivas. Uma vers ao pode estar sendo usada pelo cliente, enquanto
outra esta em teste e uma terceira ainda est a em desenvolvimento. Se
forem encontrados problema em qualquer uma das vers oes, as correc
oes
devem ser propagadas entre elas. Isso pode levar a confus oes que levam
a confusoes dispendiosas. Um sistema de Gerencia de Configurac ao e u
til
para gerenciar as diversas variantes de sistemas de software em desenvolvi-
mento pois controla as versoes que sao utilizadas em determinadas builds
do software ao compilar builds de programas individuais ou de uma nova
vers
ao do software de acordo com a especificacao definida pelo usuario e ao
impor polticas de desenvolvimento do sistema. Os principais benefcios
do gerenciamento da mudanca s ao:
Suporte a diversos metodos de desenvolvimento;
Preservac
ao da integridade do produto;
Garantia da abrangencia e precis
ao do produto configurado;
Ambiente est
avel no qual o produto ser
a desenvolvido;
Restric
ao das mudancas feitas nos artefatos com base nas polticas
do projeto;
Trilha de auditoria indicando por que, quando e por quem um artefato
foi alterado.
Alem disso, ele armazena dados detalhados sobre as alterac
oes, tais como,
quem criou uma vers ao especifica, quais vers
oes dos c
odigo fonte foram
utilizadas em determinado build, alem de outras informac oes relevantes.
13.1 As Atividades
Na disciplina de Gerencia de Configurac

ao as principais atividades s
ao:
Configurar ambiente;
Estabelecer polticas;
Escrever plano;
Criar unidade de implantac
ao;
Relatar status de configurac
ao;
Realizar auditorias de configurac
ao;
146
Estabelecer processo de controle de mudancas;

Revisar solicitac
ao de mudanca;
Confirmar, duplicar ou recusar requisic

ao de mudanca;
Crias espacos de trabalho de integrac
ao;
Criar baselines;
Promover baselines ( de desenvolvimento para testes, de testes para ho-

mologac
ao, etc.);
Criar espaco de trabalho de desenvolvimento;
Fazer mudancas;
Liderar mudancas;
Atualizar espaco de trabalho;
Enviar solicitac
ao de mudanca;
Atualizar solicitac
ao de mudanca.
13.2 Artefatos
ao os principais artefatos s
ao:
Reposit
orio do projeto;
Plano de gerenciamento da configurac

ao;
Unidade de implantac
ao;
Metricas do projeto;
Registro da auditoria de configurac
ao.
13.3 Pap
eis e Responsabilidades
ao os principais papeis e responsabili-
dades s
ao:
Gerente de configurac
ao
Configurar ambiente;
Estabelecer polticas;
Escrever plano;
Criar unidades de implantac
ao;
Relatar status de configurac
ao;
Realizar auditoria de configurac
ao.
147
Gerente de controle de mudanca

Estabelecer processo de controle de mudancas;
Revisar solicitac
ao de mudanca;
Confirmar, duplicar ou recusar solicitac
ao de mudanca.
Integrador
Criar espacos de trabalho de integrac
ao;
Criar baselines;
Promover baselines.
Outros papeis
Criar espaco de trabalho de desenvolvimento;

Fazer mudancas;
Liderar mudancas;
Atualizar espaco de trabalho;
Enviar solicitac
ao de mudanca;
Atualizar solicitacao de mudanca.
148
Captulo 14
CMM - Capability
Maturity Model
CMM, do acr onimo em ingles de Capability Maturity Model, e uma metodolo-

gia de diagn
ostico e avaliac
ao de maturidade do desenvolvimento de softwares
em uma organizacao.
Ele descreve os principais elementos de um processo de desenvolvimento de

software. O CMM descreve os est agios de maturidade atraves dos quais orga-
nizac
oes passam enquanto evoluem o seu ciclo de desenvolvimento de software,
atraves de avaliac
ao contnua, identificac
ao de problemas e ac
oes corretivas den-
tro de uma estrategia de melhoria dos processos. Este caminho de melhoria e
definido por cinco nveis de maturidade:
1. Inicial
2. Repetitivo
3. Definido
4. Gerenciado
5. Em Otimizac
ao
O CMM fornece ` as organizac

oes orientac
ao sobre como ganhar controle do
processo de desenvolvimento de software e como evoluir para uma cultura de
excelencia na gest
ao de software. O objetivo principal nas transic oes desses
nveis de maturidade e a realizac
ao de um processo controlado e mensurado
como a fundacao para melhoria contnua. Cada nvel de maturidade possui um
conjunto de praticas de software e gest
ao especficas, denominadas
areas-chave
do processo (KPA). Estas devem ser implantadas para a organizac ao atingir o
nvel de maturidade em questao.
O CMM identifica os nveis atraves dos quais uma organizacao deve evoluir
para estabelecer uma cultura de excelencia na engenharia de software. Como
cada nvel de maturidade do CMM forma a base necess aria sobre a qual o
pr
oximo nvel ser
a construdo, normalmente tentar pular nveis e improdutivo,
149
porque nao haver

a estabilidade na melhoria do processo, justamente pela falta
da base que a sustentaria.
Figura 14.1: Modelo CMM
14.1 Os nveis de maturidade no CMM

14.1.1 Nvel 1 - Inicial
No nvel 1 de maturidade os processos s
ao geralmente ad hoc e a organizac ao
geralmente nao disp
oe de um ambiente estavel. O sucesso nestas organizacoes
depende da competencia e herosmo dos funcion
arios e n
ao no uso de processos
estruturados. Devido ao imediatismo, um ambiente ca otico, o nvel 1 de ma-
turidade raramente produz um produto ou servico que funcione; assim, frequen-
temente eles excedem o orcamento e o prazo em seus projetos.
14.1.2 Nvel 2 - Repetitivo

No nvel 2 de maturidade, o desenvolvimento do software e repetido. O processo
pode nao se repetir para todos os projetos da organizac
ao. A organizac
ao pode
usar ferramentas de Gerencia de Projetos para mapear os custos e o prazo do
projeto.
A adoc
ao de um processo de desenvolvimento ajuda a garantir que pr aticas
existentes s
ao utilizadas em momentos de stress. Quando estas pr
aticas s
ao ado-
tadas, os projetos decorrem e sao gerenciados de acordo com o planejamento
inicial.
O status do projeto e os servicos entregues s ao visveis ao gerenciamento

(por exemplo: e possvel a visualizac
ao de marcos do projeto e o termino da
maioria das tarefas).
Tecnicas de gerenciamento de projetos sao estabelecidas para mapear custos,

prazos, e funcionalidades. Um mnimo de disciplina nos processos e estabelecido
para que se possa repetir sucessos anteriores em projetos com escopo e aplicac
ao
similar. Ainda h a um risco significante de exceder os custos e estimativas de
prazo de desenvolvimento.
150
As
areas chaves de processo desse nvel de maturidade s
ao:
Gerencia de Requisitos (RM);

Planejamento de Projeto de Software (SPP);
Acompanhamento e Supervis
ao de Projeto de Software (SPTO);
Gerencia de Subcontratato de Software (SSM);
Garantia da Qualidade de Software (SQA);
Gerencia da Configuracao de Software (SCM).
14.1.3 Nvel 3 - Definido

A organizacao possui um conjunto de processos padr oes, os quais s
ao a base
do nvel 3. Estes est
ao estabelecidos e s
ao melhorados periodicamente. Estes
processos padroes s
ao usados para estabelecer uma consistencia dentro da orga-
nizac
ao. Projetos estabelecem seus processos definidos pelo conjunto de padr
oes
processuais da organizac
ao.
O gerenciamento da organizac ao estabelece os objetivos dos processos baseado

no conjunto de padr
oes pre-definidos e garante que estes objetivos sejam encam-
inhados de forma apropriada.
Uma crtica distinc

ao entre os nveis 2 e 3 e o escopo dos padr oes, descric
ao
dos processos e procedimentos. No nvel 2, os padr oes, descric
oes de proces-
sos e procedimentos podem ser bem diferentes em cada inst ancia especfica do
processo (por exemplo, em um projeto particular). No nvel 3, os padr oes, de-
scric
oes de processo e procedimentos para o projeto s ao guiados pelo conjunto
padr ao de processos da organizacao.
As
ao:
Foco no Processo da Organizac

ao (OPF);
Definic
ao do Processo da Organizac
ao (OPD);
Programa de Treinamento (TP);
Gerencia Integrada de Software (ISM);

Engenharia de Produto de Software (SPE);
Coordenac
ao entre Grupos (IC);
Revis
oes Tecnicas Formais (PR).
151
14.1.4 Nvel 4 - Gerenciado

Utilizando metricas precisas, o gerenciamento pode efetivamente controlar os es-
forcos para desenvolvimento de software. Em particular, o gerenciamento pode
identificar caminhos para ajustar e adaptar o processo para projetos particu-
lares sem perda de metricas de qualidade ou desvios das especificac
oes.
Organizac
oes neste nvel conseguem metas qualitativas para o processo de
desenvolvimento de software e de manutenc
ao.
Subprocessos s ao selecionados conforme a import

ancia na performance total
do processo. Esses subprocessos selecionados s ao controlados usando tecnicas
estatsticas e qualitativas.
Uma crtica distinc

ao entre o nvel de maturidade 3 e 4 e a previsibilidade
do desempenho do processo. No nvel 4, o desempenho do processo e controlado
usando tecnicas estatsticas e qualitativas, e e previsvel qualitativamente. No
nvel 3, os processos s
ao somente previsveis qualitativamente.
As
ao:
Gerencia Quantitativa do Processo (QPM);

Gerencia de Qualidade de Software (SQM).
14.1.5 Nvel 5 - Otimizado

O nvel de maturidade 5 foca no contnuo aumento do desempenho dos proces-
sos atraves de melhoras de inovac
ao tecnologica e incremental. Objetivos de
melhoria quantitativa dos processos para a organizacao sao estabelecidos, con-
tinuamente revisados, refletindo os objetivos da organizac
ao, e usando criterios
de gerencia de processos.
Os efeitos da melhora da revis ao dos processos sao medidas e acompan-

hadas utilizando-se de processos de melhoria de qualidade. Ambos, os processo
definidos e o conjunto de processos padr
oes da organizac
ao s
ao alvos de melhoria
de metricas.
As
ao:
Prevenc
ao de Defeitos (DP);
Gerencia da Mudanca Tecnol

ogica (TCM);
Gerencia da Mudanca do Processo (PCM).
14.2 Um pouco mais sobre KPAs

As areas-chave de processo do Nvel 2 est
ao focadas nas quest
oes do projeto de
software relacionadas ao estabelecimento de controles basicos de gerenciamento
do projeto, e tem os seguintes objetivos:
152
Gerencia de Requisitos ` a Estabelecer um entendimento comum entre o

cliente e os requisitos (desejos, necessidades) do cliente que ser
ao atendidos
pela soluc
ao a ser desenvolvida;
Planejamento de Projeto de Software ` a Estabelecer planos coerentes para
realizar a engenharia de software e o gerenciamento do projeto;
Acompanhamento e Supervis ao de Projeto de Software `
a Estabelecer uma
adequada visibilidade do andamento (progresso) do software, de forma que
o gerenciamento possa tomar ac
oes corretivas se o planejamento original
n
ao estiver sendo seguido;
Gerencia de Subcontratato de Software ` a Selecionar fornecedores qualifi-
cados e gerenci
a-los de forma eficiente;
Garantia da Qualidade de Software `
a Fornecer ao gerenciamento visibili-
dade do processo em uso e dos produtos em construc
ao;
Gerencia da Configuracao de Software `
a Estabelecer e manter a integridade
dos produtos durante todo o ciclo de vida do software.
As
areas-chave do Nvel 3 est
ao focadas tanto nas quest
oes do projeto, quanto
da organizac
ao, conforme a organizac ao estabelece uma infra-estrutura que efe-
tivamente institucionaliza os processos de engenharia de software e de gerenci-
amento de todos os projetos.
As areas-chave do Nvel 4 est

ao focadas no estabelecimento quantitativo
tanto do processo de software, quanto dos produtos em construc
ao.
As areas-chave do Nvel 5 cobrem quest

oes que tanto a organizac
ao, quanto
os projetos devem considerar para implementar melhorias no processo de soft-
ware que sejam contnuas e mensur aveis.

Figura 14.2: Areas-chave de processo no modelo CMM
14.3 Efeitos da evolu

cao do nvel de maturidade
A evoluc
ao no nvel de maturidade causa efeitos nas pessoas, nas tecnologias e
nas pr
aticas de medidas. A seguir sao apresentados esses efeitos em cada nvel
153
de maturidade.
Pessoas
Nvel 1: Sucesso depende de indivduos e her
ois. Regime constante
de emergencia (apagar incendio). Relacionamento entre grupos e
descoordenado e muitas vezes conflitante;
Nvel 2: Sucesso ainda depende de indivduos, mas passam a contar
com apoio gerencial. Os compromissos s ao compreendidos e gerenci-
ados. Existe treinamento para algumas func oes;
Nvel 3: Grupos de projeto trabalham de maneira coordenada. O
treinamento e planejado de acordo com as necessidades de cada papel
e aplicado convenientemente;
Nvel 4: Existe um forte sentido de trabalho em equipe;
Nvel 5: Todos est
ao engajados em atividades de melhoria contnua.
Tecnologia
Nvel 1: A introduc
ao de novas tecnologias e arriscada;
Nvel 2: Atividades bem definidas facilitam a introduc
ao de novas
tecnologias;
Nvel 3: Novas tecnologias s
ao avaliadas qualitativamente;
ao avaliadas quantitativamente;
ao planejadas e introduzidas com total
controle.
Medidas
Nvel 1: Coleta de dados e feita de maneira ad hoc;

Nvel 2: Coleta de dados de atividades de planejamento e acompan-
hamento e feita de maneira sistematica;
Nvel 3: Todos os processos definidos tem coleta sistem
atica de dados,
os quais sao compartilhados por todos os projetos da organizac ao;
Nvel 4: A definic
ao e coleta de dados s
ao padronizadas na orga-
nizac
ao e os dados s
ao usados para entender os processos de maneira
quantitativa e estabiliz
a-los;
Nvel 5: Os dados coletados s ao usados para avaliar e selecionar

possibilidades de melhoria de processos.
154
Parte IV
Linguagem de Programa
c
ao
Java
155
Captulo 15
Conceitos B
asicos de Java
15.1 Pacotes
Em projetos pequenos e comum colocar todos os arquivos java em um u nico
diret
orio. Essa e uma abordagem r apida, simples. No entanto, se o pequeno
projeto comecar a crescer, o n
umero de arquivos aumentar
a e administr
a-los em
um unico diret
orio pode se tornar um problema.
Pacotes nao s
ao nada mais que uma forma de organiza os arquivos que inte-
gram o projeto em diferentes diret
orios de acordo com suas funcionalidades ou
categoria a qual eles pertencam.
Por exemplo, os arquivos no pacote java.io s

ao todos relacionados com fun-
cionalidades de I/O, enquanto os arquivos do pacote java.net fornecem fun-
cionalidades para tratar de redes. Em aplicac oes com interface gr
afica, por
exemplo, e muito comum encontrar um diret orio chamado ui (user interface).
Alem de melhorar a organizacao dos arquivos que comp oe o projeto, a uti-

lizac
ao de pacotes ajuda a evitar colis
ao de nomes entre classes. Por exemplo:
Se um programador definir uma classe chamada Vector, esse nome iria colidir
com a classe Vector da JDK. No entanto, isso n ao ocorre por que a JDK usa
java.util como um nome de pacote para a classe Vector. Dessa forma, a classe
implementada pelo programador pode se chamar Vector. A figura 15.1 mostra
uma estrutura de diret orios criada pela utilizac
ao de pacotes.
156
Para indicar que uma classe pertence a um determinado pacote basta inciar
o arquivo java como mostrado no exemplo a seguir.
//Somente c
odigo pode vir antes dessa linha
package world;
public class HelloWorld {

public static void main(String[] args) {
System.out.println("Hello World");
}
}
15.2 Modificadores de Acesso

Os modificadores de acesso s ao keywords adicionadas ao codigo para determinar
se atributos, metodos ou classes poderam ser acessados a partir de outras classes.
Os modificadores de acesso presentes na linguagem Java s ao: public, private,
protected e package-private (implcito quando nao e usado nenhum modificador
na declarac
ao da classe, atributo ou metodo).
Uma classe p ublica pode ser acessada por qualquer outra classe. Caso seja
declarada sem o modificador public, a classe ser
a package-private, ou seja, s
o
podera ser acessada por classes do mesmo pacote.
Os metodos e atributos aceitam outros modificadores alem do public. O

modificador private d
a acesso somente dentro da classe, enquanto o modificador
protected permite acesso dentro do pacote e `
as subclasses.
Assim como nas classes, caso nenhum modificador seja declarado, fica implcito
o modificador package-private.
A tabela 15.1 abaixo resumo as permic

oes de acesso impostas por cada um
dos modificadores:
Modificador Pacote Subclasse Todos

public sim sim sim
private n
ao n
ao n
ao
protected sim sim n
ao
nenhum sim n
ao n
ao
Tabela 15.1: Modificadores de Acesso
15.3 Vari
aveis
Na linguagem de programac
ao Java s
ao definidos os seguintes tipos de vari
aveis:
Vari
aveis de Inst
ancia (Atributos n
ao est
aticos): Um objeto armazena seu
estado individual em atributos n ao est
aticos, ou seja, declarados sem o
157
modificador static. Atributos nao est

aticos s
ao conhecidos com vari
aveis
de instancia por que seus valores s
ao u
nicos para cada inst
ancia de uma
classe;
Vari aveis de Classe (Atributos est aticas): Uma vari avel de classe e todo
atributo declarado com o modificador static. Isso indica ao compilador
que existe apenas uma c opia da variavel, n
ao importando o n umero de
vezes que essa classe foi instanciada. Portanto, quando o valor de uma
variavel de classe e alterada em um dos objetos, o novo valor se torna
visvel para todos os outros objetos da mesma classe. Para impedir que
uma vari avel de classe tenha seu valor alterado ela deve ser declarada com
o mofificador final.
Variaveis Locais: As vari aveis locais sao utilizadas para armazenar o es-
tado tempor ario dos metodos. A sintaxe de declarac ao de uma variavel
local e similar a de declarac ao de uma vari avel de inst
ancia. O que deter-
mina se uma vari avel e local e a parte do c
odigo em que ela e declarada
- entre as chaves que determinam o incio e o fim de um metodo. Uma
vari
avel e visvel apenas para o metodo no qual foi declarada; n ao pode
ser acessada do resto da classe.
public class Bicicleta {
// Vari
avel de Inst^
ancia
public int velocidade = 0;
// Vari
avel de Classe
public static int qtdRodas = 2;
// Vari
avel de Classe com valor constante
public static final String marca = "Caloi";
public void aumentaVelocidade (int incremento){

// Vari
avel Local
int novaVelocidade; = velocidade + incremento;
velocidade = novaVelocidade;
}
}
15.4 Operadores
A lista abaixo sumariza os operadores suportados pela linguagem Java:
Operador de Atribuic
ao Simples
= Operador de Atribuic
ao Simples
158
Operadores aritmeticos
+ Adic
ao (Tambem utilizado para concatenac
ao de Strings)
- Subtrac
ao
Multiplicac
ao
/ Divis
ao
% Resto da Divisao
Operadores Un
arios
+ Operador un
ario mais
Operador un
ario menos; Inverte o sinal de uma vari
avel
++ Operador de Incremento; Incrementa um valor de 1
Operador de Decremento; Decrementa o valor de 1
! Operador L
ogico de complemento; Inverte o valor de um boolean
Operadores de Comparac
ao
== Igual
!= Diferente
> Maior
>= Maior ou Igual
< Menor
<= Menor ou Igual
instanceof Compara um objeto a um tipo especfico
Operadores Condicionais
&& AND Condicional

|| OR Condicional
?: Tern
ario (Forma curta para if-then-else)
Operadores Bit a Bit e de Deslocamento (Shift)
Complemento bit a bit un ario

<< shift para esquerda

>> Shift para direita
>>> Shift para direita sem sinal
& AND bit a bit
OR exclusivo bit a bit
| OR bit a bit
159
15.5 Express
oes, Senten
cas e Blocos
Uma express ao e uma construc
ao feita de vari
aveis, operadores e chamadas de
metodos, descrita de acordo com a sintaxe da linguagem. A seguir, exemplos
de express
oes:
//Declara
c~ao e inicializa
c~ao de uma v
ari
avel do tipo int
int cadence = 0;
//Atribui
c~ao de valor a uma posic~
ao de um vetor de int
anArray[0] = 100;
//Imprimindo um valor na tela
System.out.println("Element 1 at index 0: " + anArray[0]);
//Atribui
c~ao de valor baseado no resultado de uma operac~ao de adi
c~ao
result = 1 + 2;
//Utiliza
c~ao de par^
entesis para explicitar ordem de execu c~
ao das opera
c~oes
zaz = x / (y+10);
Em java uma sentenca (statements) e definida como uma unidade completa

de execuc
ao. Os seguintes tipos de express
oes podem se tornar sentencas quando
terminadas com um ponto e vrgula: (i) Express oes de Atribuic
ao; (ii) Ex-
press
oes com ++ ou ; (iii) Chamada de metodos e (iv) Express oes de Criac
ao
de objetos.
// Statement de atribuic~
ao
aValue = 8933.234;
// Statement de incremento
aValue++;
// Statement de chamada de metodo
System.out.println("Hello World!");
// Statement de cria
c~ao de objeto
Bicycle myBike = new Bicycle();
Essas sao as chamadas statements de express ao. Existem ainda as state-

ments de declarac
ao de vari
avel e de controle de fluxo.
Um bloco e um grupo de zero ou mais statements entre um par de chaves.

O exemplo a seguir ilustra o uso de blocos em Java:
class BlockDemo {
boolean condition = true;
if (condition) { // begin block 1
System.out.println("Condition is true.");
} // end block one
else { // begin block 2
System.out.println("Condition is false.");
} // end block 2
}
}
160
15.6 Comandos de Controle de Fluxo

As statements de um codigo geralmente s
ao executadas na medida na ordem em
aparecem. No entanto, os comandos de controle de fluxo podem ser utilizadas
ara interromper o fluxo de execuc
ao empregando decis oes, looping e desvios,
permitindo que ao programa executar condicionalmente blocos de c odigo par-
ticulares. Os principais comandos de controle de fluxo da linguagem Java sao
mostrados a seguir.
If-Then
void applyBrakes(){
if (isMoving){ // the "if" clause: bicycle must moving
currentSpeed--; // the "then" clause: decrease current speed
}
}
If-Then-Else
//Exemplo 1
void applyBrakes(){
if (isMoving) {
currentSpeed--;
} else {
System.err.println("The bicycle has already stopped!");
}
}
//Exemplo 2
class IfElseDemo {
int testscore = 76;

char grade;
if (testscore >= 90) {

grade = A;
} else if (testscore >= 80) {
grade = B;
grade = C;
grade = D;
} else {
grade = F;
}
//O resultado ser
a C pois, uma vez que a condi
c~ao
e atendida,
//o restante do c
odigo If-Then-Else n~
ao
e mais avaliado
System.out.println("Grade = " + grade);
161
}
}
Switch
class SwitchDemo {
int month = 2;
int year = 2000;
int numDays = 0;
switch (month) {
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12:
numDays = 31;
break;
case 4:
case 6:
case 9:
case 11:
numDays = 30;
break;
case 2:
if ( ((year % 4 == 0) && !(year % 100 == 0))
|| (year % 400 == 0) )
numDays = 29;
else
numDays = 28;
break;
default:
System.out.println("Invalid month.");
break;
}
//O resultado sera 29

System.out.println("Number of Days = " + numDays);
}
}
While e Do-While
//Exemplo While
class WhileDemo {
public static void main(String[] args){
int count = 1;
//Teste realizado antes da execu
c~ao do bloco de c
odigo
162
//Pode acontecer do codigo n~

ao ser executado nenhuma vez
while (count < 11) {
System.out.println("Count is: " + count);
count++;
}
}
}
//Exemplo Do-While
class DoWhileDemo {
int count = 1;
do {
System.out.println("Count is: " + count);
count++;
//Teste ao fim da execu
c~ao do bloco de c
odigo
//C
odigo
e executado ao menos uma vez
} while (count <= 11);
}
}
For
//Exemplo 1
class ForDemo {
for(int i=1; i<11; i++){
System.out.println("Count is: " + i);
}
}
}
//Exemplo 2
for ( ; ; ) { //infinite loop
// c
odigo
}
//Exemplo 3
class EnhancedForDemo {

int[] numbers = {1,2,3,4,5,6,7,8,9,10};
for (int item : numbers) {
System.out.println("Count is: " + item);
}
}
}
Break
//Exemplo 1
class BreakDemo {
163

int[] arrayOfInts = {32,87,3,589,12,1076,2000,8,622,127};
int searchfor = 12;
int i;
boolean foundIt = false;
for (i = 0; i < arrayOfInts.length; i++) {

if (arrayOfInts[i] == searchfor) {
foundIt = true;
//Encerra o loop for
break;
}
}
if (foundIt) {
System.out.println("Found " + searchfor + " at index " + i);
} else {
System.out.println(searchfor + " not in the array");
}
}
}
//Exemplo 2
class BreakWithLabelDemo {
int[][] arrayOfInts = {{32,87,3,589},
{12,1076,2000,8},
{622,127,77,955}};
int searchfor = 12;

int i;
int j = 0;
search:
for (i = 0; i < arrayOfInts.length; i++) {
for (j = 0; j < arrayOfInts[i].length; j++) {
if (arrayOfInts[i][j] == searchfor) {
foundIt = true;
//Encerra o loop for mais interno

//e desvia para o label search
break search;
}
}
}
if (foundIt) {
System.out.println("Found " + searchfor + " at " + i + ", " + j);
} else {
System.out.println(searchfor + " not in the array");
164
}
}
}
Continue
//Exemplo 1
class ContinueDemo {
String searchMe = "peter piper picked a peck of pickled peppers";

int max = searchMe.length();
int numPs = 0;
for (int i = 0; i < max; i++) {

//interested only in ps
if (searchMe.charAt(i) != p){
//Vai para o pr
oximo loop sem executar
//o restante do c
odigo do bloco for
continue;
}
//process ps
numPs++;
}
System.out.println("Found " + numPs + " ps in the string.");
}
}
//Exemplo 2
class ContinueWithLabelDemo {
String searchMe = "Look for a substring in me";

String substring = "sub";
int max = searchMe.length() - substring.length();

test:
for (int i = 0; i <= max; i++) {
int n = substring.length();
int j = i;
int k = 0;
while (n-- != 0) {
if (searchMe.charAt(j++)!= substring.charAt(k++)) {
//Interrompe a itera
c~ao do loop while e vai
//para proxima itera
c~ao do loop for,
//marcada pelo label test
continue test;
165
}
}
foundIt = true;
break test;
}
System.out.println(foundIt ? "Found it" : "Didnt find it");
}
}
15.7 Classes Aninhadas

No Java existe a possibilidade de se definir classes dentro de outra classe, como
se fossem atributos ou metodos. Algumas das vantagens de se utilizar esse
recurso do Java s
ao:
Legibilidade: Classes podem ser sgrupadas por similaridade;

Ocultamento: Podem ser privadas ou protegidas;
Redigibilidade: Classes internas possuem acesso aos membros privados da
classe que a definiu e vice-versa. Na verdade, o recurso de classes internas
surgiu no Java 1.1 com esse prop osito.
Como s ao definidas dentro de outras classes, o c

odigo fonte fica no mesmo
arquivo .java. Ao compilar, gera-se v
arios arquivos .class, compondo o nome da
classe externa e interna. Exemplo: Externa.java contem a classe Externa, que
define uma classe interna chamada Interna. Ao compilar, gera-se Externa.class
e Externa$Interna.class. E importante ressaltar que a classe interna n ao pode
ter o mesmo nome da classe externa que a define.
No Java existem os seguintes tipos de classes internas:
Classes Aninhadas
Classes Instanciadas
Classes Membro
Classes Locais
Classes An
onimas
As classes aninhadas s ao os tipos mais simples de classes internas. Uma

classe e definida dentro da outra como se fosse um membro static. Elas permitem
definir acesso privado ou protegido e agrupa classes logicamente relacionadas.
S
ao referenciadas via Externa.Interna, como se fosse um atributo est atico. A
seguir um exemplo de classe aninhada e de como referenci a-la:
//Classe externa
class Par {
private Chave chave;
166
private Valor valor;
public Par(Chave chave, Valor valor) {

this.chave = chave;
this.valor = valor;
}
//Classe interna
static class Chave {
private String nome;
public Chave(String nome) {
this.nome = nome;
}
}
//Classe interna com prote

c~ao de acesso
protected static class Valor {
private int valor;
public Valor(int valor) {
this.valor = valor;
}
}
public class Teste {

Par.Chave chave = new Par.Chave("Nota");
Par.Valor valor = new Par.Valor(10);
Par par = new Par(chave, valor);
}
15.8 Tipos Enumerados

Tipos enumerados s ao aqueles que possuem um conjunto finitos de valores que
as vari
aveis podem assumir. Por exemplo: estacoes do ano, naipes ou cartas do
baralho, planetas do sistema solar etc. Originalmente, a forma padrao utilizada
para representar tipos enumerados era o chamado int Enum Pattern (tipos enu-
merados baseados em inteiros).
// int Enum Pattern

public static final int SEASON_WINTER = 0;
public static final int SEASON_SPRING = 1;
public static final int SEASON_SUMMER = 2;
public static final int SEASON_FALL = 3;
167
Esse tipo de padronizac

ao apresentava os seguintes problemas:
Nao seguro quanto ao tipo: Como uma season e representada por um

int, pode-se passar qualquer valor inteiro (inclusive diferente de 0,1,2,3)
quando uma season for requerida;
Sem namespace: E necessario criar um padr

ao de nomenclatura para evi-
tar colis
ao com outros tipos enumerados. (Exemplo: SEASON ).
Valores imprimidos n
ao s
ao explicativos: Como os valores s
ao int, quando
impressos n
ao apresentam a informacao que representam diretamente.
Para contornar esses problemas a partir do Java 5 foi introduzido o Typesafe

Enum Pattern, a partir do qual os tipos enumerados podem ser expressos de
forma mais simples. O codigo abaixo mostra o uso do novo padr ao para tipos
enumerados:
public class Weather {
//Define tipo enumerado Refrigerante

public enum Season = {winter, spring, summer, fall};
private printSeasons() {
//Loop recuperando cada um dos valores poss
veis de Season
for (Season s : Season.values()){
System.out.println(s);
}
}
}
15.9 Anotac
oes
Anotacoes (annotations) proveem dados sobre o programa mas n ao s
ao parte do
do programa propriamente dito. Elas n ao possuem efeito direto na operac
oes do
c
odigo com o qual est ao relacionadas. Esse recurso da linguagem Java permite
que o programador n ao se preocupe em escrever c odigo auxiliar (arquivos de
configurac
ao, por exemplo). A ideia e que o programador diga o que tem que
ser feito utilizando as anotacoes e ferramentas auxiliares facam o restante do
trabalho. Alguns exemplos do uso de anotac oes s

ao:
Informac
oes para o compilador: Anotac
oes podem ser utilizadas pelo com-
pilador para detectar erros ou sumprimir mensagens de warning;
Processamento em tempo de Compilac ao ou Deploy: Ferramentas aux-
iliares podem processar as anotac
oes para gerar c
odigo, arquivos XML
etc;
Processamento em tempo de Execuc ao: Algumas anotac
oes podem ser
processsadas em tempo de execuc
ao;
168
Documentac
ao: Anotacoes podem ser utilizadas para substituir coment
arios
no c
odigo.
Os tres pre-defindos de anotac
oes utilizadas pelo compilador s
ao:
@Deprecated: Indica que o elemento marcado est
a deprecated e n
ao deve
ser mais utilizado. O compilador gera um warning sempre que um pro-
grama utilizar um uma classe, um metodo ou um atributo marcado como
@Deprecated;
@Override: Informa ao compilador que o elemento marcado deve sobre-

screver o elemento de mesmo nome declarado na superclasse. Embora
a anotac
ao n
ao seja obrigat
orio para sobrescrever um metodo, utiliz
a-la
ajuda a prevenir erros;
@SuppressWarnings: Indica ao compilador situac
oes em que os warnings
devem ser suprimidos;
A seguir alguns exemplos de utilizac
ao das anotac
oes descritas.
//Marca o metodo como deprecated

@Deprecated
static void deprecatedMethod() { //c
odigo }
//Indica que o m
etodo ir
a sobrescrever o m
etodo da superclasse
@Override
int overriddenMethod() { //c
odigo }
//Indica ao compilador para suprimir warning gerados pelo uso

//de m
etodos deprecated
@SuppressWarnings("deprecation")
void useDeprecatedMethod() {
//O uso de um m
etodo deprecated geraria um warning
objectOne.deprecatedMethod();
}
15.10 Gen
ericos
Os genericos s
ao um recurso introduzido a partir Java 5 e permite ao progra-
mador escrever c odigo abstraindo tipos de dados. Os genericos s
ao tipicamente
utilizados em conjunto com interfaces ex: List) que herdam da interface Collec-
tion ou de classes que a implementam (ex: AbstractList, ArrayList, LinkedList,
Vector)
Quando um elemento e retirado de uma Collection e necess ario realizar um

cast para o tipo do elemento armazenado na Collection. Alem de incoveniente,
isso e inseguro. O compilador nao checa se o cast realizado e do mesmo tipo do
armazenado na colec ao. Dessa forma, o cast pode falhar em tempo de execuc ao.
169
//Criac~
ao de uma collection do tipo LinkedList
List myIntList = new LinkedList();
//Adi
c~ao de um elemento do tipo Integer a collection
myIntList.add(new Integer(0));
//Recuperando um elemento da collection. Cast para Integer
e necess
ario
Integer x = (Integer) myIntList.iterator().next();
Os genericos proveem uma forma de comunicar ao compilador o tipo ar-

mazenado na colec ao, permitindo que a checagem seja feita em tempo de com-
pilac
ao. Alem de evitar erros em tempo de execuc
ao, a utilizac
ao de genericos
elimina a necessidade de casts.
//Criac~
ao de uma collection LinkedList para armazenar objetos do tipo Integer
List<Integer> myIntList = new LinkedList<Integer>();
//Adi
c~ao de um elemento do tipo Integer a collection
myIntList.add(new Integer(0));
////Recuperando um elemento da collection. Cast n~ao e necess
ario
Integer x = myIntList.iterator().next();
Os tipos genericos tem como grande vantagem o aproveitamento de c odigo.

A interface Collection e um exemplo disso. As operac oes de adicionar ou re-
mover um novo elemento, determinar o tamanho, verificar se a collection est a
vazia ou recuperar o ndice de um determinado elemento, por exemplo, cer-
tamente sao aplicaveis a collections do tipo Integer, String ou de outra classe
qualquer. Exemplos de interfaces genericas sao List e Iterator. A seguir, alguns
trechos dessas duas interfaces como definidas no pacote java.util.
public interface Iterator<E> {

E next();
boolean hasNext();
//mais c
odigo ...
}
public interface List<E> {

void add(E x);
Iterator<E> iterator();
//mais c
odigo ...
Genericos permitem implementac

oes mais sofisticadas como:
//Wildcards ou Coringas
//M
etodo com par^
ametro Casulo. Aceita Casulo de qualquer tipo
void imprimir (Casulo<?> c) {
// c
odigo do m
etodo ...
}
//Limitando o tipo gen

erico aceito pelo m
etodo
//M
etodo s
o aceita Casulo de Forma ou Casulos de subclasses de Forma
170
void desenhar (Casulo<? extends Forma> c){

// c
odigo do m
etodo ...
}
15.11 Reflex
ao
A Reflection permite um programa Java examinar ou fazer a introspecc ao nele
mesmo, ou seja, olhar e examinar suas propriedades e estrutura. Com isso, voce
pode, por exemplo obter o nome de todos os membros de uma classe, como
atributos e metodos, bem como executar um metodo usando a Introspection.
Esse recurso e utilizado, por exemplo, pelos ambientes de desenvolvimento (as
IDEs) para examinar e exibir a estrutura e conte udo das classes e beans. A
seguir um exemplo do uso de refetions.
import java.lang.reflect.*;
public class Classe1 {
private int funcao1( Object p, int x ) throws NullPointerException {

if (p == null) throw new NullPointerException();
return x;
}
public static void main(String args[]) {

try {
//Carrega a classe
Class cls = Class.forName("Classe1");
//Recupera a lista de metodos da classe
Method methlist[] = cls.getDeclaredMethods();
//Imprime informa
c~oes (m
etodos, modificadores, exce
c~oes)
//sobre cada um dos metodos da classe
for (int i = 0; i < methlist.length; i++) {
Method m = methlist[i];
System.out.println("-------------------------------------");
System.out.println("nome = " + m.getName());
System.out.println("-------------------------------------");
System.out.println("membro de:" + m.getDeclaringClass());

System.out.println("modificador:" + Modifier.toString(m.getModifiers()));
//Recupera lista de par^

ametros do m
etodo
Class pvec[] = m.getParameterTypes();
for (int j = 0; j < pvec.length; j++)
System.out.println("par^
ametro #" + j + " " + pvec[j]);
//Recupera a lista de excess~

oes do m
etodo
Class evec[] = m.getExceptionTypes();
for (int j = 0; j < evec.length; j++)
171
System.out.println("exce
c~ao #" + j + " " + evec[j]);
//Recupera o tipo de retorno do m

etodo
System.out.println("tipo de retorno = " + m.getReturnType());
}
}
catch (Throwable e) {
System.err.println(e);
}
}
}
//Sa
da da execu
c~ao da classe Classe1:
//Lista de m
etodos da Classe1 com todas as suas propriedades
-------------------------------------
nome = funcao1
-------------------------------------
membro de:class Classe1
modificador:private
par^
ametro #0 class java.lang.Object
par^
ametro #1 int
excec~
ao #0 class java.lang.NullPointerException
tipo de retorno = int
-------------------------------------
nome = main
-------------------------------------
membro de:class Classe1
modificador:public static
par^
ametro #0 class [Ljava.lang.String;
tipo de retorno = void
172
Captulo 16
Classes Essenciais
16.1 Exception e Controle de Exce

coes
Uma excec
ao e um evento que ocorre durante a execuc
ao de um programa in-
terrompendo seu fluxo normal de execuc
ao.
Quando um erro ocorre dentro de um metodo, o metodo cria um objeto

chamado exception e o entrega ao controle de execuc ao (runtime system), que
contem informac
oes sobre o erro, incluindo seu tipo e o estado do programa
quando o erro ocorreu. O ato de criar um objeto exception e a entreg a-lo ao
runtime system e chamado lancamento de uma excecao (throwing an exception).
O runtime system ent ao pesquisa na pilha de chamadas por um metodo que

contenha um bloco de c odigo capaz de tratar a excec
ao. Esse bloco de c
odigo
e chamado tratador de excec oes (exception handler). A pesquisa comeca no
metodo onde o erro ocorreu e procede na pilha na ordem reversa em que os
metodos foram chamados. Quando um tratador adequado e encontrado, o run-
time syste o entrega a excecao. Um tratador e considerado adequado quando o
tipo da excec
ao lancada coincide com o tipo definido no tratador (IOException,
ClassNotFoundException, etc.).
Quando um tratador e escolhido diz-se que ele capturou a excec

ao (catches
the exception). Se o runtime system pesquisa em toda a pilha de metodos e
n
ao encontrar um tratador adequado, o programa ser a encerrado. A figura 16.1
mostra a ordem de pesquisa por um tratador para a excecao.
16.1.1 Exce
coes tpicas
Em Java excecoes s
ao objetos. A classe Exception e a superclasse de todas as
excec
oes. Exemplos tpicos de excec
oes s
ao:
Indice de uma array fora do intervalo permitido (ArrayIndexOutOfBound-
sException);
Problemas em operac
oes aritmeticas, como overflows e divis
oes por zero
(ArithmeticException);
173
Figura 16.1: Procura pelo tratador de excec

oes
Argumentos inv
alidos numa chamada a um metodo (IllegalArgumentEx-
ception);
Uso de uma referencia que n
ao aponta para nenhum objeto (NullPoint-
erException);
Acesso a um arquivo inexistente (FileNotFoundException);
Erros de banco de dados (SQLException);
A classe Exception, por sua vez, e subclasse de Throwable, o que permite

que as excec
oes sejam lancadas. Se o programador desejar que a excec ao assim
lancada seja tratada fora do metodo que a gerou, ele deve explicitar isto usando
a palavra chave throws seguida do tipo de excecao, na declaracao do metodo.
//Exemplo 1: M
etodo indica que todas exce
c~oes ser~
ao lan
cadas, ou seja,
// n~
ao ser~
ao tratadas internamente.
public void simpleMethod1 (String x) throws Exception {

//...
if (problema1) throw Exception;
//...
}
//Exemplo 2: M
etodo indica que as exce~
oes do tipo excecao1
// e excecao2 nao ser~

ao tratadas internamente.
public void simpleMethod2 (int a, int b) throws excecao1, excecao2 {

//...
if (problema1) throw excecao1;
if (problema2) throw excecao2;
//...
}
Na verdade, existe uma classe de excec oes, a RuntimeException, que n ao

precisam ser lancada explicitamente. RuntimeException e uma superclasse das
excec
oes que podem ocorrer durante a operac
ao normal da m
aquina virtual Java.
174
Uma vez que a excec ao foi lancada, a execuc

ao do metodo e interrompida e o
controle volta ao objeto que chamou este metodo. Exemplos de classes que her-
dam de RuntimeException s ao ArithmeticException, BufferOverflowException,
ClassCastException, IllegalArgumentException, IndexOutOfBoundsException,
NullPointerException, SystemException, etc.
A figura 16.2 mostra como as excec

oes est
ao organizadas na hierarquia de
classes da linguagem Java.
Figura 16.2: Exceptions e Errors
Alem das excec

oes tpicas, a figura 16.2 mostra tambem a classe Error. Er-
ror e uma subclasse de Throwable que indica situac oes excepcionais externas a
aplicac
ao, das quais a aplicac
ao nem sempre e capaz de se recuperar, por exem-
plo, um problema de hardware. Uma aplicac ao pode decidir por capturar um
erro com objetivo de notificar o usu ario sobre o problema, no entanto, quase
sempre faz mais sentido para o programa imprimir um stack trace e encerrar.
A classe VirtualMachineError e um exemplo de subclasse de Error, que en-

globa problemas como falta de memoria (OutOfMemoryError) e estouro de pilha
(StackOverflowError).
16.1.2 Capturando Excec

oes
Para capturar uma excec
ao e utilizada a seguinte estrutura de c
odigo:
try {
// C
odigo que pode gerar exce
c~oes dos tipos
// ExceptionType1 e ExceptionType2
}catch(ExceptionType1 opa1){
// C
odigo para lidar com uma exce
c~ao do tipo
// ExceptionType1
}catch( ExceptionType2 opa2 ){

// C
odigo para lidar com uma exce
c~ao do tipo
// ExceptionType2
175
}finally{
// C
odigo que deve ser executado em qualquer caso
Quando ocorre uma excec ao, os blocos catch s

ao examinados sucessivamente
ate que o argumento corresponda ao tipo da excec ao. No exemplo acima, se
ExceptionType2 for uma subclasse de ExceptionType1, o segundo bloco catch
nunca sera alcancado. Neste caso, deve-se inverter a ordem dos blocos catch.
O bloco finally e opcional, e normalmente e usado para realizar acoes que

independem da ocorrencia de uma excec ao em um dado bloco de comandos.
Por exemplo, em um sistema que escreve informac oes em um banco de dados,
e necessario fechar a conex
ao com este u ltimo ao final da operac
ao de escrita,
independentemente da operac ao ter sido bem-sucedida ou n ao. Tendo isso em
vista, o comando respons avel por fechar a conex
ao deve ficar dentro de um bloco
finally.
16.2 Threads e Concorr

encia
Em programac ao concorrente existem duas unidades b
asicas de execuc
ao: pro-
cessos e threads. Em java, os recrsos para programac
ao concorrente sao mais
voltados para o uso de threads.
Threads s
ao comumente chamadas de processos leves. Processos e threads
proveem um ambiente de execuc
ao, mas criar uma thread requer menos recursos
que criar um processo. As threads existem dentro dos processos - cada processo
possui pelo menos uma. As threads compartilham os recursos do processo, in-
cluindo mem oria e arquivos abertos, favorecendo a eficiencia da comunicac
ao,
porem a tornando potencialmente problem atica.
Cada aplicac
ao possui pelo menos uma thread - ou v
arias, se considerarmos
a threads de sistema. Do ponto de vista do programador, uma aplicacao comeca
com apenas uma u nica thread chamada main, e essa possui a habilidade para
criar novas threads.
16.2.1 Definindo e Iniciando uma Thread

Existem duas formas basicas de se definir uma thread em Java: implementar a
interface Runnable ou extender a classe Thread. O c odigo para cada um das
formas segue abaixo:
//Implementando a interface Runnable

public class HelloRunnable implements Runnable {
public void run() {
System.out.println("Hello from a thread!");
}
176

(new Thread(new HelloRunnable())).start();
}
}
//Extendendo a classe Thread

public class HelloThread extends Thread {
public void run() {
System.out.println("Hello from a thread!");
}
(new HelloThread()).start();
}
}
A primeira forma e mais geral e flexvel, porque objetos Runnable podem

herdar de outras classes diferentes de Thread. No entanto, a segunda forma e
mais simples e funciona bem para aplicacoes que pouco complexas.
Em ambos os casos, a tarefa executada pela thread deve ser implementada

no metodo Thread.run e para inici
a-la deve ser utilizado o metodo Thread.start.
16.2.2 Pausando a execuc

ao com sleep
Thread.sleep faz com que a thread corrente suspenda sua execuc ao por um
perodo de tempo especfico. Essa uma forma de liberar o processador para
outras threads ou processos que estejam rodando no sistema. O parametro do
metodo Thread.sleep e o tempo em milissegundos.
public class SleepMessages {

public static void main(String args[]) throws InterruptedException {
String importantInfo[] = {
"Mares eat oats",
"Does eat oats",
"Little lambs eat ivy",
"A kid will eat ivy too"
};
for (int i = 0; i < importantInfo.length; i++) {

//Pausa a thread corrente (main) por 4 segundos
Thread.sleep(4000);
//Imprime uma mensagem
System.out.println(importantInfo[i]);
}
}
}
177
16.2.3 Interrup
coes
Uma interrupcao indica que a thread deve parar o que est
a fazendo e comecar
a fazer outra coisa. E o programador quem deve definir como a thread deve
responder a uma interrupcao. O uso mais comum de interrupc oes e finalizar a
execuc
ao de uma thread.
for (int i = 0; i < importantInfo.length; i++) {

//Pause for 4 seconds
try {
Thread.sleep(4000);
} catch (InterruptedException e) {
//Weve been interrupted: no more messages.
return;
}
//Print a message
System.out.println(importantInfo[i]);
}
16.2.4 Joins
O metodo join e usado para fazer com que uma thread aguarde ate que outra
thread termine. Em geral, o join e utilizado para a thread esperar pelo termino
da execuc
ao de suas threads filhas. Imagine uma aplicac ao que dependa da
execuc
ao de tres tarefas independentes A, B e C. A aplicac
ao s
o pode continuar
quando cada uma das tarefas estiver sido completada. Portanto, a aplicac ao
(thread principal) deve executar o metodo join para cada uma das tarefas A,B
e C. O codigo java para essa situac
ao teria a seguinte estrutura:

System.out.println("Thread main iniciada");
//C
odigo inicial da thread main
//Threads auxiliares A, B e C
Thread a = new thread_tarefaA();
Thread b = new thread_tarefaB();
Thread c = new thread_tarefaC();
//Iniciando as threads auxiliares

a.start();
b.start();
c.start();
//Aguardando as threads auxiliares terminarem

a.join();
b.join();
c.join();
//C
odigo restante da thread main
178
System.out.println("Thread main encerrada");

}
16.2.5 Sincroniza
c
ao
As threads se comunicam entre si essencialmente por meio de compartilhamento
no acesso de atributos e referencias a objetos. Essa e uma forma de comunicac ao
eficiente, porem permite a ocorrencia de dois tipos de erros: interferencia entre
threads e erros de consistencia de mem oria. Para contornar esses problemas o
Java oferece o recurso de sincronizac ao.
O problema da interferencia ocorre quando duas operac oes, rodando em

threads diferentes, mas atuando sobre o mesmo dado, se intercalam.
//Interfer^
encia entre threads
//Três threads que atuam sobre o mesmo dado

//N~
ao e poss
vel garantir a ordem de execu
c~ao das opera
c~oes
//pois em princpio, as threads s~
ao iniciadas ao mesmo tempo.
int a = 0;
thread_incrementa_a.start();
thread_decrementa_a.start();
thread_imprime_a.start();
Os erros de inconsistencia de mem oria ocorrem quando diferentes threads

tem diferentes visoes daquilo que deveria ser o mesmo dado. As causas dos
erros de inconsistencia de memoria s
ao complexas e est
ao fora do escopo dessa
sec
ao.
A chave para evitar esse tipo de erro est

a em entender o que o Java chama de
relacionamento happens-before. Esse relacionamento consiste em garantir que a
mem oria escrita por uma statement especfica est
a visvel para uma outra state-
ment. Para criar esse tipo de relacionamento entre threads pode ser utilizado o
metodo Thread.join, como discutido anteriormente. A linguagem Java tambem
prove outros dois idiomas para sincronizacao que s
ao: metodos sincronizados e
statements sincronizadas.
Com os metodos sincronizados n ao e possvel realizar duas chamadas si-

mult aneas do metodo sobre um unico objeto. Quando uma thread est a execu-
tando um metodo sincronizado sobre um objeto, todas as outras threads que
invocam metodos sincronizados para o mesmo objeto suspendem sua execuc ao
ate que a primeira thread libere o objeto. Alem disso, os metodos sincroniza-
dos estabelecem automaticamente uma relac ao de happens-before com todas as
chamadas subsequentes de metodos sincronizados. Isso garante que a as mu-
dancas no estado do objeto estarao visveis para todas as threads.
public class SynchronizedCounter {
179
private int c = 0;
//M
etodos sincronizados para manipular um contador
public synchronized void increment() {c++;}
public synchronized void decrement() {c--;}
public synchronized int value() {return c;}
Ao contr ario dos metodos sincronizados, as statements sincronizadas devem

especficar para qual objeto devera ser obtido o lock. Essa tecnica pode ser u
til
quando e implementar concorrencia com uma granularidade mais fina. Uma
exemplo de c odigo para criac
ao de statements sincronizadas e mostrado abaixo:
public class MsLunch {
private long c1 = 0;
private long c2 = 0;
private Object lock1 = new Object();
private Object lock2 = new Object();
public void inc1() {

//Lock somente sobre o objeto lock1
synchronized(lock1) {c1++;}
}
public void inc2() {

//Lock somente sobre o objeto lock2
synchronized(lock2) {c2++;}
}
}
16.2.6 Executores e Thread Pools

Nos exemplos mostrados, existe uma conex ao direta entre a tarefa executada
por uma nova thread, como definida no objeto Runnable, e a nova thread em
sim, definida por um objeto Thread. Isso funciona bem para aplicac oes pe-
quenas. Em aplicacoes de grande porte e mais apropriado separar a criac ao e
gerenciamento da threads do resto da aplicac ao. Os objetos que encapsulam as

func
oes de gerenciamento de threads sao chamados executores (executors).
O pacote java.util.concurrency define tres interfaces executoras que s
ao Ex-
ecutor, ExecutorService e ScheduledExecutorService. Essas interfaces definem
metodos para gerenciamento de threads na aplicac ao. Exemplo: Se r e um
objeto do tipo Runnable, e e e um objeto do tipo Executor o trecho de c odigo
(new Thread(r)).start();
poderia ser substitudo por
e.execute(r);
180
Na primeira forma, uma nova thread seria criada para realizar a tarefa
definida em r, enquanto na segunda, isso dependeria da implementac
ao da in-
terface executora.
Geralmente, as interfaces executoras sao criadas utilizando as chamadas

ThreadPools, que consistem de um conjunto de threads (worker threads) re-
spons
aveis pela execuc
ao das tarefas. Quando o metodo execute e chamado
sobre o objeto r, uma worker thread e alocada para rodar a tarefa definida em
r. Caso n
ao exista nenhuma worker thread disponvel no momento, r e colocada
em uma fila de espera ate que uma worker thread seja liberada.
Usando pools de threads e possvel minimizar o overhead de criac ao de

threads e otimizar o gerenciamento de memoria, uma vez que e possvel definir o
n
umero m aximo de threads no pool de acordo com as necessidades da aplicac ao
e quantidade de recursos do sistema.
16.3 Streams e Serializa

cao
16.3.1 I/O Streams
Um I/O stream pode representar diferentes tipos de fonte e destino, incluindo
arquivos em discos, dispositivos, outros programas e mem oria. Os streams su-
portam diversos tipos de dados, como simples bytes, tipos de dados primitivos e
ate mesmo objetos complexos. Alguns streams simplesmente passam os dados,
enquanto outros realizam algum tipo de manipulacao e transformac
ao conforme
necess
ario. A seguir ser
ao mostrados alguns exemplos da utilizac
ao de streams.
Streams de Bytes
Byte streams s ao utilizados para realizar input e output de bytes. Todas

as classes byte stream herdam de InputStream e outputStream. Os streams de
bytes representam o nvel mais baixo que pode ser alcancado, e devem evita-
dos. Todas as outras classes de stream s ao construdas com base na operac
oes
definidas pelas classes de byte stream.
//Exemplo 1: Stream de Bytes

//Copia o arquivo xanadu.txt para outagain.txt byte a byte.
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
public class CopyBytes {

public static void main(String[] args) throws IOException {
FileInputStream in = null;
FileOutputStream out = null;
try {
in = new FileInputStream("xanadu.txt");
out = new FileOutputStream("outagain.txt");
181
int c;
while ((c = in.read()) != -1) {
out.write(c);
}
} finally {
if (in != null) {in.close();}
if (out != null) {out.close();}
}
}
}
Streams de Caracteres
A plataforma java armazena os valores dos caracteres utilizando a convec

ao
Unicode. As operac
oes de com streams de caracteres automaticamente con-
vertem do formato Unicode para o formato local.
//Exemplo 1: Stream de Caracteres

//Copia o arquivo xanadu.txt para characteroutput.txt caracter e caracter
import java.io.FileReader;
import java.io.FileWriter;
public class CopyCharacters {

FileReader inputStream = null;
FileWriter outputStream = null;
try {
inputStream = new FileReader("xanadu.txt");
outputStream = new FileWriter("characteroutput.txt");
int c;
while ((c = inputStream.read()) != -1) {
outputStream.write(c);
}
} finally {
if (inputStream != null) {inputStream.close();}
if (outputStream != null) {outputStream.close();}
}
}
}
No entanto, I/O de caracteres geralmente ocorrem linha a linha. Uma linha

e um conjunto de caracteres terminada por um caracter especial de fim de linha.
O codigo a seguir executa a mesma tarefa do exemplo 1, porem copia o arquivo
linha a linha e utiliza estrategias de buffering.
//Exemplo 2: Stream de Caracteres linha a linha

//Copia o arquivo xanadu.txt para characteroutput.txt linha a linha
import java.io.FileReader;
182
import java.io.FileWriter;
import java.io.BufferedReader;
import java.io.PrintWriter;
public class CopyLines {

BufferedReader inputStream = null;
PrintWriter outputStream = null;
try {
inputStream = new BufferedReader(new FileReader("xanadu.txt"));
outputStream =new PrintWriter(new FileWriter("characteroutput.txt"));
String l;
while ((l = inputStream.readLine()) != null) {
outputStream.println(l);
}
} finally {
if (inputStream != null) {inputStream.close();}
if (outputStream != null) {outputStream.close();}
}
}
}
No exemplo 1 o c
odigo utiliza operac
oe de I/O n
ao bufferizadas. Isso significa
que a cada requisic
ao de leitura ou escrita expressa no c odigo e prontamente
tratada pelo sistema operacional, disparando, por exemplo, acesso ao disco ou
a rede.
`
Para reduzir esse tipo de overhead a plataforma Java implementa I/O streams
bufferizados. Os input streams leem dados de uma area de buffer; a API in-
put nativa so e chamada quando esse buffer est a vazio ou n
ao contem os dados
procurados. Similarmente, os output streams escrevem dados para uma area de
buffer, enquanto a API nativa de output s o e chamada quando o buffer de es-
crita est
a cheio ou quando algum comando que implique no flushing e utilizado,
por exemplo, println.
16.3.2 Serializa
c
ao - Streams de Objetos
Os streams apresentados ate agora s ao chamados data streams. Assim como
os data streams suportam I/O de tipos primitivos de dados, os object streams

suportam I/O para objetos. A maioria das classes padr ao do java suportam
a serializac
ao de seus objetos. Para que uma objetos de uma classe possam
ser serializados a classe deve implementar a interface Serializable. A interface
Serializable nao define metodos ou atributos, servindo apenas para indicar que
uma classe e serializ
avel.
As classes de streams de objetos sao ObjectInputStream e ObjectOutput-

Stream. Essas classes implementam as interfaces ObjectInput e ObjectOutput,
que por sua ve s
ao subitnerfaces de DataInput and DataOutput. Isso significa
dizer que todos os metodos para I/O de tipos de dados primitivos tambem s
ao
183
implementados nas classes de stream para objetos. A seguir, um exemplo sim-

ples para serializac
ao de objetos em Java.
import java.io.*;
public class Pessoa implements Serializable{
public String nome = "Maria";

public int idade = 30;
public String sexo = "feminino";
public Pessoa (String p_nome, int p_idade, String p_sexo){

nome = p_nome;
idade = p_idade;
sexo = p_sexo;
}
public static void main (String [] args){
Pessoa p = new Pessoa("Maria",10,"feminino");
try {
// Serializa o objeto para um arquivo
ObjectOutput out = new ObjectOutputStream(
new FileOutputStream("pessoa.ser")
);
out.writeObject(p);
out.close();
// Desserializa o objeto a partir do arquivo

File file = new File("pessoa.ser");
ObjectInputStream in = new ObjectInputStream(
new FileInputStream(file)
);
Pessoa clone = (Pessoa) in.readObject();
in.close();
// Testa um atributo do novo objeto clone

System.out.println("Nome de p: " + p.nome);

System.out.println("Nome do clone de p: " + clone.nome);
}catch (IOException e) {
//Pode ser gerado na serializac~
ao ou desserializa
c~ao
System.out.println(e.getMessage());
}catch (ClassNotFoundException e) {
//Pode ser gerado desserializac~
ao
}
}
184
Embora as classes ObjectInputStream e ObjectOutputStream sejam sufi-

cientes para serializar e desserializar a maioria dos objetos no Java, ela possui
o incoveniente de utilizar arquivos bin arios, o que dificulta a leitura direta por
um usu ario ou por outras aplicacoes (escritas em outras linguagens, por exem-
plo). Muitas aplicac
oes realiz
ao serializac
ao com arquivos XML, o que permite
contornar os problemas da legibilidade e integrac ao mais facilmente.
Existem in umeros pacotes para serializac

ao de objetos em arquivos XML.
Quando se est a trabalhando com java beans, por exemplo, duas classes muito
utilizadas para serializac
ao de objetos em XML s ao java.beans.XMLEncoder e
java.beans.XMLDecoder. A seguir, um trecho de c odigo exemplificando o uso
dessas classes.
PessoaXML p = new PessoaXML("Maria",10,"feminino");
// Serializa o objeto para um arquivo XML

XMLEncoder e = new XMLEncoder(
new BufferedOutputStream(
new FileOutputStream("pessoa.xml")));
e.writeObject(p);
e.close();
// Desserializa o objeto a partir do arquivo XML

XMLDecoder d = new XMLDecoder(
new BufferedInputStream(
new FileInputStream("pessoa.xml")));
PessoaXML clone = (PessoaXML) d.readObject();
d.close();
16.4 Classes e Opera

coes de I/O
16.5 Classes para manipula
cao de propriedades
Boa parte das aplicac

oes necessitam de algum tipo de configurac
ao adicional que
n
ao pode ser embutida diretamente no c odigo. Em java, uma forma tradicional
de se fazer isso envolve a utilizac
ao ddos chamados arquivos de propriedades,
que podem ser manipulados a partir da classe java.util.Properties, que e uma
extens
ao da classe java.util.Hashtable.
Um arquivo de propriedades guarda conjunto de pares nome/valor, que po-

dem ser lidos ou alterados. O formato tpico de um arquivo de propriedades e
motrado a seguir:
185
#Esta
e uma linha de comentario
#Mon Jun 11 22:37:16 BRT 2007
app.diretorio=/zaz/traz/bin
app.usuario=camatchones
app.mododeoperacao=producao
E a seguir e mostrado um exemplo de c

odigo Java para manipulac
ao de um
arquivo de propriedades.
import java.util.Properties;
import java.io.*;
public class Exemplo {
public Exemplo (){}
public static void main (String [] args){

try{
// Cria e le os valores padrao para um objeto Propertie
Properties defaultProps = new Properties();
FileInputStream in = new FileInputStream("exemplo.properties");
defaultProps.load(in);
in.close();
// Utilizacao as propriedades quando precisarmos

String diretorio = defaultProps.getProperty("app.diretorio");
String usuario = defaultProps.getProperty("app.usuario");
// Modificamos/Criando valores das propriedades

if (usuario.equals("joao")){
defaultProps.setProperty("app.dataDir", "/home/joao");
defaultProps.setProperty("app.nova_configuracao", "12345");
}
// Salvamos para uma proxima execussao

FileOutputStream out = new FileOutputStream("exemplo.properties");
defaultProps.store(out, "Isso
e um coment
ario!");
out.close();
}catch(Exception e){
}
}
}
Uma observacao importante e que o metodo getProperty sempre retorna

uma String, de modo que se uma propriedade e de algum outro tipo, essa deve
ser convertida no momento da leitura.
Atualmente o uso de arquivos XML para armazenamento de configurac

oes
186
vem ganahando popularidade, no entanto, os arquivos de propriedades contin-

uam ser uma forma simples e eficaz de gerenciar configuracoes simples.
187
Captulo 17
Colec
oes
Uma colec ao e simplesmente um grupo de objetos em uma u nica unidade. As

colec
oes s
ao usadas para armazenar, recuperar, manipular e comunicar dados
agregados. Tipicamente, representam itens de dados que d ao forma a um grupo
natural, tal como uma m ao do poker (uma colec
ao dos cart
oes) e uma pasta de
correspondencia (uma colecao das letras).
Uma framework de colec oes e uma arquitetura unificada para representac

ao e
manipulac
ao das colec
oes, permitindo que elas sejam manipuladas independen-
temente dos detalhes de sua implementac ao. Todos os frameworks de colec oes
contem:
Interfaces: Estes s ao os tipos de dados abstratos que representam as

colec
oes. As interfaces permitem que as colec
oes sejam manipuladas inde-
pendentemente dos detalhes de sua representac ao. Em linguagem orien-
tadas ` a objeto as interfaces d
ao forma geralmente a uma hierarquia;
Implementac oes: Estas s
ao as implementacoes concretas das relac
oes da
colec
ao. Essencialmente, sao estruturas de dados reus
aveis;
Algoritmos: Estes s ao os metodos que executam computac oes u
teis, tais
como procurar e ordenar objetos de uma determinada colec ao. Os algorit-
mos s
ao polimorficos, isto e, o mesmo metodo pode ser usado em diferentes
implementac
oes.
As principais vantagens do framework de colec

oes (collection framework)
s
ao:
Reducao do esforco de programac

ao, fornecendo estruturas de dados e
algoritmos u
teis, para que n
ao seja necess
ario reescreve-los;
Aumento da performance: fornecendo implementac oes de alta perfor-
mance. Como as varias implementac
oes de cada interface s
ao substituveis,
os programas podem ser facilmente refinados trocando-se as implementac oes;
Interoperabilidade entre APIs n

ao relacionadas, estabelecendo uma lin-
guagem comum para passagem de colec oes;
188
Reduc
ao do esforco de aprendizado de APIs, eliminando a necessidade de
se aprender v
arias APIs de colec
oes diferentes;
Reduc
ao do esforco de projetar e implementar APIs, eliminando a neces-
sidade de se criar APIs de colec
oes pr
oprias;
Promover o re uso de software, fornecendo uma interface padr

ao para
colec
oes e algoritmos para manipula-los.
As colec oes s
ao necess
arias, devido o uso dos arrays possuir uma serie de
limitac
oes, como por exemplo:
Um array n
ao pode ter o tamanho modificado depois de criado;
Somente pode conter elementos de um mesmo tipo;
Para inserir ou retirar um elemento e necess

ario modificar a posic
ao de
outros elementos.
Figura 17.1: Interfaces Collection
17.1 Interface Collection

Interface base para todos os tipos de colec ao. Ela define as operacoes mais
b
asicas para colec oes de objetos, como adic ao (add) e remoc
ao (remove) ab-
stratos (sem informac oes quanto ` a ordenacao dos elementos), esvaziamento
(clear), tamanho (size), convers ao para array (toArray), objeto de iterac
ao (it-
erator), e verificac
oes de existencia (contains e isEmpty). A seguir e mostada a
Interface Collection:
public interface Collection<E> extends Iterable<E> {

// Basic operations
int size();
boolean isEmpty();
boolean contains(Object element);
boolean add(E element); //optional
boolean remove(Object element); //optional
// Bulk operations
boolean containsAll(Collection<?> c);
boolean addAll(Collection<? extends E> c); //optional
189
boolean removeAll(Collection<?> c); //optional

boolean retainAll(Collection<?> c); //optional
void clear(); //optional
// Array operations
Object[] toArray();
<T> T[] toArray(T[] a);
17.2 Interface Set

Interface que define uma colec ao, ou conjunto, que nao contem objetos dupli-
cados. Isto e, s
ao ignoradas as adic
oes caso o objeto ou um objeto equivalente
j
a exista na colec
ao. Por objetos equivalentes, entenda-se objetos que tenham
o mesmo c odigo hash (retornado pelo metodo hashCode()) e que retornem ver-
dadeiro na comparac ao feita pelo metodo equals().
Nao e garantida a ordenac ao dos objetos, isto e, a ordem de iterac

ao dos
objetos nao necessariamente tem qualquer relac ao com a ordem de insercao dos
objetos. Por isso, nao e possvel indexar os elementos por ndices numericos,
como em uma List. A seguir e mostada a Interface Set:
public interface Set<E> extends Collection<E> {
// Basic operations
int size();
boolean isEmpty();
boolean contains(Object element);
boolean remove(Object element); //optional
// Bulk operations
boolean containsAll(Collection<?> c);
boolean addAll(Collection<? extends E> c); //optional
boolean removeAll(Collection<?> c); //optional
boolean retainAll(Collection<?> c); //optional

void clear(); //optional
// Array Operations
Object[] toArray();
<T> T[] toArray(T[] a);
Existem 3 implementac
oes da interface Set:
190
HashSet: Implementac ao de Set que utiliza uma tabela hash para guardar
seus elementos. N ao garante a ordem de iterac
ao, nem que a ordem per-
manecer a constante com o tempo (uma modificac ao da colec
ao pode al-
terar a ordenac
ao geral dos elementos). Por utilizar o algoritmo de tabela
hash, o acesso e r
apido, tanto para leitura quanto para modificac
ao.
LinkedHashSet: Implementac ao de Set que estende HashSet, mas adi-
ciona previsibilidade ` a ordem de iterac
ao sobre os elementos, isto e, uma
iterac
ao sobre seus elementos (utilizando o Iterator) mantem a ordem de
inserc
ao (a inserc
ao de elementos duplicados nao altera a ordem anterior).
Internamente, e mantida uma lista duplamente encadeada que mantem
esta ordem. Por ter que manter uma lista paralelamente ` a tabela hash, a
modificacao deste tipo de colec
ao acarreta em uma leve queda na perfor-
mance em relac ao ` a HashSet, mas ainda e mais r
apida que uma TreeSet,
que utiliza comparac oes para determinar a ordem dos elementos.
TreeSet: Implementacao de SortedSet. SortedSet e uma interface que es-

tende Set, adicionando a sem antica de ordenac
ao natural dos elementos.
A posic
ao dos elementos no percorrimento da colec ao e determinado pelo
retorno do metodo compareTo(o), caso os elementos implementem a inter-
face Comparable, ou do metodo compare(o1,o2) de um objeto auxiliar que
implemente a interface Comparator. A TreeSet utiliza internamente uma
TreeMap, que por sua vez utiliza o algoritmo Red-Black para a ordenac ao
da
arvore de elementos. Isto garante a ordenac
ao ascendente da colec
ao, de
acordo com a ordem natural dos elementos, definida pela implementac ao
da interface Comparable ou Comparator. Use esta classe quando precisar
de um conjunto (de elementos u nicos) que deve estar sempre ordenado,
mesmo sofrendo modificac oes.
A seguir s
ao mostrados alguns exemplos:
import java.util.*;
public class FindDups {

Set<String> s = new HashSet<String>();
for (String a : args)
if (!s.add(a))
System.out.println("Duplicate detected: " + a);

System.out.println(s.size() + " distinct words: " + s);
}
Rodando o programa:
prompt#> java FindDups i came i saw i left
A sa
da produzida ser
a:
191
Duplicate detected: i
4 distinct words: [i, left, saw, came]
O tipo de implementac ao Set no exemplo anterior e HashSet, que como dito

anteriormente nao faz nenhuma garantia a respeito da ordem dos elementos no
Set. Caso seja necessario imprimir a lista em ordem alfabetica basta mudar o
tipo de implementacao de HashSet para TreeSet. A nova sada do programa
anterior para TreeSet seria a seguinte:
Rodando o programa:
A sa
da produzida ser
a:
4 distinct words: [came, i, left, saw]
Caso fosse utilizado uma LinkedHashSet a sada seria a seguinte:
Rodando o programa:
A sa
da produzida ser
a:
4 distinct words: [i, came, saw, left]

E agora um outro exemplo, modificando a classe FindDups:
import java.util.*;
public class FindDups2 {

Set<String> uniques = new HashSet<String>();
Set<String> dups = new HashSet<String>();
for (String a : args)
if (!uniques.add(a))
192
dups.add(a);
// Destructive set-difference
uniques.removeAll(dups);
System.out.println("Unique words: " + uniques);
System.out.println("Duplicate words: " + dups);
}
Executando o c odigo anterior com os mesmos argumentos dos programas

anteriores (i came i saw i left) a sada deste programa seria:
Unique words: [left, saw, came]
Duplicate words: [i]
Ha duas implementac
oes Set com finalidades especiais: EnumSet e CopyOn-
WriteArraySet.
17.3 Interface List

Interface que extende Collection, e que define colec
oes ordenadas (seq uencias),
onde se tem o controle total sobre a posic
ao de cada elemento, identificado por
um ndice numerico. Na maioria dos casos, pode ser encarado como um array
de tamanho vari avel, pois, como os arrays primitivos, e acessvel por ndices,
mas alem disso possui metodos de insercao e remocao. A seguir e mostada a
Interface List:
public interface List<E> extends Collection<E> {
// Positional access
E get(int index);
E set(int index, E element); //optional
void add(int index, E element); //optional
E remove(int index); //optional
boolean addAll(int index,
Collection<? extends E> c); //optional
// Search
int indexOf(Object o);
int lastIndexOf(Object o);
// Iteration
ListIterator<E> listIterator();
ListIterator<E> listIterator(int index);
// Range-view
List<E> subList(int from, int to);
193
oes da interface List:
ArrayList: Implementac ao de List que utiliza internamente um array de

objetos. Em uma inserc ao onde o tamanho do array interno n ao e su-
ficiente, um novo array e alocado (de tamanho igual a 1.5 vezes o ar-
ray original), e todo o conte udo e copiado para o novo array. Em uma
inserc
ao no meio da lista o conte udo posterior ao ndice e deslocado em
uma posic ao. Esta implementac ao e a recomendada quando o tamanho
da lista e previsvel (evitando realocacoes) e as operac
oes de insercao e
remocao s
ao feitas, em sua maioria, no fim da lista (evitando deslocamen-
tos), ou quando a lista e mais lida do que modificada (otimizado para
leitura aleatoria).
LinkedList: Implementac ao de List que utiliza internamente uma lista

encadeada. A localizac ao de um elemento na n-esima posic ao e feita
percorrendo-se a lista da ponta mais pr oxima ate o ndice desejado. A
insercao e feita pela adic
ao de novos n os, entre os nos adjacentes, sendo
que antes e necess aria a localizac
ao desta posicao. Esta implementac ao e
recomendada quando as modificac oes s
ao feitas em sua maioria tanto no
incio quanto no final da lista, e o percorrimento e feito de forma seq uen-
cial (via Iterator) ou nas extremidades, e n ao aleatoria (por ndices). Um
exemplo de uso e como uma fila (FIFO - First-In-First-Out), onde os ele-
mentos s ao retirados da lista na mesma seq uencia em que s
ao adicionados.
A seguir s
import java.util.*;
public class ExemploArrayList {

List c = new ArrayList();
c.add("Maria");
c.add("Joao");
c.add("Ana");
c.add("Joao");
c.add("Jose");
Iterator i = c.iterator();
while( i.hasNext() ) {
System.out.print( i.next() + " " );
}
System.out.println();
System.out.println(c.get(2));
System.out.println(c);
}
194
A sada produzida ser

a:
Maria Joao Ana Joao Jose

Ana
[Maria, Joao, Ana, Joao, Jose]
ArrayList e LinkedList tem algumas diferencas, entre elas temos os metodos

addFirst, addLast, getFirst, getLast, removeFirst e removeLast para LinkedList
que inserem, retornam e retiram um elemento no inicio ou no fim de uma lista
, com estes metodos podemos simular pilhas e filas.
Ha uma implementac
ao List com finalidades especiais: CopyOnWriteAr-
rayList.
17.4 Interface Map

Interface que define um array associativo, isto e, ao inves de n
umeros, objetos
s
ao usados como chaves para se recuperar os elementos. As chaves n ao podem se
repetir (seguindo o mesmo princpio da interface Set), mas os valores podem ser
repetidos para chaves diferentes. Um Map tambem n ao possui necessariamente
uma ordem definida para o percorrimento. A seguir e mostada a Interface Map:
public interface Map<K,V> {
// Basic operations
V put(K key, V value);
V get(Object key);
V remove(Object key);
boolean containsKey(Object key);
boolean containsValue(Object value);
int size();
boolean isEmpty();
// Bulk operations
void putAll(Map<? extends K, ? extends V> m);
void clear();
// Collection Views
public Set<K> keySet();

public Collection<V> values();
public Set<Map.Entry<K,V>> entrySet();
// Interface for entrySet elements

public interface Entry {
K getKey();
V getValue();
V setValue(V value);
}
195
oes da interface Map:
HashMap: Implementac ao de Map que utiliza uma tabela hash para ar-
mazenar seus elementos. O tempo de acesso aos elementos (leitura e mod-
ificac
ao) e constante (muito bom) se a func
ao de hash for bem distribuda,
isto e, a chance de dois objetos diferentes retornarem o mesmo valor pelo
metodo hashCode() e pequena.
TreeMap: Implementacao de SortedMap. SortedMap e uma Interface que

estende Map, adicionando a sem antica de ordenac
ao natural dos elemen-
tos, analogo `
a SortedSet. Tambem adiciona operac oes de partic
ao da
colec
ao, com os metodos headMap(k) - que retorna um SortedMap com
os elementos de chaves anteriores a k -, subMap(k1,k2) - que retorna um
SortedMap com os elementos de chaves compreendidas entre k1 e k2 - e
tailMap(k) - que retorna um SortedMap com os elementos de chaves poste-
riores a k. A TreeMap utiliza o algoritmo Red-Black para a ordenac ao da
arvore de elementos. Isto garante a ordenac
ao ascendente da colec
ao, de
acordo com a ordem natural dos elementos, definida pela implementac ao
da interface Comparable ou Comparator. Use esta classe quando precisar
de um conjunto (de elementos u nicos) que deve estar sempre ordenado,
mesmo sofrendo modificacoes.
LinkedHashMap: Implementac ao de Map que estende HashMap, mas adi-

ciona previsibilidade ` a ordem de iterac
ao sobre os elementos, isto e, uma
iterac
ao sobre seus elementos (utilizando o Iterator) mantem a ordem de
inserc
ao (a inserc
ao de elementos duplicados nao altera a ordem anterior).
Internamente, e mantida uma lista duplamente encadeada que mantem
esta ordem. Por ter que manter uma lista paralelamente ` a tabela hash, a
modificacao deste tipo de colec
ao acarreta em uma leve queda na perfor-
mance em relac ao à HashMap, mas ainda e mais rapida que uma TreeMap,
que utiliza comparac oes para determinar a ordem dos elementos.
A seguir s
import java.util.*;
public class Freq {


Map<String, Integer> m = new HashMap<String, Integer>();
// Initialize frequency table from command line
for (String a : args) {
Integer freq = m.get(a);
m.put(a, (freq == null) ? 1 : freq + 1);
}
System.out.println(m.size() + " distinct words:");
System.out.println(m);
}
196
Rodando o programa:
prompt#> java Freq if it is to be it is up to me to delegate
A sa
da produzida ser
a:
8 distinct words:
{to=3, delegate=1, be=1, it=2, up=1, if=1, me=1, is=2}
Caso fosse usado uma TreeMap ao inves de HashMap a sada seria:
8 distinct words:
{be=1, delegate=1, if=1, is=2, it=2, me=1, to=3, up=1}
E caso fosse utilizado LinkedHashMap a sada seria:
8 distinct words:
{if=1, it=2, is=2, to=3, be=1, up=1, me=1, delegate=1}
H
a duas implementac
oes Map com finalidades especiais: EnumMap, WeakHashMap
e IdentityMap.
17.5 Interface Queue

Uma queue e uma colec ao para prender elementos antes de processarem. Alem
das operacoes b
asicas da colecao, as filas fornecem a inserc
ao, a remoc
ao e
operac
oes adicionais de inspec
ao. A seguir e mostrada a Interface Queue:
public interface Queue<E> extends Collection<E> {
E element();
boolean offer(E e);
E peek();
E poll();
E remove();
Queue tipicamente, mas n ao necessariamente, manipulam os elementos como

uma FIFO (first-in-first-out). Entre as excecoes estao as priority queues (filas
com prioridades), que requisitam elementos de acordo com algum de seus val-
ores.
O primeiro elemento da fila (cabeca da fila) e o elemento que seria removido
pela chamada do metodo remove ou poll. Em uma queue do tipo FIFO, todos
os elementos novos sao introduzidos no final da fila. Outros tipos de queue
197
podem usar regras diferentes de colocac ao. Cada implementac ao de queue deve
especificar suas propriedades.
possvel que algumas implementac
E oes de queue restrinja o numero de el-
ementos que prende; tais filas s ao conhecidas como limitadas. Algumas im-
plementacoes de queue em java.uitl.concurrent s ao limitadas, mas as imple-
mentacoes em java.util nao sao.
As implementac oes da queue geralmente n ao permitem a inserc
ao de elemen-
tos nulos. A implementac ao de LinkedList, que foi adaptada para implementar
uma queue, e uma excec ao.
A seguir e mostrado um exemplo:
import java.util.*;
public class Countdown {
public static void main(String[] args) throws InterruptedException {

int time = Integer.parseInt(args[0]);
Queue<Integer> queue = new LinkedList<Integer>();
for (int i = time; i >= 0; i--)
queue.add(i);
while (!queue.isEmpty()) {
System.out.println(queue.remove());
Thread.sleep(1000);
}
}
A classe PriorityQueue e uma fila de prioridade baseada na estrutura de

dados heap. Esta fila requisita elementos de acordo com uma ordem especificada
no tempo da construc ao.
A interface queue e estendida pela BlockingQueue. Algumas implementacoes
de BlockingQueue s ao: LinkedBlockingQueue, ArrayBlockingQueue, Priority-
BlockingQueue, DelayQueue e a SynchronousQueue.
198
Captulo 18
JDBC - Java Database

Connectivity
18.1 Conceitos B
asicos
Java Database Connectivity ou JDBC e um conjunto de classes e interfaces
(API) escritas em Java que faz o envio de instruc
oes SQL para qualquer banco
de dados relacional.
API de baixo nvel e base para APIs de alto nvel;

Amplia o que voce pode fazer com java;
Possibilita o uso de banco de dados j

a instalados;
Para cada banco de dados h
a um driver JDBC que pode cair em quatro
categorias.
As 4 categorias de driver s
ao:
TIPO 1: PONTE JDBC-ODBC E o tipo mais simples mas restrito à

plataforma Windows. Utiliza ODBC para conectar-se com o banco de
dados, convertendo metodos JDBC em chamadas ` as func
oes do ODBC.
Esta ponte e normalmente usada quando nao h
a um driver puro-java (Tipo
4) para determinado banco de dados, pois seu uso e desencorajado devido
a dependencia de plataforma.
`
TIPO 2: DRIVER API-NATIVO O driver API-Nativo traduz as chamadas

JDBC para as chamadas da API cliente do banco de dados usado (Oracle,
Sybase, Informix, DB2, ou outro SGBD). Como a ponte JDBC-ODBC,
pode precisar de software extra instalado na m
aquina cliente.
TIPO 3: DRIVER DE PROTOCOLO DE REDE Traduz a chamada
JDBC para um protocolo de rede independente do banco de dados uti-
lizado, que e traduzido para o protocolo do banco de dados por um servi-
dor. Por utilizar um protocolo independente, pode conectar as aplicac
oes
java a v o modelo mais flexvel.
arios banco de dados diferente. E
199
TIPO 4: DRIVER NATIVO Converte as chamadas JDBC diretamente

no protocolo do banco de dados. Implementado em java, normalmente e
independente de plataforma e escrito pelos pr o
oprios desenvolvedores. E
tipo mais recomendado para ser usado.
Figura 18.1: Tipos de Drivers JDBC
Como mostrado na figura 18.1 a aplicac

ao java chama a biblioteca JDBC.
Posteriormente o JDBC carrega um driver para que se comunique com a base
de dados.
18.2 Carregamento de drivers

Depois de iniciar o programa e importar os pacotes necess
arios (import java.sql.*),
devemos seguir certos passos para que seja possvel o acesso ao SGBD. De-
vemos inicialmente carregar o driver e depois criar a conex ao propriamente
dita. A carga do driver e muito simples. Basta invocar o metodo est atico:
Class.forName(jdbc.XYZ). Exemplo:
try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); //Or any other driver
}catch(Exception x){
System.out.println( "Unable to load the driver class!" );
}
A classe Class tem como func
ao instanciar a classe identificada entre parenteses
e registr
a-la com a JVM, que ir a utiliz
a-la para acessar o SGBD. Em nosso ex-
emplo, utilizamos a ponteODBC-JDBC. A Class e uma classe no pacote de
java.lang.
18.3 Conex
ao
Feito o carregamento dos drivers, o proximo passo e o estabelecimento da
conexao. Tipicamente uma aplicac
ao JDBC conecta ao banco de dados usando
200
um dos seguintes mecanismos:
DriverManager: Esta implementac ao requer que uma aplicacao carregue

um driver especfico, usando uma URL hardcoded. Como parte de sua
inicializac
ao, a classe DriverManager tenta carregar as classes do driver
referenciado. Isto permite que voce customize os drivers de JDBC usados
por suas aplicacoes.
DataSource: Esta interface e preferida sobre a DriverManager porque per-
mite que os detalhes sobre a origem dos dados sejam transparentes a sua
aplicac
ao. As propriedades de um objeto de DataSource s ao ajustadas de
modo que represente uma origem particular de dados.
Para abrirmos uma conex ao, normalmente teremos que entrar em contato
com o SGBD. A linha mostrada abaixo d
a a ideia geral de como e feita `
a conex
ao
atraves do mecanismo DriverManager:
try{
Connection con = DriverManager.getConnection(url,"user", "password");
}catch( SQLException x ){
System.out.println( "Couldnt get connection!" );
}
A parte mais complexa e montar a url. Esta parte da informac ao sempre

se inicia com jdbc: mas o resto depende do fabricante do banco. Na seq uencia
normalmente temos o nome do fabricante (ent ao temos jdbc:db2, jdbc:oracle,
jdbc:psql e etc) e por u
ltimo o nome da fonte de dados (ent
ao temos jdbc:db2:db,
jdbc:oracle:server.unicamp.br:1234/meubanco e etc).
O proximo exemplo mostra como seria o estabelecimento de conex ao atraves
de um DataSource.
InitialContext ic = new InitialContext()

DataSource ds = ic.lookup("java:comp/env/jdbc/myDB");
Connection con = ds.getConnection();
Toda parte envolvida com a conexao propriamente dita acontece de maneira

transparente. O programador n ao tem necessidade nenhuma de saber o que
se passa e, a n
ao ser que ele um dia resolva escrever seu pr
oprio driver para
conex
ao a algum SGBD, tem que se dar por satisfeito da coisa acontecer assim.
A partir de agora, o objeto con representa uma conex ao ativa e aberta ao
banco de dados e o programador pode utiliz a-lo para enviar statements SQL
para o banco.
18.4 Statements
necess
E ario criar um objeto da classe Statement para armazenar o pedido
que ser
a enviado ao SGBD. O programador deve simplesmente criar um objeto
deste tipo, informar a cadeia de strings que representa seu comando SQL e
depois executa-lo, usando metodos especiais dependendo do tipo de comando
desejado. Para um SELECT, usa-se o executeQuery. Para INSERT, UPDATE
e DELETE executeUpdate. Por exemplo:
201
Statement stmt = com.createStatement();

Neste ponto, um statement foi criado. Mas n
ao existe nenhum comando
SQL nele. Podemos executar um comando como no exemplo abaixo:
stmt.executeUpdate( "DELETE FROM Clientes WHERE CPF = " + cpf + "");
Note que existe uma estrutura de parenteses, sinais de concatenac
ao e aspas.
Esses sinais s
ao importantes e muitas vezes causam confus oes tremendas em
programas. Deve-se ter muito cuidado com eles, principalmente quando houver
vari
aveis do programa java misturadas ao SQL.
O metodo mais comum de ser utilizado e o executeQuery. Mas ele retorna
apenas dados. Assim, devemos ter outro tipo de classe que serve exclusivamente
para receber esses dados, de maneira que possamos fazer uso deles no proces-
samento. Essa classe e chamada ResultSet. E necessario instanciar um objeto
desta classe que receba o resultado do executeQuery. Veja o exemplo:
ResultSet rs = stmt.executeQuery("SELECT NOME, SOBRENOME, IDADE FROM PESSOA");
A partir de agora, tem-se um objeto chamado rs que armazena todos os
dados recebidos. Em linhas gerais, os programadores estabelecem um loop onde
fazer a leitura dos dados baseados em metodos presentes na classe ResultSet.
Esses metodos permitem andarpelos resultados e copiar os valores para outros
objetos.
...
String query = "SELECT NOME, IDADE FROM PESSOA";
ResultSet rs = stmt.executeQuery(query);
While(rs.next()){
String nome = rs.getString("NOME");
Int idade = rs.getInt("IDADE");
...
Para acessar os nomes e as idades corremos cada registro e acessamos os
valores de acordo com o tipo. O metodo next() movimenta o cursor para o
pr
oximo registro, tornando aquele registro o corrente. Podemos ent ao execu-
tar outros metodos. Note que o cursor inicialmente fica posicionado acima do
primeiro registro, exigindo uma primeira execuc
ao do next() para que possamos
processar o primeiro registro.
Utilizamos metodos cujo nome se iniciam com get para obter os dados das
colunas. Eles devem ser obtidos de acordo com o tipo (o cast pode ser efetuado,
quando houver possibilidade), e esses metodos permitem que apontemos as col-
unas pelo nome ou pelo ndice (seu n

umero, na hora em que foi recebida e n ao
na ordem da tabela original). Assim, o codigo anterior poderia ser:
String nome = rs.getString(1);
Int idade = rs.getInt(2);
Esta ultima abordagem tem uma melhor performance. Caso o programador
queira atualizar o atributo nome da quinta linha do resultSet poderia fazer da
seguinte maneira.
rs.absolute(5); //move o cursor para o quinto registro
rs.updateString("NOME", "Joao"); //altera o valor da coluna NOME
rs.updateRow(); //atualiza a coluna na tabela
202
18.5 Prepared Statements

` vezes e mais conveniente usar um objeto PreparedStatement para enviar
As
comandos sql para a base de dados. Este tipo especial de statement e derivado
da classe mais geral, Statement.
A principal diferenca e que o prepared statement contem n ao apenas um
comando SQL, mas sim um comando SQL pre-compilado. Isso significa que
quando o prepared statement e executado, o SGBD deve apenas rodar o co-
mando SQL sem ter que fazer sua compilac ao primeiro.
Os objetos PreparedStatements podem ser usados sem par ametros no co-
mando SQL, embora seja mais freq uente o uso com par ametros. A vantagem da
utilizac
ao de par
ametros e que voce pode fornecer valores diferentes ao mesmo
statement a cada vez que voce execut a-lo.
PreparedStatement pstmt = conn.prepareStatement("insert into TABLE values (?,?)");

pstmt.setString(1,arquivo.getName());
pstmt.setBinaryStream(2,inputStream,(int)arquivo.length());
pstmt.executeUpdate();
Note que voce pode possuir diversos tipos de campos diferentes, e nem por
isso precisa usar aspas duplas, aspas simples ou nenhuma aspas na hora de
passar os valores para serem incluidos/consultados/alterados no banco. Esta e
uma das principais vantagens de se usar PreparedStatement.
Lembre-se que a ordem dos sets dever ao ser dadas na mesma ordem que
foi inserido os sinais de interrogac
ao. A seguir e mostrada uma operac
ao de
UPDATE usando Statement e PreparedStatement.
//Usando Statement
Statement stmt = con.createStatement();

String sql = "UPDATE COFFEES SET SALES = 75 WHERE COF_NAME LIKE Colombian";
stmt.executeUpdate(sql);
//Usando Prepared Statement
PreparedStatement pstmt = con.prepareStatement(

"UPDATE COFFEES SET SALES = ? WHERE COF_NAME LIKE ?"
);
updateSales.setInt(1, 75);
updateSales.setString(2, "Colombian");
pstmt.executeUpdate();
18.6 Transac
ao
Existem situac
oes onde nao se deseja que uma instruc
ao tenha efeito a n
ao ser
que outras tambem tenham. Algumas situac oes necessitam que dados sejam
includos em mais de uma tabela para que sejam considerados consistentes. Ou
os dados estao presentes em todas as tabelas ou n
ao devem estar presentes em
nenhuma.
203
A tecnica utilizada para garantir esse tipo de consistencia e o uso de transac

oes.
Uma transac ao nada mais e do que statements que s ao executados juntos, como
uma coisa u nica: ou todos falham, ou todos s ao executados.
A primeira providencia e desabilitar o auto-commit. Quando uma conex ao
e criada, o padr ao e que ela trate cada executeUpdate como uma transac ao
separada, que e validada (commit) assim que e completada. Assim, devemos
utilizar o c
odigo:
con.setAutoCommit(false);
A partir daqui, nenhum statement ser a validado ate que o programador

permita. Todos eles serao agrupados e validados como um s o. Ao final do
processo (caso tudo tenha transcorrido de acordo com o esperado), executa-se:
con.commit();
Caso algo nao tenha dado certo, podemos executar o metodo rollback para
que todo o statement seja descartado.
con.rollback();
importante lembrar algumas coisas quando lidamos com a transac
E ao de
maneira manual. Os recursos de banco normalmente ficam presos, esperando
um commi() ou rollback(). Assim, se um programa tratar ou entrar em loop
(ou mesmo demorar muito) o acesso ao banco fica prejudicado. Existe ainda a
possibilidade de um dirty read, onde outro programa recupera dados do disco
que voce est
a alterando, mas ainda nao validou. Esse tipo de comportamento
pode ser evitado aumentando o nvel de isolamento entre transac
oes. Verifique
o metodo setTransactionIsolation() da classe Connection.
18.7 Informac
oes Complementares
Ocasionalmente, voce ira sentir necessidade de obter mais informac
oes sobre o
resultado de um SELECT ou mesmo sobre a tabela em quest ao. Pode-se obter
esses dados utilizando a classe ResultSetMetaData, que pode ser criada segundo
o exemplo:
ResultSet rs = stmt.executeQuery(query);
ResultSetMetaData meta = rs.get.MetaData();
A classe ResultSetMetaData lhe fornece informac oes acerca do n

umero de
colunas recebidas, o nome e o tipo das colunas, se alguma coluna aceita dados
nulos, campos de data etc. Alem disso fornece tambem informac oes sobre a
tabela com que estamos trabalhando. Abaixo segue um exemplo mais completo:
...
Statement stmt = conn.createStatement();
// Tabela a ser analisada

ResultSet rset = stmt.executeQuery("SELECT * from EMP ");
ResultSetMetaData rsmd = rset.getMetaData();
204
// retorna o numero total de colunas

int numColumns = rsmd.getColumnCount();
System.out.println("Total de Colunas = " + numColumns);
// loop para recuperar os metadados de cada coluna

for (int i=0; i<numColumns; i++) {
System.out.println("Nome da Coluna=" + rsmd.getColumnName(i + 1));
System.out.println(" Tipo=" + rsmd.getColumnType(i + 1) );
System.out.println(" Nome do Tipo=" + rsmd.getColumnTypeName(i + 1));
System.out.println(" Tamanho=" + rsmd.getColumnDisplaySize(i + 1));
System.out.println(" Casas Decimais=" + rsmd.getScale(i + 1));
}
18.8 Exemplo Extra

Abaixo segue um exemplo extra com os assuntos tratados neste captulo.
import java.sql.*;
public class Principal{
public static void main(String[] args) throws Exception

//carregando o driver
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
//estabelecendo a conex~
ao
Connection con = DriverManagerSet.getConnection("jdbc:obc:bd");
//criando statement
Statement stmt = con.createStatement();
//Executando a consulta
ResultSet rs = stmt.executeQuery("SELECT LOGIN, NOME FROM ATENDENTE");
//Percorrendo o resultset
While(rs.next()){
String login = rs.getString("LOGIN");
String nome = rs.getString("NOME");

System.out.println("LOGIN:"+login);
Systems.out.println("NOME:"+nome);
}
//Pegando terceiro registro do ResultSet e alterando seu LOGIN

rs.absolute(3);
rs.updateString("LOGIN", "jsilva");
rs.updateRow(); //atualiza a coluna na tabela
//desativando o auto commit
205
con.setAutoCommit(false);
//atualizando o segundo registro sem usar updateRow

rs.absolute(2)
stmt.executeUpdate(
"UPDATE FROM ATENDENTE SET LOGIN= "jsouza" WHERE NOME = "
+ rs.getString("NOME") + ""
);
//Varias outras opera

c~oes de UPDATE
...
//"commitando" todos os updates realizados de uma

unica vez
con.commit();
}
}
206
Captulo 19
A plataforma J2EE
A plataforma J2EE e uma soluc

ao baseada em componentes para projeto, de-
senvolvimento, montagem e disponibilizac
ao de aplicac
oes distribudas em am-
bientes corporativos. O J2EE oferece, entre outras tecnologias:
Modelo multi-camada de aplicac
oes distribudas (multi-tier );
Componentes Reutiliz
aveis;
Modelo de seguranca unificado;
Controle de transac
oes flexveis;
Suporte a servicos Web (web services).
No modelo multi-camada distribudo da arquitetura J2EE as seguintes car-
actersticas s
ao importantes:
Os componentes que comp
oem a aplicac
ao podem estar em diferentes
m
aquinas;
Suas localizac
oes dependem da camada a que pertence.
Tipicamente, as aplicac
oes J2EE s
ao divididas em 4 camadas que s
ao:
Cliente (client-tier );
Web (web-tier );
Neg
ocios (bussiness-tier );
Sistemas de Informac
ao (EIS-tier ).
As caractersticas mais comuns dos componentes J2EE s
ao o fato deles serem
unidades de software auto-contidas e a capacidade de comunicac ao com outros
componentes. O que distingue um componente J2EE de uma classe comum e o
fato deles poderem ser combinados para formar uma aplicac ao J2EE, alem de
serem disponibilizados, executados e gerenciados por um servidor J2EE, comu-
mente chamado de servidor de aplicac ao.
A tabela a seguir mostra exemplos de componentes J2EE e o seus respectivos

tipo e local de execuc
ao.
207
Figura 19.1: Arquitetura J2EE
Componente Tipo Local de Execuc

ao
Clientes da aplicac
ao e Applets Cliente J2EE Cliente
Servlets e P
aginas JSP Web Servidor
Enterprise Java Beans Negocios Servidor
Tabela 19.1: Componentes J2EE
19.1 Containers J2EE

Na arquitetura J2EE um container e um ambiente que fornece um conjunto
de servicos para os componentes. Um componente deve ser colocado em um
container apropriado para que possa ser executado. Um exemplo simples de
container e o Apache Tomcat, que na arquitetura J2EE funciona como um con-
tainer Web, fornecendo servicos para rodar p
aginas JSP e Servlets.
Algumas dos servicos prestados pelos containers podem ser configurados.

Exemplo deles s
ao:
Seguranca;
Gerenciamento de Transac
oes;
Busca de Nomes e Diret
orios utilizando JNDI (Java Naming and Directory
Interface);
Conectividade Remota entre clientes e EJBs;
No entanto, alguns dos servicos oferecidos pelos containers n ao podem ser

configurados, uma vez que contituem o n ucleo da arquitetura e conferem a
escalabilidade da soluc
ao. Exemplo de servicos n
ao configur
aveis s
ao:
Criac
ao de Destruic ao de EJBs e Servlets (Ciclo de Vida dos Compo-
nentes). S ao utilizados pools de componentes para atender as requisic
oes
dos usu arios. N ao e o programador instancia um componete no c odigo
do cliente, porem a criac ao efetiva do objeto acontece no servidor de
aplicac
ao, onde o componente existe e e executado de fato;
Acesso `
as APIs da plataforma;
208
Gerenciamento de conex oes com bancos de dados. Os servidores de aplicac

ao
implementam o conceito de pools de conex oes. O programador n ao pre-
cisa escrever o c
odigo para abertura e encerramento da conex ao, pois isso
e papel do servidor de aplicac
ao;
Persitencia do estado dos componentes.
19.2 Clientes J2EE

Na arquitetura J2EE existem basicamente dois tipos de clientes que s
ao:
Clientes Web: P aginas Web din amicas geradas por componentes Web
(JSP ou Servlets) e que s
ao exibidas no browser. Existe ainda os applets,
que s
ao pequenos clientes de aplicac
ao escritos em Java e que rodam na
JVM embutida no browser.
Clientes de Aplicacao: Permitem que o usu ario interaja com o servidor

de aplicac
ao atraves de interfaces mais complexas, geralmente feitas uti-
lizando as APIs Swing ao AWT (Abstract Window Toolkit).
importante ressaltar que toda a l
E ogica de neg
ocio e implementada pelos
EJBs, que rodam no servidor de aplicac
ao. Assim como os EJBs , os Servlets e
p
aginas JSP tambem est
ao em um servidor de aplicac ao, porem n
ao no mesmo
container.
Os Servlets sao classes Java que processam dinamicamente as requisic oes e

controem respostas na forma de p aginas HTML. As p aginas JSP permitem in-
serir c
odigo java diretamente em um documento HMTL, sendo apropriadas para
criar conte
udo din amico e, em geral, para descrever a l
ogica de apresentac
ao.
19.3 Um pouco mais sobre Servlets

Um servlet e uma classe java que extende as capacidades do servidor que aces-
sam aplicacoes num modelo de programa requisic ao e resposta. Os servlets,
como definidos na interface Servlet disponvel no pacote javax.servlet, s
ao in-
dependentes de protocolo, e definem os metodos que todos os servlets devem
implementar. Os servlets s ao especialmente populares no desenvolvimento de
aplicac
oes Web, cuja comunicac
ao e baseada no protocolo HTTP.
A classe HttpServlet, disponvel no pacote javax.servlet.http, implementa a

interface Servlet e prove a base para implementac
ao de aplicac
oes Web empre-
gando o protocolo HTTP.
Do ponto de vista do cliente, um servlet funciona atendendo uma requisic

ao
e gerando conte
udo dinamico em forma de p aginas web, em HTML por exemplo,
como resposta. O codigo a seguir exemplifica a criac
ao de um servlet.
209
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;
public class MyNameServlet extends HttpServlet

{
/**
* Method to receive get requests from the web server
* (Passes them onto the doPost method)
* @param req The HttpServletRequest which contains the
* information submitted via get
* @param res A response containing the required response
* data for this request
**/
public void doGet(HttpServletRequest req, HttpServletResponse res)

throws ServletException, IOException
{
doPost(req,res);
}
/**
* Method to receive and process Post requests from the web server
* @param req The HttpServletRequest which contains the information
* submitted via post
* @param res A response containing the required response data for this request
**/
public void doPost(HttpServletRequest req, HttpServletResponse res)

throws ServletException, IOException
{
//*****Read the value of the yourname parameter*****
String name=req.getParameterValues("yourname")[0];
//*****Construct a response in HTML*****

String reply="<HTML>\n"+
"<HEAD><TITLE>My Name Servlet Response</TITLE></HEAD>\n"+
"<BODY>\n"+
"<CENTER><BR><B>\n"+
"Hello "+name+"\n"+
"</B></CENTER>\n</BODY>\n</HTML>";
//*****Send the reply*****

res.setContentType("text/html");
PrintWriter out=res.getWriter();
out.println(reply);
out.close();
}
210
O servlet interpreta a informac

ao dos formulario HTML para gerar uma
p
agina, tambem HTML, como resposta ` a requisic
ao do cliente. O trecho a
seguir mostra o c
odigo HTML da p agina que contem o formul ario.
<HTML>
<HEAD><TITLE>My Name Servlet Demonstration</TITLE></HEAD>
<BODY>
<CENTER>
<FORM ACTION="/servlet/MyNameServlet" METHOD=POST>
Please Enter your name <INPUT TYPE=TEXT NAME="yourname">
<INPUT TYPE=SUBMIT VALUE=Submit>
</FORM>
</CENTER>
</BODY>
</HTML>
Enquanto o trecho de c odigo a seguir mostra a pagina HTML retornada

como resposta pelo servlet, supondo que o us
ario tenha digitado zazaza.
<HTML>
<HEAD><TITLE>My Name Servlet Response</TITLE></HEAD>
<BODY>
<CENTER><BR><B>
Hello zazaza
</B></CENTER>
</BODY>
</HTML>
19.3.1 Ciclo de Vida dos Servlets

O inicio do clico de vida de um servlet ocorre quando o administrador do sis-
tema inicia uma aplicacao baseada em um servlet. Nesse momento, o container
responsavel pelos servlets no servidor de aplicac
ao cria uma inst ancia de um
servlet. O container tambem passa os par ametros de inicializacao do servlet
atraves do metodo init. Os parametros de inicializac
ao persistem ate o servlet
ser destrudo.
Se o processo de incializacao ocorrer com sucesso, o servlet se torna disponvel

para servico (atendimento de requisic oes). Se o processo falhar o container

descarrega o servlet.
Apos a que um servlet se torna disponvel, o administrador pode optar para

coloc
a-lo em um estado de indisponvel, e assim ele permanecer a ate que o ad-
ministrador execute a operacao contr
aria.
Quando um requisic ao de um cliente chega ao servidor de aplicac

ao, o con-
tainer cria os objetos request e response, que sao passados de parametro para
o metodo service.
211
O metodo service recupera informac oes sobre a requisic

ao a partir do ob-
jeto request, processa a requisic
ao, e em seguida utiliza o objeto response para
criar uma resposta para o cliente.O metodo service pode ainda chamar outros
metodos para processar a requisicao, como doGet(), doPost(), ou metodos es-
critos pelo pr
oprio programador.
Quando o administrador encerra a aplicac ao, o container invoca o metodo

destroy() e descarrega o servlet. A figura 19.2 representa o diagrama de estados
do ciclo de vida de um servlet.
Figura 19.2: Ciclo de vida do servlet
19.3.2 Mantendo o estado do cliente

Muitas aplicac
oes requerem que uma serie de requisic oes de um mesmo cliente
sejam associadas uma com a outra, para que uma determinada operac ao faca
sentido. Um exemplo pr atico e uma aplicac
ao de carrinho de compras, em que
o cliente vai navegando durante as p aginas escolhendo os produtos e ao final
realiza a compra de fato. O perodo que compreende a entrada no site, pas-

sando pela escolha dos produtos e chegando ao pagamento ou ao cancelamento
e comumente chamada de sess ao. A aplicac
ao e respons
avel por manter o estado
da sess
ao, tendo em vista que o protocolo HTTP e um protocolo stateless.
Para suportar aplicac

oes que precisam manter um estado, os servlets ofere-
cem APIs para implementar o conceito de sess
ao.
As sessoes s
ao representadas pelo objeto HttpSession. Uma sess ao pode ser
acessada chamando o metodo getSession do objeto request. Esse metodo re-
torna a sess
ao corrente associada com o request, e se ela ainda n
ao existir, uma
212
sess
ao e criada. Como o metodo getSession pode modificar o header da resposta
(response header), esse metodo deve ser chamado antes de recuperados o Print-
Writer ou o ServletOutputStream (objetos que servem para mandar dados para
o cliente).
Atributos podem ser associados a uma sess ao pelo nome. Tais atributos
podem ser acessados por qualquer componente Web que pertenca ao mesmo
contexto esteja atendendo uma requisic
ao que seja parte da mesma sess
ao. A
seguir um exemplo de Servlet que mantem sessoes:
public class CashierServlet extends HttpServlet {

public void doGet (HttpServletRequest request,HttpServletResponse response)
throws ServletException, IOException {
// Get the users session and shopping cart

HttpSession session = request.getSession();
ShoppingCart cart = (ShoppingCart)session.getAttribute("cart");
...
...
// Determine the total price of the users books
double total = cart.getTotal();
Como n ao h
a nenhuma forma de um cliente HTTP sinalizar que uma sess ao
nao e mais necess
aria (a n
ao ser via aplicac
ao), cada sess
ao possui um valor de
timeout. O valor de timeout pode ser acessado atr aves dos metodos getMax-
InactiveInterval e MaxInactiveInterval. Geralmente o tempo m aximo de
inatividade permitido para uma sess ao tambem e feita no servidor de aplicac
ao.
19.4 Um pouco mais sobre p

aginas JSP
Java Server Pages (JSP) e uma tecnologia que permite embutir c
odigo java em
uma pagina HTML para gerar conte udo din
amico. Um exemplo simples de uma
p
agina JSP e a seguinte:
<HTML>
<BODY>
<% int a = 1 + 3; %>

Hello! O valor de a e <%= a %>
</BODY>
</HTML>
Todo c
odigo java aparece na pagina .jsp deve estar entre as tags % e %.
Para imprimir algum valor na p agina e utilizada as tag %= e %, ou alterna-
tivamente os metodos out.print() ou out.println(), como mostrado no exemplo
a seguir:
<%@ page import="java.util.*, java.lang.*" %>
213
<HTML>
<BODY>
<% Date date = new Date(); %>
Hello! The time is now
<%
// This scriptlet generates HTML output
out.println( String.valueOf( date ));
%>
</BODY>
</HTML>
A primeira linha da pagina e um exemplo de diretiva JSP. Elas sempre s

ao
definidas entre as tags %@ e %. No exemplo e utilizada uma diretiva de im-
port, que tem por objetivo importar pacotes assim como em uma classe java
comum. Existem outros tipos de diretivas, sendo as mais conhecidas a include
e taglib.
A diretiva include inclue o conte udo do arquivo especificado durante a fase

de compilac ao da p
agina JSP, ou seja, quando esta e convertida em um Servlet.
Neste caso, os dois arquivos s ao combinados para gerar um s muito u
o. E til
quando uma p agina e estruturada em partes bem definidas (topo, menu, ro-
dape, etc.). A seguir um exemplo do uso de uma diretiva include.
<%@ include file="right_menu.jsp" %>

<HTML>
<BODY>
<h1> Noticias do dia </h1>
COECA aprova mais de 30 em 2007. A soma dos sal
arios j
a chega a R$ 150.000!
</BODY>
</HTML>
Um outro recurso das p aginas JSP s ao as chamadas taglibs, que s ao um

mecanismo port avel para encapsular funcionalidades reus aveis em p
aginas da
Web. As tags podem ser de dois tipos: carregadas de uma biblioteca externa de
tags ou pre-definidas. As tags pre-definidas sempre se iniciam com jsp. Exemplo
de chamadas a tag pre-definidas s ao mostrados abaixo:
// Exemplo 1:
// Inclui uma p
agina dentro de outra no momento da compila
c~ao.
<jsp:include page="hello.jsp"/>
// Exemplo 2:
// Localiza e instancia um bean com o determinado nome e escopo
<jsp:useBean id="cart" scope="session" class="session.Carts" />

<jsp:setProperty name="cart" property="*" />
214
<jsp:useBean id="checking" scope="session" class="bank.Checking" >

<jsp:setProperty name="checking" property="balance" value="0.0" />
</jsp:useBean>
Para utilizar uma tag carregada de uma biblioteca externa antes de mais
nada e preciso utilizar a diretiva taglib para especificar onde a biblioteca de tag
(tag library) est
a localizada.
<%@ taglib prefix="blx" uri="/blx.tld" %>

<jsp:useBean id="user" class="user.UserData" scope="session"/>
<HTML>
<BODY>
<blx:getProperty name="user" property="*">
<FORM METHOD=POST ACTION="SaveName.jsp">
Whats your name? <INPUT TYPE=TEXT NAME=username SIZE=20><BR>
Whats your e-mail address? <INPUT TYPE=TEXT NAME=email SIZE=20><BR>
Whats your age? <INPUT TYPE=TEXT NAME=age SIZE=4>
<P><INPUT TYPE=SUBMIT>
</FORM>
</blx:getProperty>
</BODY>
</HTML>
19.4.1 JSP vs. Servlets

Quando uma p agina JSP e requisitada pela primeira vez, o container compila
a p
agina JSP gerando um servlet. Nas chamadas sucessivas essa etapa n ao e
mais necess
aria, a nao ser que a p
agina JSP tenha sido modificada. Portanto,
as p
aginas JSP sao, em ultima inst
ancia, processadas como servlets.
Pelo fato de ser transformada em um servlet, durante o processamento de

p
aginas JSP, o container tambem cria os objetos request e response. O objeto
request armazena informac oes enviadas na requisic
ao do cliente, por exemplo,
os campos de um formul ario de cadastro. O seguinte trecho de c odigo mostra
como o objeto request e utilizado em uma pagina JSP.
<HTML>
<BODY>
<%
// Captura o valor do campo tx_name do form submetido
String nome = request.getParameter("tx_name");
//Captura o ip de origem da requisi
c~ao
String ip = request.getRemoteHost();
%>
Ol
a <b> <%=nome%> </b>, o endere
co IP da sua m
aqina
e <%=ip%>
215
</BODY>
</HTML>
19.5 Um pouco mais sobre EJBs

Os EJBs (Enterprise Java Beans) s ao componentes de software simples, re-
utiliz
aveis e port
aveis, que podem ser combinados para criar aplicacoes corpo-
rativas. Eles encapsulam a l ogica de negocio, ou seja, o c
odigo que realiza o
prop osito da aplicac
ao. Tecnicamente falando, os EJBs tambem s ao classes
Java, com seus pr oprios atributos e metodos.
As inst
ancias dos EJBs s
ao executadas em containers de EJB nos servidores
de aplicac
ao. S
ao os containers que gerenciam o ciclo de vida dos EJBs, de-
cidindo quando eles devem ser criados ou destrudos.
Os principais benefcios da utilizac

ao dos beans s
ao:
O desenvolvedor dos clientes pode se concentra na l

ogica de apresentac
ao;
Os clientes s
ao menos pesados, j a que os EJBs s
ao executados nos con-
tainers do servidor de aplicac
ao;
Maior reutilizac
ao de componentes.
Os dois tipos mais importantes de EJBs s

ao:
Session Beans:
Modelam os processo da l ogica de neg ocios, executam tarefas para os
clientes e podem implementar web services. No momento da requisic ao do
cliente, um session bean e alocado para atendimento, tornando exclusivo
ate o fim do atendimento da requisic ao. Os sessions beans podem ser de
dois tipos: stateless ou statefull. Os beans stateless n
ao mantem o estado
da conversacao, ou seja, ap
os o termino da execuc
ao de um metodo todo
o estado (valor dos atributos do EJB) se perdem, e o mesmo e liberado, se
tornando livre para atender outra requisicao. Ja com os beans statefull, o
estado pode ser modificados e recuperado entre sucessivas invocac oes de
metodos. Todos os metodos invocados pelo cliente s ao enviados a mesma
instancia, que mantem o estado ate que a sess ao termine ou o bean seja
destrudo.
Entity Beans:
Sao responsaveis pela persistencia dos dados da aplicac
ao, geralmente uti-
lizando bancos de dados. Nesse contexto, bean desse tipo est a associado
a uma tabela em um BD, enquanto cada int ancia de um entity bean rep-
resenta um registro de tal tabela. Esse tipo de bean pode ser compartil-
hado por m ultiplos usu
arios, sendo necessario para isso o gerenciamento
de transac
oes, que e um dos servicos prestados pelo container EJB. Cada
bean tem um identificador u nico que permite encontr a-lo. Como na tabela
de um BD relacional, um entity bean pode estar relacionado a outros, po-
dendo este relacionamento ser implementado pelo pr oprio bean ou pelo
container. Com os entity beans, o container e respons avel por todas as
216
chamadas ao banco de dados (Ex: Uma atualizac ao de um entity bean faz

com que o container dispare um SQL Update, enquanto a criac ao de um
novo entity bean ir
a fazer o container disparar um SQL Insert.) A ideia
e eliminar ao m
aximo a necessidade de escrever comandos SQL. Todos os
comandos SQL envidos ao banco fazem uso das conex oes disponveis em
um pool de conexoes, que tambem e um servico gerenciado pelo servidor
de aplicac
ao.
19.5.1 Ciclo de Vida dos EJBs

Um EJB passa por v arios estados ao longo de seu ciclo de vida, sendo
que cada tipo de EJB tem um ciclo de vida especfico. No caso dos EJBs
stateless, o ciclo de vida e descrito pelos seguintes estados e eventos:
O bean inicia em estado Does Not Exist;

O cliente invoca um metodo create() na interface local;
O container instancia o bean e os metodos setSessionContext() e
ejbCreate(), implementados no bean, s ao invocados. A partir da, o
EJB passa para o estado Ready;
Ao final, o cliente invoca o metodo remove() na interface local e em
seguida o container invoca o metodo ejbRemove(), implementado no
bean, e o EJB volta para o estado Does Not Exist;
Figura 19.3: Ciclo de vida de um EJB stateless
O ciclo de vida dos EJBs statefull, por sua vez, e descrito pelo seguintes
estados e eventos:
O bean inicia em estado Does Not Exist;

O cliente invoca um metodo create() na interface local;
O container instancia o bean e os metodos setSessionContext() e
ejbCreate(), implementados no bean, sao invocados. A partir da, o
EJB passa para o estado Ready;
217
Quando no estado Ready, o container pode optar por desativar

o bean, ou seja, transfer-lo para mem
oria secund
aria invocando o
metodo ejbPassivate(). Nesse caso, o EJB vai para o estado Pas-
sive;
Para reativar o bean, o container deve chamar o metodo ejbActi-
vate(), levando-o para o estado Ready novamente;
Ao final, assim como nos EJBs stateless, o cliente invoca o metodo
remove() na interface local e em seguida o container invoca o metodo
ejbRemove(), implementado no bean, e o EJB volta para o estado
Does Not Exist;
Os processos de desativac
ao e ativac
ao de um EJB consistem em salvar
seu estado em mem oria secundaria e restaur
a-lo, respectivamente. Nesses
processos os containers utilizam tecnicas de serializac
ao. Atualmente, os
containers tem implementado a serializac
ao utilizando arquivos XML.
Como foi discutido, os containers fazem uso dos chamados pools de EJBs,
que s
ao um conjunto de beans designados a atender as requisic oes dos
usu
arios. Em determinados momentos, os beans de um pool podem estar
completamente alocados para atendimento de usu arios. Um cliente que
desejasse ter sua requisic
ao atendida teria que aguardar a desalocac
ao de
um bean por parte de um cliente.
No entanto, alguns dos beans no pool podem estar inativos, aguardando

invocacao de metodos por parte dos clientes. E papel do container decidir
quando um bean deve ir para o estado passivo (ser serializado) para liberar
recursos, que em u ltima inst
ancia se traduz em mem oria no servidor de
aplicac
ao, permitindo que novas requisicoes sejam atendidas. Quando um
cliente que teve seu bean serializado decidir realizar uma nova requisicao,
um bean deve ser alocado e o seu estado deve ser restaurado da mem oria
secund aria para a mem oria principal.
218
Figura 19.4: Ciclo de vida de um EJB statefull

219
Parte V
Desenvolvimento Web
220
Captulo 20
Usabilidade
20.1 Definic
ao
A norma ISO 9241-11 define a usabilidade como: a extens ao em que um produto
pode ser usado por usu arios especficos para alcancar objetivos especficos com
efic
acia, eficiencia e satisfaca
o num contexto especfico de uso. E, define uma
estrutura para a usabilidade, figura 20.1.
Figura 20.1: Estrutura de usabilidade segundo a ISO 9241-11
Conforme a estrutura e preciso identificar os objetivos, e decompor a usabil-

idade (efic
acia, eficiencia e satisfac
ao) em atributos passveis de serem verifica-
dos e mensurados, assim como o contexto de uso (usu ario, tarefa, equipamento
e ambiente).
Contextualizando o ambiente para as p aginas de Web, a usabilidade e o
termo tecnico usado para referenciar a qualidade de uso de uma determinada
interface. Ela refere-se ao grau com que o usu ario consegue realizar uma tarefa.
221
Em geral, s ao considerados os seguintes atributos para verificac

ao da usabili-
dade numa interface: funcionalidade correta; a eficiencia de uso; a facilidade
de aprendizagem; a facilidade de relembrar; toler ancia ao erro do usu ario; e
satisfac
ao do usu
ario.
20.2 Princpios da usabilidade

Os principais pontos que um Web site deve cumprir s
ao:
Usar etiquetas ALT para todas as imagens, especialmente as de navegac

ao;
Usar texto negro em fundo branco sempre que possvel para uma legibili-
dade maior;
Usar cores de fundo planas ou com texturas, mas que sejam extremamente
subtis;
Assegurar que o texto se encontra numa cor que se possa imprimir (n
ao
branco);
Colocar o menu de navegac

ao numa localizac
ao consistente em cada p
agina
do site;
Usar localizac
oes familiares para as barras de navegacao; Usar um design
adequado para que nunca seja necess ario recorre ao scroll horizontal;
Usar um eixo de simetria para centrar o texto numa p agina; Encorajar o
uso do scroll atraves da colocac
ao de uma imagem que fique semi-escondida
no fundo da p agina.
Deve-se tentar evitar:
As etiquetas ALT sejam reduzidas (especialmente para uma pequena im-

agem de tamanho fixo);
Mostrar texto est

atico em azul ou a sublinhado;
Usar o negrito ou mai

usculo para texto longo;
Deixar espacos em branco muito longo a leitura torna-se mais difcil;
Obrigar o utilizador a fazer scroll para encontrar informac

ao importante,
especialmente botoes ou links de navegacao;
Usar travess
oes para separar horizontalmente diferentes tipos de conte
udos;
Alternar frequentemente entre texto centrado e alinhado `

a esquerda. A
maior parte do texto deve estar alinhada `
a esquerda;
Fixar a resoluc
ao das p
aginas a mais de 800 X 600. P aginas de grandes
resoluc
oes podem obrigar o utilizador a fazer scroll horizontal.
As principais vantagens do estudo da usabilidade de um produto de software

s
ao:
222
Aumentar a produtividade dos utilizadores;

Aumentar os nveis de utilizac
ao do produto;
Reduzir a necessidade de formac

ao e de custos de produc
ao de docu-
mentac
ao;
Reduzir os custos de suporte tecnico;
Reduzir custos e tempo de desenvolvimento;
Minimizar o re-desenvolvimento e as alterac

oes ap
os a finalizac
ao.
20.3 T
ecnicas de avalia
c
ao de usabilidade
A usabilidade pode ser avaliada por diversas tecnicas. As mais usuais s ao da
heurstica e dos testes com utilizadores.
A heurstica e uma das formas de avaliar a usabilidade mais econ omica e
pratica, permitindo detectar problemas na fase de desenvolvimento da interface.
Esta tecnica consiste em levantar quest oes heursticas relacionadas à interface
como: navegac ao, controle, funcionalidade, linguagem, ajuda e suporte, con-
sistencia e erros. Nunca deve ser feita individualmente, pois uma pessoa n ao
tem capacidade de levantar todas as quest oes heursticas.
A tecnica dos testes com utilizadores obriga que o produto esteja pelo menos
em forma de prot otipo para poder ser testado. O utilizador testa a interface
tendo por base um conjunto de tarefas que foram definidas como princpios
heursticos.
Portanto, o objetivo de um bom design de p aginas Web e obter alta quali-
dade, no que diz respeito n ao somente a uma boa aparencia visual, como tambem
a estruturac
` ao da informac
ao de forma a permitir aos usu arios encontr
a-la r
apida
e eficaz.
223
Captulo 21
Acessibilidade
21.1 Definic
ao
A acessibilidade descreve os problemas de usabilidade encontrados por usu arios
com necessidades especiais ou com limitac oes tecnologicas. Na pr
atica, a acessi-
bilidade de uma interface e indicada pela facilidade de acesso de um indivduo,
independente de suas capacidades fsicas, sensoriais e cognitivas, do seu am-
biente e das condic oes de trabalho e das barreiras tecnol ogicas. Ou seja, a
acessibilidade significa que pessoas com necessidades especiais podem apreen-
der, compreender, navegar e interagir com a Web.
As causas mais freq uentes de falta de acessibilidade em muitas p aginas da
Web para todos os usu arios est
ao muitas vezes associadas: ` a falta de estru-
tura que desorienta o usu ario dificultando a navegacao e ao uso abusivo de
informacoes gr
aficas (imagens, macros, scripts Java, elementos multimdia) sem
proporcionar alternativas adequadas de texto ou outro tipo de coment ario.
21.2 Princpios da acessibilidade

Os princpios de acessibilidade segundo W3C est ao relacionados a dois prin-
cipais temas: assegurar uma transformac ao harmoniosa e tornar o conte udo
compreensvel e naveg avel. Estes princpios sao abordados num documento
elaborado pelo W3C (Word Wide Web Consortium)-WAI (Web Accessibility
Initiative), considerado referencia para os princpios de acessibilidade e ideias
de design, chamado Web Content Accessibility GuideLines, WCAG 1.0.
A transformacao harmoniosa de uma p agina Web pode ser garantida pela

observancia de alguns pontos-chaves:
Separar a estrutura da apresentac ao, diferenciando o conte udo (a in-

formacao a ser transmitida), a estrutura (a forma como a informac
ao e or-
ganizada em termos l ogicos) e a apresentac
ao (a forma como a informacao
e reproduzida, por exemplo, como materia impressa, como apresentac ao
gr
afica bidimensional, sob forma exclusivamente gr afica, como discurso
sintetizado, em braille, etc.);
Criar p
aginas que cumpram a sua finalidade, mesmo que o usu ario n
ao
possa ver e/ou ouvir, fornecendo informac
oes que preencham a mesma fi-
224
nalidade ou funcao que o

audio ou o vdeo, de maneira a se adaptar o mel-
hor possvel a canais sensoriais alternativos e as tecnologias de apoio (soft-
ware ou hardware para ajudar pessoas com incapacidade ou deficiencia)
atualmente disponveis no mercado;
Criar p
aginas que nao dependam exclusivamente de um tipo de equipa-
mento. As p aginas devem ser acessveis a usu
arios que n
ao possuam
mouse, que recebam voz ou texto, etc.
Os criadores de conte udo para a Web necessitam tornar suas produc oes com-
preensveis e naveg aveis, empregando uma linguagem clara e disponibilizando
meios de navegac ao e apropriac ao da informacao apresentada. Disponibilizar
mecanismos de orientac ao de p agina e ferramentas de navegacao s
ao fatores que
potencializam a acessibilidade ` a Web ao garantir a perceptibilidade e navega-
bilidade no site, pois sem esses elementos, os usu arios podem, por exemplo, n ao
compreender tabelas, listas ou menus extensos.
O documento WCAG 1.0 descreve os 14 princpios ou diretrizes que abordam
as quest oes relacionadas à acessibilidade à Web. Cada diretriz possui pontos de
verificac
ao os quais sao classificados por nveis de prioridade. Os 14 princpios
s
ao:
1. Fornecer alternativas ao conteudo sonoro ou visual esta diretriz indica a

necessidade de disponibilizar conte
udo que, ao ser apresentado ao usu ario,
transmita, em essencia, as mesmas func oes e finalidades do conte udo
sonoro e visual. Assim, deve-se fornecer um equivalente textual a cada
elemento nao textual;
2. Nao recorrer apenas a cor deve-se garantir a percepc
ao do texto e dos
elementos graficos do documento, mesmo quando s ao vistos sem cores.
Assim, deve-se assegurar que todas as informac oes veiculadas por meio
de cores estejam tambem disponveis sem cor, por exemplo, a partir de
informac
oes do contexto ou de marcac
ao apropriada;
3. Utilizar corretamente anotac
oes (proporciona efeitos de formatac
ao, com
por exemplo, B ou I em HTML) e folhas de estilo (conjunto de declaracoes
que especificam a apresentacao do documento) esta diretriz indica a
necessidade de se utilizar marcacao nos documentos com os elementos
estruturais adequados e controlar a apresentacao por meio de folhas de
estilo, em vez de elementos de apresentac
ao e atributos;
4. Indicar claramente qual o idioma utilizado utilizar marcac oes que fa-
cilitem a pron uncia e a interpretac

ao de abreviaturas ou de texto em lngua
estrangeira e imprescindvel. Deve-se identificar claramente quaisquer mu-
dancas de idioma no texto de um documento, bem como nos equivalentes
textuais;
5. Criar tabelas passveis de transformac ao harmoniosa assegurar que as
tabelas tem as marcacoes necess
arias para serem transformadas de forma
harmoniosa por navegadores acessveis a outros agentes do usu ario. Em
tabelas de dados, e preciso identificar os cabecalhos de linha e de coluna;
6. Assegurar que as p
aginas dotadas de novas tecnologias sejam transfor-
madas harmoniosamente permitir que as p
aginas sejam acessveis mesmo
225
quando as novas tecnologias mais recentes nao forem suportadas ou ten-

ham sido desativadas. Deve-se organizar os documentos de tal forma que
possam ser lidos sem a necessidade de recorrer a folhas de estilo;
7. Assegurar o controle de usuario sobre as alterac
oes temporais do conteudo
assegurar a possibilidade de interrupcao moment anea ou definitiva do
movimento, intermitencia, transcurso ou atualizacao automatica de p
aginas
e objetos;
8. Assegurar acessibilidade direta em interfaces integradas pelo usu ario
a interface com o usu ario deve obedecer a princpios de design para a
acessibilidade: acesso independente de dispositivos, operacionalidade pelo
teclado, emissao automatica de voz (verbalizac
ao);
9. Projetar paginas considerando a independencia de dispositivos utilizando
func
oes que permitam a ativacao de paginas por meio de dispositivos de
entrada e de comandos. Geralmente as p aginas que permitem interacao
pelo teclado sao tambem acessveis atraves de interfaces de comando de
voz ou de linhas de comando;
10. Utilizar soluc
oes provis
orias ou de transic
ao utilizar soluc
oes de acessi-
bilidade transitorias, para que as tecnologias de apoio e os navegadores
mais antigos funcionem corretamente;
11. Utilizar tecnologias e recomendac
oes do W3C utilizar tecnologias do
W3C (HTML, XML, CSS, SVG, SMIL e etc.) e seguir as recomendaco es
de acessibilidade;
12. Fornecer informac
oes de contexto e orientac
oes ajudar os usu
arios a
compreenderem p aginas ou elementos complexos;
13. Fornecer mecanismos de navegac ao claros fornecer mecanismos de navegac ao
coerentes e sistematizados (informacoes de orientac
ao, barras de navegac
ao,
mapa do site) de modo a aumentar a probabilidade de uma pessoa encon-
trar o que procura em um dado site. A existencia de mecanismos claros
e coerente e importante para usu arios com deficiencia visual ou cognitiva,
beneficiando a todos os usu arios;
14. Assegurar clareza e simplicidade dos documentos assegurar a producao
de documentos claros e simples, para que sejam mais f
aceis de compreen-
der. Deve-se tambem utilizar a linguagem mais clara e simples possvel,
adequada ao conteudo do site.
Conforme mencionado anteriormente, cada diretriz possui pontos de veri-

ficac
ao que por sua vez possui os nveis de prioridade. De acordo com a classi-
ficac
ao, existem 3 nveis de prioridade:
Prioridade 1 pontos que os criadores de conte udo Web tem absolutamente de
satisfazer para evitar que usu
arios fiquem impossibilitados de compreender
as informac
oes contidas na pagina ou site;
Prioridade 2 pontos que os criadores de conteudo para a Web devem satisfazer
para evitar que os usu
arios tenham dificuldade de acessar as informac
oes
contidas no documento, evitando barreiras significativas a documentos
publicados na Web;
226
Prioridade 3 pontos que os criadores de conteudo na Web podem satisfazer

para melhorar o acesso as informac
oes disponibilizadas nas p
aginas ou
sites.
Na verificac
ao da acessibilidade de um documento s
ao estabelecidos os nveis
de conformidade para as p aginas ou sites na Web:
Nvel de conformidade A quando satisfeitos todos os pontos de verificac
ao
de prioridade 1;
Nvel de conformidade Duplo A quando satisfeitos todos os pontos de ver-
ificac
ao de prioridade 1 e 2;
Nvel de conformidade Triplo A quando satisfeitos todos os pontos de ver-
ificac
ao de prioridade 1, 2 e 3.
21.3 T
ecnicas de avalia
cao de acessibilidade
As avaliac oes e validac
oes s
ao especificadas num documento do W3C chamado
Evaluating Web Sites Accessibility, onde s ao apresentados dois metodos de
avaliacao de acessibilidade: Avaliac ao de Preliminar de Acessibilidade (iden-
tificac
ao de forma r apida dos problemas gerais de acessibilidade num site) e
Avaliac ao de Conformidade (verificac ao do grau de conformidade de um site
com os padr oes de acessibilidade, WCAG. Este metodo identifica problemas de
acessibilidade mais especficos num site).
A avaliac
ao e validacao da acessibilidade s
ao feitas por meio de ferramentas
autom aticas ou da revis ao direta manual. Os metodos autom aticos s
ao geral-
mente r apidos, mas n ao sao capazes de identificar todos os aspectos da acessi-
bilidade. Esses metodos n ao s
ao capazes de avaliar conte udo gerado dinamica-
mente. A avaliac ao humana pode ajudar a garantir a clareza da linguagem e a
facilidade de navegac ao.
Para a validac ao autom atica da acessibilidade de uma p agina ou de um
site podemos utilizar as ferramentas ou servicos de an alise da acessibilidade e
compatibilidade, como Bobby, o validador par HTML 4 do W3C e o TAW. O
ideal e a combinac ao dos metodos manuais e autom aticos.
A avaliacao e validacao da acessibilidade de uma p agina ou de um site ` a
Web devem estar presentes desde as fases iniciais do desenvolvimento do doc-
umento. O W3C-WAI aponta como metodo para testar uma p agina ou site,
apos a implementac ao dos princpios de acessibilidade, os seguintes pontos de
verificacao:
1. Utilizar uma ferramenta de acessibilidade autom

atica e ferramentas de
validac
ao de navegadores;
2. Validar a sintaxe (HTML, XML, etc.);
3. Validar as folhas de estilo;
4. Utilizar um navegador s
o de texto ou um emulador;
5. Utilizar varios navegadores gr
aficos com o som e os gr
aficos ativos, sem
gr
aficos, sem mouse e sem carregar frames, programas interpret aveis, fol-
has de estilo ou applets;
227
6. Utilizar v
arios navegadores, antigos e recentes;
7. Utilizar um navegador de emiss ao automatica de falas, com leitores de
tela, com software de aplicac
ao, monitores monocrom aticos, etc;
8. Utilizar corretores ortogr

aficos e gramaticais;
9. Rever o documento, verificando a clareza e a simplicidade;

10. Validar p
aginas com usu
arios reais.
Acessibilidade e usabilidade sao conceitos que se inter-relacionam, pois am-

bos buscam a eficiencia e efic
acia no uso de uma interface. A observac ao de
alguns criterios ou fatores a serem ressaltados na elaboracao de uma p agina
Web pode auxiliar na concepc ao de bons projetos de interface e consequente-
mente, melhorar a qualidade da interacao do usuario com a aplicac
ao.
228
Captulo 22
Padr
oes Web W3C
Padroes Web (Web Standards ou Tableless) e um conjunto de normas, diretrizes,

recomendacoes, notas, artigos, tutoriais e afins de carater tecnico, produzidos
pelo W3C e destinados a orientar fabricantes, desenvolvedores e projetistas para
o uso de pr aticas que possibilitem a criacao de uma Web acessvel a todos,
ajudados por diversos recursos que fazem uma Web mais agrad avel de usar.
Toda essa padronizac ao e para atender a ideia da Web Sem antica que
consiste organizar os documentos Web de tal forma, que estes possam ser inter-
pretados automaticamente, facilitando a pesquisa e cruzamento das informac oes
dos documentos. Ou seja, alem da informac ao, a maquina saberia distinguir a
que se refere esta informac
ao. Um exemplo pr atico disso e que, se utiliz
assemos
o elemento address para definir os enderecos em nosso site, uma ferramenta
de busca poderia criar uma indexac ao destes enderecos, e disponibilizar para o
usu
ario. Quantas vezes voce visitou o site de uma empresa e cansou de procurar
pelo endereco, ou um telefone de atendimento ao cliente? A Web Sem antica n
ao
e uma substituicao a Web atual, mas sim uma extens ao da atual. E a base da
Web Sem antica e o XML, o RDF e a Ontologia.
Existem diversas vantagens na aplicac ao dos padroes Web. Entre elas, vale
destacar:
Acessibilidade tanto para deficientes quanto para usu

arios de dispositivos
moveis como PDAs, celulares, smartphones, etc.; O browser interpreta as
informac
oes de layout (em um arquivo CSS) de 30% a 70% mais rapida-
mente, o que gera uma queda consider avel no download dos arquivos do
site;
Economia de banda na transmiss

ao dos arquivos, pois com a utilizac
ao dos
padr
oes os arquivos possuem menor tamanho; O c odigo HTML se torna
muito mais compacto ao se separar conte
udo, design e programac ao;
Melhor visibilidade no Google e nos demais mecanismos de busca, pois os

padr
oes utilizam a estrutura semantica simples do HTML;
Maior facilidade de atualizac

ao e mudancas no layout.
Algumas tecnologias padronizadas pelo W3C:
229
HTML (Hyper Text Markup Language) E uma linguagem de marcacao

de tags utilizada para produzir p
aginas na Web. A u
ltima recomendac
ao
lancada pelo W3C foi a HTML 4.01;
XHTML (Extensible Hyper Text Markup Language E uma reformulacao

da linguagem de marcac ao HTML baseada em XML. Combina as tags de
marcacao do HTML com as regras do XML. Esta reformulac ao tem em
vista a exibic
ao de p
aginas Web em diversos dispositivos (televisao, palm,
celular). A intenc
ao desta linguagem e melhorar a acessibilidade. A u
ltima
recomendac ao lancada pelo W3C foi XHTML 1.0;
XML (Extensible Markup Language) E uma linguagem de marcac

ao apro-
priada para representacao de dados, documentos e demais entidades cuja
essencia fundamenta-se na capacidade de agregar informac
oes. A ultima
recomendac ao lancada pelo W3C foi XML 1.0;
CSS (Cascading Style Sheets) E uma linguagem de estilo utilizada para

definir a apresentac
ao de documentos escritos em uma linguagem de marcacao,
como HTML ou XML. Seu principal benefcio e prover a separacao entre o
formato e o conteudo de um documento. A u ltima recomendac
ao lancada
pelo W3C foi CSS 3;
XSL (Extensible Markup Language E uma linguagem que define as folhas
de estilo padr
ao para o XML. E constituda de tres partes: XSLT (lin-
guagem de transformacao de documentos XML), XPath (linguagem para
navegac
ao em documentos XML) e XSL-FO (linguagem para formatac ao
de documentos XML). A u ltima recomendacao lancada pelo W3C foi XSL
1.0, XSLT 2.0 e XSL-FO;
XSLT (XSL Transformations) E uma linguagem de marcac ao XML usada
para transformar documentos XML. Esta linguagem possibilita mais trans-
formac
oes mais potentes do que as folhas de estilo CSS;
XPath (XML Path) E uma linguagem para encontrar informac oes em um

documento XML. O XPath e utilizado para navegar atraves de atributos
e elementos em um documento XML. E o principal elemento no padr ao
XSLT;
XQuery (XML Query) E uma linguagem utilizada para executar consultas
em dados XML. A u
ltima recomendac
ao lancada pelo W3C foi XQuery
1.0;
DOM (Document Object Model) E uma especificac

ao do W3C, indepen-
dente de linguagem e plataforma, onde se pode alterar e editar a estrutura
de um documento. Com o DOM e possvel acessar elementos de um doc-
umento, e poder trabalhar com cada um desses elementos separadamente,
possibilitando a criac
ao de p
aginas altamente din amicas. A u ltima re-
comendac ao lancada pelo W3C foi DOM Level 3;
SOAP (Simple Object Acess Protocol) E um protocolo de comunicac ao
simples baseado em XML para troca de informac oes entre aplicac
oes. A
especificac
ao do SOAP prove maneiras para construir mensagens que pos-
sam trafegar por meio de diversos protocolos de forma independente da
230
linguagem de programac ao e do sistema operacional. Normalmente, o pro-

tocolo utilizado para troca de informacoes e o HTTP, pois este n
ao possui
problema de seguranca com firewalls e proxy. Ou seja, o http por ser um
protocolo da Internet nao e bloqueado pelos firewalls e proxy. A u ltima
recomendac ao lancada pelo W3C foi SOAP 1.2;
WSDL (Web Services Description Language) E uma linguagem baseada
em XML para descric ao de Web Services e como acessa-los. A u
ltima
recomendac
ao lancada pelo W3C foi WSDL 1.1;
RDF (Resource Description Framework) E uma linguagem para repre-

sentar informac oes na Web. O RDF usa notac ao XML como sintaxe de
codificacao para descricao de metadados. A ideia do RDF e a descric
ao
dos dados e dos metadados em tres componentes: recurso (qualquer objeto
que e identific
avel unicamente por um URI), propriedade (e uma carac-
terstica, um atributo ou relacionamento especfico de um recurso) e valor,
e uma forma coerente de acesso aos padr oes de metadados (namespace)
publicados na Web. Um dos benefcios do RDF e permitir que aplicac oes
possam agir de forma inteligente e automatizada sobre as informac oes
publicadas na Web. A u ltima recomendac
ao lancada pelo W3C foi RDF
1.0;
OWL (Web Ontology Language) E uma linguagem para definir e instan-

ciar ontologias na Web. Uma ontologia OWL pode incluir descric oes de
classes e suas respectivas propriedades e relacionamentos. A OWL foi pro-
jetada para aplicac
oes que precisam processar o conte udo da informac ao
ao inves de apresenta-la aos humanos. Ela fornece um vocabul ario adi-
cional com uma sem antica formal que facilita muito mais a interpretac
ao
do conte udo da Web do o XML. A OWL foi baseada nas linguagens OIL
e DAML+OIL, e possui tres sublinguagens: OWL LITE, OWL DL, OWL
FULL. A u ltima recomendac ao lancada pelo W3C foi OWL 1.0;
SMIL (Syncronized Multimedia Integration Language) E uma linguagem

baseada em XML, trabalhando com tags semelhantes ao HTML, podendo
ser editado por qualquer editor de texto comum, pois os elementos mul-
timdia n
ao s
ao inseridos, apenas referenciados. O SMIL permite a criac ao
de apresentacoes audiovisuais interativas, e e utilizado em apresentac
oes
multimdias do tipo rich media, que integram audio e vdeo streaming,
texto ou qualquer outro tipo de arquivo. O SMIL permite gerenciar a
transmiss ao de arquivos multimdia por streaming, sincronizar estes ar-
quivos com animac oes flash, p

aginas HTML, etc., e criar uma especie de
indexacao destes arquivos de audio e vdeo. Uma grande vantagem do
SMIL que ele e utilizado pelos players mutimdia Real Player QuickTime.
Au ltima recomendac ao lancada pelo W3C foi SMIL 2.1.
O W3C estabelece uma serie de recomendacoes para utilizar essas tecnolo-

gias. Esses padr
oes s
ao conhecidos como Padr
oes W3C ou Recomendac oes W3C.
Observac
oes:
1. Um namespace (NS) define um vocabul ario controlado que identifica um

conjunto de conceitos de forma u
nica para que n
ao haja ambiguidade na
231
sua interpretac
ao. Os namespaces XML s ao conjuntos de tipos de elemen-
tos e atributos possveis para cada tipo. As triplas do RDF se baseiam
em namespaces de forma que a cada recurso seja associado uma dupla
de propriedade e valor. Os namespaces podem ser referenciados por meio
de uma URI, que se constitui em um reposit orio compartilhado, e nao-
ambguo, onde usu arios e programas de validac
ao de c
odigo XML podem
consultar a sintaxe e propriedades sem anticas dos conceitos cobertos;
2. URI (Uniform Resource Identifier) e uma cadeia de caracteres que identi-

fica um recurso da internet. O URI mais comum e o URL que identifica
um endereco de domnio, mas os URIs podem tambem identificar livros,
elementos de uma p agina e pessoas individuais, por exemplo;
3. Uma Ontologia fornece uma conceituac ao (meta-informac ao) que descreve

a sem antica dos objetos, as propriedades dos objetos e as relac oes exis-
tentes entre eles num dado domnio do conhecimento. As Ontologias s ao
desenvolvidas para fornecer um nvel sem antico `
a informac
ao de um dado
domnio de forma torn a-la process
avel por maquinas e comunic avel en-
tre diferentes agentes (software e pessoas). As ontologias s ao utilizadas
na Inteligencia Artificial, Web Sem antica, Engenharia de Software e Ar-
quitetura da Informac ao como uma forma de representac ao de conheci-
mento do mundo ou alguma parte dele. S ao elementos da Ontologia: In-
divduos (inst
ancias) que incluem objetos concretos ou abstratos, Classes
(conceitos) que sao grupos abstratos (por exemplo, Pessoa, a classe para
todas as pessoas), Atributos que armazenam informac oes do objeto (pelo
menos um nome e um valor), e Relacionamento que s ao as formas como
os objetos se relacionam com os outros objetos;
232
Captulo 23
XML
23.1 O que
e XML?
Extensible Markup Language (XML) e uma linguagem de marcac ao (utilizac
ao
de tags) para descrever os dados de p aginas Web de forma estruturada. O
XML e um dos padr oes adotado pelo W3C e foi projetado para descrever o
conteudo de uma pagina Web em vez da sua formatac ao. O XML e derivado da
linguagem SGML (Standard Generalized Markup Language), que e um padr ao
internacional para definic
ao de formatos de representacao de documentos. O
SGML e muito mais complexo de se implementar do que o XML. A figura 23.1
mostra um exemplo de uma p agina Web em XML.
Como o XML trata apenas do conte udo do documento, existem diversos
padroes para descrever o formato da apresentacao dos dados. Uma das formas
de apresentar tais documentos e por meio das folhas de estilo. As principais
linguagens de estilo s
ao o CSS (Cascading Style Sheets) e o XSL (Extensible
Style Sheets). Ent
ao, a apresentac
ao dos dados ficar
a a cargo dessas linguagens.
Figura 23.1: Uma p

agina Web simples em XML
233
23.2 Caractersticas do XML

Algumas caractersticas do XML:
uma linguagem de representac
E ao de documentos e n
ao uma linguagem
de programac
ao;
Facilita a gerac
ao de dados, a leitura de dados e assegura que a estrutura
de dados n ao e ambgua;
extensvel e independente de plataforma;
E
modular, pois a permite a definic
E ao de um novo formato de documento
pela combinac
ao e reuso de outros formatos;
N
ao possui tags pre-definidas, e permite um n
umero infinito de tags;
Estruturas de dados podem ser agrupadas em profundidade infinita;

Pode ser descrita por grafos com n
os e r
otulos, possibilitando que algorit-
mos conhecidos possam ser utilizados para a recuperac ao ou localizac
ao
de dados.
23.3 Comparac
ao entre XML e HTML
O XML e o HTML s ao primos. O XML n ao veio para substituir o HTML. Eles
derivam da mesma linguagem, o SGML. A grande diferenca entre o HTML e
o XML e que o HTML descreve como os dados devem ser apresentados (for-
matacao dos dados) numa p agina Web enquanto o XML descreve os dados
(conteudo) de uma p agina Web.
Ambos fazem o uso de tags (palavras delimitadas por < e >) e atributos.
Enquanto o HTML especifica o que cada tag e atributo significam e frequente-
mente como o texto entre elas aparece num browser, o XML usa as tags somente
para delimitar as porc oes de dados, e deixa a interpretacao dos dados para a
aplicac
ao que ira ler este dado. Por exemplo, enquanto em um documento
HTML uma tag p indica um par agrafo, no XML essa tag pode denotar um
preco, um par ametro, uma pessoa, etc.
Enquanto ao uso das tags nas duas linguagens, O XML as tags n ao s
ao
pre-definidas e pode-se usar um n umero infinito de tags. O HTML isso n ao e
possvel.
Os arquivos XML s ao arquivos textos, e nao sao destinados à leitura por

um ser humano como o HTML e. Isso fica a cargo de outras linguagens. As
especificac
oes de XML s ao muito mais rgidas que a especificacao do HTML.
Elas estabelecem que e obrigat orio rejeitar sintaticamente arquivos incorretos,
mesmo que o navegador possa descobrir o que o Web designer pretendia. Os
navegadores s o tem permissao para indicar o erro.
23.4 Sintaxe b
asica do XML
O componente b asico no XML e o elemento, que e composto pela uma tag
inicial, pelo conte
udo e pela uma tag final. A express
ao book e chamada de
234
tag inicial (comeca com e termina com ) e /book e chamada de tag final
(comeca com / e termina com ). Estas marcac oes sao definidas pelo usu
ario.
A estrutura ou o texto entre as tags iniciais e finais e chamado de conte udo. As
tags no XML s ao case sensitive.
Os elementos podem incluir outros elementos (ditos elementos filhos) e tex-
tos. No exemplo da figura 23.1, bookl ist e o elemento raiz e o book e o elemento
filho. Usam-se elementos repetidos com a mesma tag (book) para representar
colec
oes de dados, figura 23.1.
Um elemento pode n ao ter qualquer conte udo. Este tipo de elemento e
designado por elemento vazio, por exemplo, o elemento \ <figura path=... >
que marca onde deve ser inserido uma figura. Os elementos vazios possuem uma
sintaxe diferente, inicia-se por < e termina em >, que e a forma abreviada de
escrever <elem-ident> <elem-ident>. N ao e permitida a utilizac
ao de espaco
em branco no nome dos elementos. O nome dos elementos pode comecar somente
com letras, underscore ou dois pontos.
A linguagem XML permite associar atributos aos elementos. Os atributos
s
ao utilizados para especificar as propriedades ou caractersticas do elemento.
O atributo e definido como um par (nome, valor) separado por um sinal de
igual (=) e sempre aparecem na tag inicial. Assim como nas tags, o usu ario
pode definir tambem os atributos. O valor do atributo e sempre um conjunto
de caracteres que deve estar entre aspas. Por exemplo:
<disciplina cod="cop025"> T
ecnicas de programa
c~ao</disciplina>
Neste exemplo, cod=3cop025e um atributo do elemento <disciplina>.

Cada atributo de um elemento pode ser especificado somente uma vez.O XML
define apenas dois atributos como reservado: xml:lang e xml:space.
Uma observacao importante a ser feita a respeito de elemento e atributo e
que nao existe uma fronteira entre os dois, figura 23.2. A representac
ao (b) est
a
correta, mas e muito mais difcil de processar.

oes diferentes de uma estrutura em XML
Algumas regras b
asicas devem ser lembradas na construc
ao de um docu-
mento XML:
235
O documento deve ter sempre uma declarac

ao XML no incio (<?xml
version=1.0?>);
O documento deve incluir um ou mais elementos o primeiro elemento,
que delimitar
a todo o corpo do documento, e o elemento raiz e todos os
outros dever
ao estar includos dentro dele;
Todos os elementos dever ter uma tag de incio e outra de fim;
Todos os elementos dever estar aninhados corretamente;
Todos os valores de atributos devem estar entre aspas.
23.5 Conjunto de tags

As principais tags que podem ser utilizadas em um documento XML s
ao:
Instru
cao de processamento mecanismo que permite a inserc ao de informac
oes
explcitas em um documento destinadas a uma aplicac ao. Os interpre-
tadores XML n ao interpretam essas informac
oes, mas simplesmente as
repassam para a aplicacao. A instruc
ao de processamento nao faz parte
do conte udo do documento;
Sintaxe:
<? ?>
Exemplo:
<?html action="hr"?>
Declara
cao XML e um tipo de instruc ao de processamento. Qualquer doc-
umento XML dever comecar sempre com uma declarac ao XML. Nor-
malmente, se contiver algo antes da declarac ao ou se estiver ausente, a
aplicac
ao acusar
a erro. Existem tres tipos de atributos para a declarac
ao:
version (Obrigat orio e indica a versao do XML utilizado, 1.0), stan-
dalone (Opcional e indica se o documento est a autocontido. Aceita os
valores yescaso o documento n ao tenha referencias a entidade externa e
nocaso contr ario.), encoding (Opcional e indica qual codificac
ao usada
para os caracteres. O valor para caractere portugues e isso-8859-1);
Sintaxe:
<?xml ?>
Exemplo:
<?xml version="1.0" standalone="yes" encoding="UCS-2" ?>
Coment
arios utilizado para indicar que o conte
udo a seguir n
ao e para ser
processado;
Sintaxe:
236

Exemplo:

Elementos explicado anteriormente;

Atributos explicado anteriormente;
CDATA utilizado quando se deseja que os caracteres de texto n
ao sejam con-
fundidos com os elementos de marcac
ao, por exemplo o uso do sinal < e
>;
Sintaxe:
<![CDATA[ ... ]]>
Exemplo:
<![CDATA[Imprima a tecla <<ENTER>>]]>
PCDATA (Parser Character Data) utilizado para designar que o texto en-
tre as duas marcac
oes e um dado e nao um texto. Isso e utilizado na
definic
ao das DTDs ou gramatica do documento;
Refer
encias e possvel associar identificadores u
nicos aos elementos, por meio
de um atributo de identificacao, id. Com isto permite-se que elementos
distintos referenciem-se entre si;
Exemplo:
<biblio id="bib" ano="2001">

...
</biblio>
Entidade identifica um conjunto de informac ao por um nome. As entidades

podem ser associar a textos e ficheiros. O XML possui cinco entidades
pre-definidas: &lt (<), &gt (>), &amp (&), &apos () e &quot ();
Sintaxe:
<!ENTITY ...>
Exemplo (entidade interna):
<!ENTITY assinatura "Jorge Manuel Neves Coelho">

(assinatura= Jorge Manuel Neves Coelho)
Exemplo (entidade externa):
<!ENTITY ent01 SYSTEM "ents/ent01.xml">
237
A verificac
ao sintatica de um documento XML e feita por parsers que anal-
isam um documento e enviam mensagens de erro ao detectar erros de sintaxe.
Existem dois tipos de parser: o paser validador, que verifica se um documento e
bem formado, e o parser n ao validador, que verifica se um documento e v alido.
Um documento XML e bem formado quando obedece a sintaxe XML, e um doc-
umento XML e v alido quando obedece a uma gram atica especificada por uma
DTD. Pode-se dizer que um documento v alido e um documento bem formatado,
mas o contrario nao.
23.6 NameSpaces
Como os nomes dos elementos em XML n ao estao pre-definidos, pode ocorrer
um conflito de nome quando um documento XML importa outro documento
XML, pois esses documentos podem usar o mesmo nome para descrever dois
tipos diferentes de elementos, por exemplo, o elemento < table > da figura 23.3.
Figura 23.3: Diferentes documentos XML com mesmo nome de elemento
O NameSpace e um padr ao definido pelo W3C e basicamente e utilizado

para resolver conflitos de nomes usados nos documentos XML. A resoluc ao de
conflitos pode ser feita por meio do uso de prefixos ou de namespaces.
No uso de prefixos, basta o usu ario definir um nome diferente para seus
elementos < table >, por exemplo, < h : table > e < f : table >. Usando o
prefixo, criam-se dois tipos diferentes de elementos do tipo < table >.
Para definir/criar um namespace o usu ario deve definir o atributo xmlns
(XML NameSpace) a tag inicial de um elemento no documento XML com a
sintaxe xmlns:namespace-prefix =namespace. Quando o namespace e definido
a tag inicial do elemento, todos os elementos filhos com o mesmo prefixo s ao
associados com o mesmo namespace. O atributo xmlns pode ser utilizado em
qualquer elemento e n ao apenas no n
o raiz. A figura 23.4 mostra alguns exemplos
de namespace e a Ilustrac ao 6 mostra a utilizac ao de namespace em vez de
prefixo para o exemplo da figura 23.3.
Pode-se perceber pela figura 23.4.(a) que a string identificadora de um
namespace e grande para ser manipulada diretamente. Para que sua utilizac ao
238
Figura 23.4: Declarac

ao de namespace
Figura 23.5: Exemplo de utilizac

ao de namespace
seja vi
avel, utiliza-se um prefixo, uma especie de abreviatura para os names-
paces. De acordo com a figura 23.4.(b) os prefixos seriam catalogo, encomenda
e jcr.
A especificac
ao de namespaces da W3C estabelece que o namespace deve ter
um URI para garantir a unicidade dos nomes dos elementos.
Note que o endereco usado para identificar o namespace n ao e usado pelo
parser para buscar informacao. O u nico proposito e dar ao namespace um
nome u nico. Entretanto, e comum usar o namespace como um ponteiro para
uma p agina Web real contendo informac oes sobre o namespace. Por exemplo,
a figura 23.5 mostra a declarac
ao de namespaces distintos para especificar onde
s
ao buscados os dados da definicao de elementos com o mesmo nome, no caso <
table >. Os namespaces s ao tambem utilizados em definic

oes de XML Schema,
XSL e RDF.
23.7 Gram
atica de um documento XML
Algumas vezes existe a necessidade de definir os elementos que podem aparecer
em um documento XML, o conte udos destes, e os atributos que podem estar
associados aos elementos. Tambem, existe a necessidade de definir a estrutura
do documento especificando, por exemplo, quais s ao os subelementos de um
elemento e a seq
uencia que eles devem aparecer. A primeira linguagem proposta
239
para a definic
ao dessas regras nos documentos XML foi a DTD (Document Type
Definition).
Existem quatro tipos de declarac oes que podem ser utilizadas em um DTD:
elementos, atributos, entidades e instruc oes de processamento. As entidades
est
ao relacionas com a organizac ao fsica do documento XML, as instruc oes de
processamento foram explicadas anteriormente, os elementos s ao definidos pela
palavra-chave ELEMENT e a lista de atributos de cada elemento e definida pela
palavra-chave ATTLIST. As principais declarac oes que ocorrem em um DTD
s
ao de elementos e de atributos.
As declaracoes de elementos especificam como deve ser o conte udo do ele-
mento. As seguintes declaracoes podem ser feitas:
Definir a seq
uencia em os subelementos de um elemento devem aparecer:
(a, b)
Sintaxe:
<!ELEMENT nome_elemento
(seq
uência de subelemento separados por v
rgula na
ordem que devem aparecer)>
Exemplo:
<!ELEMENT biblio (t
tulo, autor, tipo_pub)>
Definir elementos vazios: constante EMPTY Exemplo:
<!ELEMENT image EMPTY>
Definir a ocorrencia repetida de um elemento em particular:

Pelo menos uma vez: (elemento)+ Exemplo:
<!ELEMENT biblio (titulo, autor+, tipo_pub)>
Zero ou mais vezes: (elemento)* Exemplo:
<!ELEMENT tabela_biblio (biblio*)>
Definir que o elemento deve ser um entre uma lista de elementos: (a|b)
Exemplo:
<!ELEMENT tipo_pub (periodico | evento)>
Obs.: O elemento tipop ub e composto por um elemento periodico ou

evento.
Definir que o elemento tem presenca opcional: (elemento)? Exemplo:
<!ELEMENT biblio (titulo, autor, tipo_pub, resumo?)>
Definir que o elemento e uma string de caracteres: #P CDAT A Exemplo:
<!ELEMENT autor (#PCDATA)>
240
Definir elementos livres: constante ANY. Exemplo:
<!ELEMENT doc (para)+>

<!ELEMENT nome (#PCDATA)>
<!ELEMENT lugar (#PCDATA)>
<!ELEMENT data (#PCDATA)>
<!ELEMENT para ANY>
Obs: O elemento para est

a definido como sendo de conteudo ANY, ou seja,
pode ser texto com elementos nome, lugar e data pelo meio (< para >Tudo
aconteceu em < lugar > Braga < /lugar > ... < /para >).
A figura 23.6 mostra o documento XML que descreve uma agenda e a figura
23.7 mostra as especificac
oes do documento DTD.
Figura 23.6: Documento XML contendo a descric

ao de uma agenda
Figura 23.7: Conjunto de declarac

oes para o XML que descreve a agenda
241
As declarac
oes de atributo servem para especificar o nome, o tipo de dado
associado ao atributo e opcionalmente especificar se ha algum valor padr
ao de
atributo: Sintaxe:
<!ATTLIST nome_elemento {nome_atributo tipo_atributo}> onde {nome_atributo tipo_atributo} den
Obs.: Alternativamente pode-se utilizar a seguinte sintaxe:
<!ATTLIST nome_elemento nome_atributo1 tipo_atributo1>
<!ATTLIST nome_elemento nome_atributo2 tipo_atributo2>
As seguintes declarac
oes de tipo de atributo podem ser feitas:
Valor do atributo deve ser uma string de qualquer tamanho: CDATA

Exemplo:
<!ATTLIST biblio ano CDATA local CDATA >
Valor do atributo pode ser um entre uma lista de valores possveis:

Exemplo:
<!ATTLIST tipo_pub abrange (regional | nacional | internacional)>
Valor do atributo significa um identificador do elemento ao qual est

a as-
sociado: ID Exemplo:
<!ATTLIST biblio ident ID>
Obs.: Cada elemento que possui o atributo ID deve ter um u

nico atributo
ID e para cada elemento o valor ID deve ser diferente.
Valor do atributo significa um nome de identificador referenci
avel: IDREF
Exemplo:
<!ATTLIST biblio refer IDREFS>
Obs.: Quando da ocorrencia de atributo com m ultiplos valores do tipo

IDREF, utiliza-se a declaracao IDREFS. Usa-se o IDREF para implemen-
tar relac
oes entre elementos.
Opcionalmente e possvel estabelecer se a presenca de um atributo e obri-

gat
oria, opcional ou se assume um valor padr ao. As seguintes declarac
oes s
ao
possveis:
Declarar que a presenca do atributo e obrigat

oria: #REQU IRED ap
os
a declarac
ao do tipo de atributo
Exemplo:
<!ATTLIST biblio ano CDATA #REQUIRED local CDATA>
Declarar que a presenca do atributo e opcional: #IM P LIED ap

os a
declarac
ao do tipo de atributo
Exemplo:
242
<!ATTLIST biblio ano CDATA #REQUIRED local CDATA #IMPLIED>
Especificar um valor padrao quando o valor do atributo deve ser escolhido

entre uma lista de valores:
Exemplo:
<!ATTLIST aula tipo (teoria | exemplo | exerc

cio) "teoria">
Declarar que a presenca do atributo e fixa: #F IXED apos a declarac

ao
do tipo de atributo e seu valor sera o que estiver a frente da palavra
#F IXED. Exemplo:
<!ATTLIST data tipo CDATA #FIXED "data">
Obs.:
1. O atributo a ser definido como #F IXED e constante e imut

avel.
2. Definic
ao de uma entidade parametrica (somente no DTD):
<!ELEMENT a (c|d|e)> <!ELEMENT a %ab;>
=> <!ENTITY % ab "(c|d|e)"> =>
<!ELEMENT b (c|d|e)> <!ELEMENT b %ab;>
Quando um documento XML atende as especificac oes de um esquema, este

documento e chamado de documento v alido. Para que o interpretador XML
possa validar um documento XML quanto a sua gram atica e necess
ario associar
o DTD ao documento XML. Esta associac ao, que e especificada no incio do
documento DTD, pode ser feita tanto de forma interna quanto de forma externa.
Na forma interna, as declarac
oes DTD sao colocadas explicitamente no ar-
quivo XML, atraves da sintaxe:
<!DOCTYPE nome_DTD [declara

c~oes da DTD]>
Exemplo:
Figura 23.8: Associacao entre o XML e o DTD na forma interna
Na forma externa, a associac

ao e feita no documento XML por meio da
sintaxe:
<!DOCTYPE nome_DTD SYSTEM "nome do arquico DTD">
243
Exemplo:
<!DOCTYPE agenda SYSTEM "agenda.dtd">
<!DOCTYPE agenda SYSTEM "http://xml.idi.uminho.pt/DTDs/agenda.dtd">
Obs.: Esta declarac
ao indica que o elemento raiz do documento e agenda e que
o DTD pode ser encontrado no sistema no arquivo agenda.dtd.
A declaracao DOCTYPE n ao pode aparecer livremente num documento
XML. Ela deve aparecer sempre ap os a declarac
ao XML e antes do elemento
raiz, figura 23.9.
Figura 23.9: Posic

ao da declarac
ao DOCTYPE
Pelas declarac
oes b
asicas que uma DTD pode utilizar, observa-se que os tipos
de dados que podem ser declarados s ao de certa forma limitados. Para ampliar
as possibilidades de se definir tipos de dados, outro tipo de esquema foi definido
pelo W3C denominado XML Schema ou XSD (XML Schema Definition).
23.8 Tecnologias XML

A seguir s
ao apresentadas as tecnologias relacionadas ao XML:
XHTML (Extensible HTML) e uma vers

ao explcita do HTML;
XML DOM (XML Document Object Model) define um padr
ao de acesso
e manipulac
ao de documentos XML;
XSL (Extensible Style Sheet Language) consiste de tres partes: XSLT,
XPath e XML-FO;
XSLT (XSL Transformation) e usado para transformar documentos XML
em outros formatos, como XHTML;
XPath e uma linguagem para navegac
ao em documentos XML;
XSL-FO (XSL Formatting Object) e uma linguagem para formatac

ao de
documentos XML;
XLink (XML Linking Language) e uma linguagem para criar hyperlinks
em documentos XML;
XPointer(XML Pointer Language) permite os hyperlinks XLink apontar
para partes especficas de um documento XML;
DTD (Document Type Description) e usado para definir a gram
atica de
um documento XML;
XSD (XML Schema Definition) e baseado em XML alternativo ao DTD;
244
XForms (XML Forms) usa XML para definir a forma dos dados;
XQuery (XML Query Language) e usado para consultar dados em XML;
SOAP (Simple Object Access Protocol) e um protocolo em XML que per-
mite as aplicac
oes trocarem informac
oes sobre o protocolo http;
WSDL (Web Services Description Language) e uma linguagem baseada
em XML para descrever web services;
RDF (Resource Description FrameWork) e uma linguagem baseada em
XML para descrever recursos da Web;
RSS (Really Simple Syndication) e um formato para indicar notcias e conte
udos
novos de um site;
WAP (Wireless Application Protocol) foi desenvolvido para mostrar conte
udo
para cliente wireless, como celulares;
SMIL (Syncronized Multimedia Integration Language) e uma linguagem
para descrever apresentac
oes audiovisuais;
SVG (Scalable Vector Graphics) define formatos gr
aficos em XM.
A figura 23.10 mostra como algumas dessas tecnologias interagem com a

linguagem XML.
Figura 23.10: Interac

ao entre as tecnologias XML
23.9 Benefcios da linguagem XML

Os principais objetivos da linguagem XML:
Buscas mais eficiente;

Desenvolvimento de aplicac
oes flexveis para a Web;
245
Integrac
ao de dados de fontes diferentes;
Computac
ao e manipulac
ao local;
M
ultiplas formas de visualizar os dados;
Atualizac
ao granulares dos documentos;
F
acil distribuic
ao na Web;
Escalabilidade;
Compreens
ao.
23.10 Ferramentas de desenvolvimento

Parsers:
Expat;
XML4J;
MSXML;
Editores:
Editores de texto comum;
Xeena;
246
Captulo 24
XSLT
Uma das principais ideias de XML e deixar explcita a separac

ao entre conte
udo,
estrutura e apresentac
ao de um documento para Web. Como XML trata apenas
do conte udo dos documentos, devem existir outros padr oes para descrever o
formato de apresentacao dos dados. Uma das formas de permitir apresentac ao
de tais documentos e por meio das folhas de estilo.
Linguagens de folhas de estilo (style sheets) foram projetadas para permi-
tir que a descric
ao de estilo de apresentac
ao de documentos seja separada da
representac
ao do conteudo dos documentos. Isto facilita a reutilizac ao de um
mesmo documento para diferentes aplicac oes ou diferentes tipos de usu arios
que requerem diferentes vis oes do mesmo. O princpio b asico destas lingua-
gens e prover uma sintaxe que permita associar partes especficas do conte udo
de documentos a estilos ou ac oes que devem ser realizadas sobre tais partes.
As principais linguagens de estilo s ao a CSS (Cascading Style Sheets) e XSL
(Extensible Style Sheet).
24.1 O que
e uma folha de estilo?
Quando um site Web e complexo e consiste de muitas p aginas produzidas por
v
arios autores que trabalham na mesma empresa, frequentemente e interessante
ter um meio de impedir que diferentes p aginas tenham uma aparencia distinta.
Esse problema pode ser resolvido usando-se folhas de estilo.
Quando as folhas de estilo s ao utilizadas, as paginas individuais deixam de
usar estilos fsicos, como negrito e italico. Em vez disso, os desenvolvedores
utilizam estilos pr oprios como < dn > (definic ao), < em > (enfase fraca),
< strong > (enfase forte) e < var > (vari aveis). Os estilos l
ogicos s
ao definidos
na folha de estilo, referida no incio de cada pagina. Uma folha de estilo pode
ser comparada a um arquivo #include em um programa C: a mudanca em uma
u
nica definic
ao de macro provoca a alterac ao em todos os arquivos de programa
que incluem o cabecalho.
24.2 Comparac
ao entre o CSS e XSL
A semelhanca entre as essas duas folhas de estilo, CSS e XSL, esta em ambas
podem ser usadas em documentos XML, mas o CSS n ao transforma documentos.
247
Essa possibilidade est

a reservada somente ao XSL. XSL e mais poderoso que
o CSS, pois suporta transformacoes do documento antes de sua exibicao. Por
outro lado, o XSL nao pode ser usado em linguagens HTML.
Desta forma essas duas linguagens completam-se uma ` a outra e podem ser
utilizadas simultaneamente. A utilidade do XSL e mais perceptvel, quando,
por exemplo, e necess
aria a ordenac
ao dos dados antes de serem exibidos.
24.3 O que
e o XSL?
O XSL e uma linguagem para descrever folhas de estilo para documentos XML.
composta por tres linguagens descendentes de XML:
E
XSLT (XSL Transformation) linguagem para transformar documentos XML;
XPath linguagem para definir parte de um documento XML;
XSL-FO (XSL Formatting Object) linguagem para formatar documentos

XML.
A componente mais importante do XSL e o XSLT.
24.4 O que
e o XSLT?
O XSLT e a parte do XSL usada para transformar um documento XML em
outro documento XML, ou em outro tipo de documento (tx, pdf, rtf, HTML,
XHTML, etc.). O XSLT utiliza o XPath para encontrar informac oes nos doc-
umentos XML. XPath e usado para navegar atraves dos elementos e atributos
nos documentos XML.
O XSLT define um conjunto de regras de transformac ao que ser
ao aplicadas
a um documento XML ( arvore fonte) para produzir outro documento XML
(
arvore resultado). Nesse processo de transformac
ao, o XSLT utiliza o XPath
para definir partes do documento de origem (fonte) que combinem com um ou
mais templates pre-definidos. Quando uma combinac ao e encontrada, o XSLT
transforma essas partes do documento de origem no documento de resultado.
As partes do documento de origem que n ao s
ao combinadas com o template
permanecer ao sem modificac
oes no documento de resultado.
O XSLT permite:
Adicionar texto ao conte

udo de elementos;
Remover, criar, alterar e ordenar os conte

udos dos elementos;
Converter conte
udo de elementos para valores de atributos, ou vice-versa;
Alterar a ordem dos elementos;
Substituir elementos por novos elementos.
248
24.5 Caractersticas do XSLT

Algumas caractersticas do XSLT:
uma linguagem declarativa descreve a transformac
E ao desejada, ao
inves de prover uma seq
uencia de instruc
oes procedurais;
essencialmente uma ferramentapara transformar documentos XML;
E
Manipula
arvores;
Uso de XSL NameSpaces o W3C prove um namespace para as tags XSL.
24.6 Declarando um documento XSL

Como o XSL obedece a mesma sintaxe do XML, quando se cria uma especi-
ficac
ao de folha de estilo XSL, deve-se incluir a instruc
ao de processamento (por
exemplo, <?xml version=1.0standalone=yesencoding=UCS-2?>) para ar-
quivos XML no incio do arquivo que descreve a folha de estilo. Os arquivos
XSL tem extens ao .xsl. A figura 24.1 mostra um exemplo de um arquivo XSL.
Figura 24.1: Declarac

ao de uma folha de estilo XSL
O elemento raiz que declara um documento ser uma folha de estilo XSL
e o elemento <xsl:stylesheet> ou <xsl:transform>. Esses dois elementos s
ao
sin
onimos e s
ao as tags mais externas de um documento XSL.
249
O modo correto de declarar uma folha de estilo XSL de acordo com a re-
comendac
ao W3C XSLT:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
ou
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
Obs.:
1. Para obter acesso aos elementos, atributos e caracterstica do XSLT, deve-
se declarar o namespace XSLT no incio do documento;
2. O xmlns:xsl=http://www.w3.org/1999/XSL/Transformidentifica a Re-
comendac ao NameSpace oficial do W3C. Caso utilize este namespace, deve
incluir o atributo version=1.0.
O restante da declarac
ao na folha de estilo XSL e referente a como transfor-
mar o documento XML. Essa transformac ao e realizada utilizando os principais
elementos XSLT:
< xsl : template >;

< xsl : value of >;
< xsl : f or each >;
< xsl : sort >;
< xsl : if >;
< xsl : choose >;
< xsl : apply templates >.
Apos a definic
ao do arquivo XSL e preciso associar este arquivo no docu-
mento XML. A instruc ao que deve ser includa no documento XML para que o
interpretador XML faca uso da folha de estilo XSL definida e:
<?xml-stylesheet type="text/xsl" href="localiza
c~ao do arquivo.xsl"?>
A figura 24.2 mostra o arquivo XML com esta associac
ao. A figura 24.1 e a
declarac
ao da folha de estilo para esse documento XML. A figura 24.3 mostra a
visualizac
ao do documento XML no browser utilizando a folha de estilo definida
anteriormente. Ao abrir o documento XML o browser transforma o documento
XML em HTML.
24.7 Elemento <xsl:template>

O elemento <xsl:template> e utilizado para construir templates. Cada template
contem regras para aplicar quando um n o (elemento) especfico e combinado.
O atributo match desse elemento e usado para associar um template com um
elemento XML ou definir um template para toda uma sec ao de um documento
250
Figura 24.2: Documento XML com linkpara a folha de estilo XSL
Figura 24.3: Visualizac

ao do arquivo XML no browser
XML. Para associar todo um documento XML o valor do atributo match=/.

Para associar apenas a um elemento do documento XML o valor do atributo
match=nome do elemento. O valor do atributo match e uma express
ao XPath.
A figura 24.1 mostra um exemplo do uso do elemento <xsl:template>.
24.8 Elemento <xsl:value-of>

O elemento <xsl:value-of> e usado para extrair o valor de um elemento no
documento XML e adicion a-lo ao documento resultado. O atributo select desse
elemento informa qual o elemento que ser
a extrado o valor. O valor do atributo
select e uma express
ao XPath. A figura 24.1 mostra um exemplo do uso do
elemento <xsl:value-of>.
251
24.9 Elemento <xsl:for-each>

O elemento <xsl:for-each> permite a realizac ao de loops no XSLT. Esse ele-
mento e usado para selecionar todos os elementos XML de um determinado
tipo. O atributo select desse elemento seleciona o elemento no documento XML
que sera processado. O valor desse atributo e uma expressao XPath. A figura
24.1 mostra um exemplo do uso do elemento <xsl:for-each>.
O elemento <xsl:for-each> tambem pode ser usado para filtrar a sada de
um documento XML. Basta acrescentar um criterio de selec ao ao atributo se-
lect desse elemento. Por exemplo, <xsl:for-each select=catalog/cd[artist=Bob
Dylan]>, mostra apenas que o cat alogo com o nome de artista Bob Dylan
ser
a colocado no documento de sada. Os operadores de filtro s ao: = (igual);
!= (diferente); &lt (menor que); &gt (maior que).
24.10 Elemento <xsl:sort>

O elelemento <xsl:sort> e usado para ordenar a sada de um documento. Para
ordenar a sada, insere-se esse elemento dentro do elemento <xsl:for-each>. O
atributo select desse elemento informa por qual elemento XML ocorre a or-
denac
ao. A figura 24.4 mostra o documento XML da figura 24.2 com a sada
ordenada pelo elemento artist.
Figura 24.4: Arquivo XSL ordenando a sada de um documento

24.11 Elemento <xsl:if>

O elemento <xsl:if> e usado para realizar testes condicionais. Para realizar
um teste condicional, basta inserir esse elemento dentro do elemento <xsl:for-
each>. O atributo test contem a express ao booleana. A figura 24.5 mostra o
documento XSL com o teste condicional, o qual seleciona apenas os cds com
precos maiores que 10.
252
Figura 24.5: Arquivo XSL com teste condicional
24.12 Elemento <xsl:choose>

O elemento <xsl:choose> e usado em conjunto com os elementos <xsl:when> e
<xsl:otherwise> para expressar m
ultiplos testes condicionais. A mostra o uso do
elemento <xsl:choose>. Neste exemplo, os elementos cd que possui preco maior
que 10 aparecem pintados de rosa e os outros aparecem normais no documento
de sada.
Figura 24.6: Arquivo XSL com m

ultiplos testes condicionais
24.13 Elemento <xsl:apply-templates>

O elemento <xsl:apply-templates> aplica um template ao elemento corrente ou

aos filhos do elemento no corrente. Se adicionar o atributo select ao elemento
<xsl:apply-templates>, o template s o sera aplicado aos elementos filhos que
combinem com o valor do atributo. O valor do atributo select pode ser usado
para especificar a ordem na qual os n os filhos s
ao processados. A figura 24.7
mostra um exemplo com a utilizacao desse elemento. A figura 24.8 mostra como
e a visualizac
ao do documento resultado.
Apesar do XSL ter elementos de loop, condic oes de teste, e etc., as p
aginas
Web em XML e XSL ainda sao est aticas como o HTML.
253
Figura 24.7: Arquivo XSL com o uso do elemento <xsl:apply-template>
24.14 XSL no lado Cliente

Foi explicado anteriormente como o XSL pode ser usado para transformar um
documento XML em HTML. O truquefoi adicionar uma descric ao XSL no
arquivo XML e deixar a transformac ao para o browser. Embora isso funcione
bem, n ao e sempre desejado incluir a referencia ao XSL no arquivo XML essa
soluc
ao n
ao funcionaria com um navegador sem nenhuma facilidade XSL.
Uma soluc ao mais vers
atil e usar o JavaScript para fazer a transformac
ao de
XML para HTML. Usando-se JavaScript pode-se:
Permitir que o JavaScript faca um teste de navegac

ao especfico;
Usar diferentes modelos de estilo de acordo com o navegador e/ou as
necessidades de usu
ario.
Usando JavaScript e possvel transformar dados de um formato para outro,
suportando diferentes navegadores e diferentes necessidades dos usu
arios.
24.15 XSL no lado Servidor

A soluc
ao apresentada anteriormente utilizando JavaScript esbarra no prob-
lema de o browser n ao suportar um parser XML, pois a transformac ao n
ao
254
Figura 24.8: Visualizac

ao do arquivo XSL com uso do <xsl:apply-template>
funcionaria.
Para disponibilizar os dados XML para todos os tipos de navegadores, o
documento XML e transformado no servidor e enviado como HTML puro para
o browser. Isso pode ser feito utilizando a linguagem ASP.
24.16 Processadores XSLT

Os processadores XSLT aplicam uma folha de estilo XSLT a um documento
XML e produz um documento resultado. Alguns exemplos de processadores:
Saxon, XT, MSXML3, Xalan (Apache) e os browsers (IE 6.0 e NetScape 6.0).
255
Captulo 25
Gerenciador de Conte
udo
Web Zone/Plone
25.1 Gest
ao de Conte
udo
Os produtos e servicos de informac
ao dados, textos, imagens, sons, softwares,
etc. sao identificados na rede com o nome generico de conte udos. A ideia
basica da Gestao de Conte udos (GC) e agilizar o processo de criac
ao, gest
ao
e publicac
ao de informacao. Em geral, os sistemas de gest ao de conteudos
automatizam o processo de gest ao e publicac
ao e permitem que usu arios n
ao
tecnicos possam criar conte
udos com maior facilidade.
O processo de gestao de conteudo, figura 25.1, envolve as seguintes etapas:
1. Criac
ao de documentos;
2. Revis
ao de documentos;
3. Inclus
ao de metadados (Indexac
ao) e controle de qualidade;
4. Publicac
ao;
5. Revis
ao peri
odica
6. Arquivamento ou eliminac
ao dos documentos.
Figura 25.1: O processo de gest

ao de conte
udo
O processo de gest ao pode ser representado em tres partes b

asicas: criac
ao,
gest
ao e publicac
ao. A fase de gestao envolve as etapas de indexac
ao e controle
de qualidade, revisao, arquivamento e eliminacao de documentos.
256
Os componentes do gerenciamento de conte udo s

ao a administrac
ao de conteudo,
gerenciamento de workflow, acesso e seguranca, bem como a customizac ao e in-
tegrac
ao com sistemas legados.
Os sistemas de gest ao de conteudo sao uteis em diversas aplicac
oes, como
por exemplo, comunidades pr aticas, portais corporativos e sites editoriais.
25.2 Sistema de Gest

ao de Conte
udo
Em geral, um sistema de gest ao de conteudo e composto por m odulos que
fornecem servicos que garantem um processo mais agil na criac
ao, gest
ao e pub-
licac
ao de conte
udos. As funcionalidades essenciais existentes nesses sistemas
s
ao:
Gest
ao de usu arios e de seus direitos permite o controle de acesso por usu arios,
incluindo ferramentas de criac
ao de perfis de usu
arios, autenticac
ao, au-
torizac
ao e auditorias;
Cria
cao, edi
cao e armazenamentos de conte udos suporte ` a criac
ao, edic
ao
e manipulac
ao de conte
udos, considerando m
ultiplos tipos (
audio, vdeo,
imagem, xml, html, texto, etc.);
Metadados (propriedades que descrevem o conte udo) descrevem carac-
tersticas importantes do conteudo como descric
ao, autor, linguagem, data
da criacao, data da revis
ao, etc. Os metadados possibilitam o controle de
acesso, controle de qualidade, classificac
ao e eliminacao autom atica de
documentos;
Gest
ao de qualidade inclui regras associadas aos tipos de conteudo que per-
mitem controle e acompanhamento do ciclo de vida. Um sistema wor-
flow consiste na automatizac
ao de procedimentos na qual documentos, in-
formac
oes ou tarefas s
ao passadas de um participante a outro, governado
por regras;
Classifica
cao, indexacao e busca de conte udo inclui mecanismos autom-
atizados de classificac
ao e indexac
ao e de recursos de busca eficientes
baseados em metadados;
Gest
ao de interface com usu arios o conteudo e independente da l ogica da
aplicac
ao e da apresentacao visual. A publicacao e din
amica em funcao
do usu ario e do dispositivo de sada. O acesso ao conte udo e controlado
e pode ser agrupado em tres areas de controle: Acesso p ublico, Acesso
restrito por licenca e acesso privilegiado (controlado a partir de regras

relacionadas ao conte udo e usuario);
Sindicalizac
ao (syndication) tecnica que permite compartilhar informac
ao
entre diferentes sites por meio do formato RSS;
Gest
ao de versoes permite manipular diferentes vers
oes do site, ou de um
conjunto de conte
udos;
Grava
cao das a c
oes e possibilidade de desfaz e-las permite que se recu-
pere de erros. Todas as mudancas no site (incluindo mudancas na l
ogica,
apresentac
ao e conte
udo) podem ser desfeitas.
257
No mercado de gest ao de conteudos, o ambiente Zope, uma framework para

gestao de conte
udos, e o Plone, sistema de gest
ao de conte
udos, ambos de codigo
aberto, tem atrado um n umero crescente de empresas e usu arios.
Obs.: Um framework (literalmente: moldura, esqueleto, armac ao) e um
am algama de servicos de softwaresat omicos coerentes. Considerando como
tijolosde base, estes servicos sao montados para formar uma aplicac ao. A
equipe pode concentrar-se nas regras de neg ocios e n
ao nos aspectos tecnicos
dos projetos.
25.3 Zope
O Zope (Z Object Publishing Environment) e uma plataforma de desenvolvi-
mento de aplicacoes Web baseada em Python e oferece um sistema de gest ao
de conteudos, onde o usu ario poder publicar e gerenciar o conte udo Web. E
um ambiente totalmente Orientado a Objetos e o permite o desenvolvimento
via Web. O Zope integra um grande n umero de ferramentas e funcionalidades
como uma base de dados de objetos, um m odulo de publicacao de objetos Web
e uma linguagem de gerac ao din amica de p
aginas.
O Zope e um ambiente multiplataforma (funciona em Unix, Linux, Mac Os
e Windows). E registrado com a licenca ZPL (Zope Public License), compatvel
com GPL (General Public License).
Diferente das outras solucoes do mercado, a finalidade do Zope nao e publicar
p
aginas HTML, mas objetos que podem ser montados automaticamente a partir
de componentes cujo comportamento, dados e a aparencia s ao configur aveis pelo
projetista do site. Esta abordagem torna o Zope mais apto ` a publicacao de
conte
udo Web que os outros produtos.
A arquitetura do Zope, mostrada na figura 25.2, e constituda pelos seguintes
modulos:
Servidor Web (ZServer) O Zope possui seu pr oprio servidor web, o Zope
Server, e dispensa a presenca de qualquer outro servidor web. Entretanto
n
ao impede a utilizac
ao de outro servidor web como Apache e Microsoft
IIS. ;
Banco de dados orientado a objetos (ZODB) o Zope possui seu pr oprio
servidor de Banco de Dados Orientado a Objetos (ZODB), onde armazena
os objetos em uma representac
ao simples e eficiente, que e formada pela
classe do objeto e uma estrutura de dicion ario contendo nas chaves as
propriedades do objeto e nos valores associados às chaves que cada pro-
priedade possui;
ZClassses Funcionam como molduras para os novos objetos no Zope. S ao es-
truturas utilizadas para criar novos objetos Zope, que podem ter como
base outros objetos. Um objeto Zope pode ser uma pasta, um documento
DTML, um metodo, etc. ZClasses podem ser criadas e ampliadas uti-
lizando apenas a interface web;
Zope Products S
ao produtos implementados em Python;
Integra
cao com banco de dados relacionais O Zope apresenta componentes
de acesso a v
arios bancos de dados, por exemplo, MYSQL, Oracle, Post-
Grees, Interbase, etc;
258
Figura 25.2: Arquitetura do Zope
Suporte a linguagens scripts Suporte a Phyton, ZPT (Zope Page Templates)

e DTML (Document Template Markup Language). A ZPT permite a
criac
ao de modelos de paginas para apresentacao. A DTML e uma lin-
guagem de criac
ao de scripts que permite ligar dados din
amicos e modelos,
definindo a apresentac
ao visual desses dados;
Interface Web de gerenciamento e desenvolvimento Zope apresenta uma
poderosa interface de gerenciamento e desenvolvimento (ZMI Zope Man-
agement Interface) que permite adicionar, editar e remover objetos, config-
urar propriedades, via browser padrao. Inclui acesso via ftp ou WebDAV
e oferece suporte aos protocolos DOM, XML, SOAP e XML-RPC.
A ideia principal em torno do Zope e a construcao de um ambiente de

publicacao de objetos. Nesse contexto, elementos constituintes de uma pagina
HTML s ao vistos como objetos que podem ser publicados e gerenciados atraves
do Zope. Sua arquitetura flexvel e baseada em componentes atende a diversas
aplicac
oes:
Gerenciar Websites o Zope inclui recursos como a possibilidade de delegac ao

de acesso a diferentes nveis, separac
ao do conte
udo, logica e apresentac
ao,
controle de acesso, controle de vers oes, seguranca, etc;
Construir sistemas de gest ao de conte udo a arquitetura Zope inclui com-
ponentes e disponibiliza produtos, que fornecem ferramentas que possi-
259
bilitam criar, gerenciar e publicar conte

udos, de modo f
acil e seguro, por
usuarios n
ao tecnicos;
Desenvolver aplica c
oes Web personalizadas o Zope forenece um frame-
work com aplicacoes sofisticadas, como comercio-eletr
onico, portais, f
oruns
e aplicac
oes personalizadas. O Zope fornece componentes funcionais de
acesso a dados, seguranca e personalizac ao, que integrados facilitam a
construcao de aplicac
oes Web rapidamente;
Desenvolver portais corporativos o Zope possibilita o desenvolvimento de
um site organizacional ou de uma comunidade de usu arios, tal que o
conteudo, como notcias, documentos, eventos, seja fornecido por mem-
bros da organizac
ao. O ambiente Zope, atraves de sua arquitetura flexvel
e de produtos desenvolvidos pela comunidade de usu arios, especialmente o
Plone (um produto para portais), fornece elementos necess arios para a con-
struc
ao r
apida de um portal (apresentac ao e personalizac
ao, organizac
ao
e gerenciamento, integrac
ao com diversas fontes de dados, mecanismos de
indexac
ao e busca, seguranca, escalabilidade, etc).
25.4 Plone
O Plone e um sistema gest ao de conte
udo livre e de c
odigo aberto que roda
em servidores Zope. Surgiu de uma evoluc ao do CMF (Content Management
Framework) do Zope. O Plone foi escrito em Python e roda sobre o Zope o
CMF. O Plone vem com um sistema de workflow, seguranca e func oes pre-
configuradas, um conjunto de tipos de conte udo e suporte a v
arias lnguas. O
Plone nao substitui o CMF, ele o complementa em funcionalidade e tambem
em ambig uidade de interface com usu ario, apresentando uma interface mais
amigavel para o usuario final. A figura 25.3 mostra a arquitetura do Zope,
CMF e Plone.
Algumas caractersticas do Plone:
Internacionaliza
cao a interface de usu
arios e traduzida para diversas lnguas;
Usabilidade permite desenvolver sites com alto nvel de usabilidade e acessi-
bilidade;
Personalizac
ao de templates o Plone separa o conte
udo do template no qual
o conte
udo est
a sendo exibido. Os templates do Plone sao escritos em
c
odigos HTML com folhas de estilo CSS;
Personalizac
ao de registro de usu arios o Plone possui um completo sis-
tema de registro de usu arios, onde e possvel personalizar o registro de
usu
arios. E possvel usar informac
oes de usu arios de outros bancos de
dados relacional (LDAP, AD, e outros);
Workflow e seguran ca o workflow controla a l ogica de processamento de
conte udo de um site. E possvel configurar o workflow na web utilizando
ferramentas gr aficas. Para cada item de conte udo em um site Plone e
possvel construir uma lista de usu arios que podem acess a-lo e se est
ao
habilitados a interagir com este conte udo (editar, ver, excluir, comentar,
etc.);
260
Figura 25.3: Arquitetura Zope, CMF e Plone
Extensvel como o Plone e de c

odigo aberto e possvel alter
a-lo sem problemas.
Com ferramentas de desenvolvimento como Archetype, e possvel gerar e
alterar c
odigo do Plone por meio da Web;
Personaliza c
ao de conte udo o administrador de sites pode desenvolver seus
proprios tipos de conte
udos e gerenci
a-los conforme as necessidades. Com
a ferramenta Archetype, e possvel gerar novos tipos de conte
udo usando
ferramentas de UML;
Comunidade Plone uma das melhores caractersticas do Plone e comunidade
de desenvolvedores e empresas que prestam suporte ao desenvolvimento.
Os tipos b
asicos de conte
udo do Plone s
ao:
Documento apresenta informacoes est

aticas para o usu o mais usado e
ario. E
pode ser considerado como uma p agina de um site;
Evento representam reunioes, eventos, encontros, semin

arios, e s
ao utilizados
nas pesquisas por t
opico de calendario;
Arquivo objetos podem conter arquivos passveis serem baixados;
Pasta serve para adicionar outros tipos de conte udo. Pode ser usada para
definir vis
oes de informac como uma pasta no disco
oes personalizadas. E
rgido;
Imagem e uma imagem do tipo GIF ou JPEG;
Link s
ao enderecos Web;
261
Notcia contem pequenos artigos e podem possuir ttulo assim como uma de-
scric
ao opcional.
Algumas definic
oes relacionadas ao Plone:
Portlet Um site Plone possui uma tres colunas por padr ao. As colunas da
esquerda e da direita possuem uma serie de caixas que mostram algum
tipo de informac
ao. Cada uma dessas caixas e chamada de portlet;
ZPT (Zope Page Template) e um sistema de templates usados pelo Plone

para exibic
ao de algum conte
udo;
Plone workflow por meio das permiss oes padr ao (pendente, p ublico, privado
e esboco) do workflow Plone e possvel criar nveis de acesso a informac
oes,
vis
oes de conte udos diferenciadas e regras de administrac ao de conteudo
especficas para cada tipo de conte udo;
Archetype e um framework para o desenvolvimento automatizado de produtos

(conte
udos) no Plone;
ArchGenXML e uma ferramenta de gerac ao de c

odigo que permite desen-
volver novos tipos de conte
udo por meio de um modelo UML.
O Plone e hoje a mais recomendada opc ao para criac

ao, publicac
ao e edic
ao
de portais web. Ele pode ser usado como um servidor para intranets ou ex-
tranets, um sistema publicador de conte udos e uma ferramenta de colaborac ao
interativa. O Plone roda em diversos sistemas operacionais (como Linux, Win-
dows, Solaris, FreeBSD e Mac OS X).
O uso do Plone esta associado a v
arios casos de sucesso no Brasil e no mundo.
No Brasil, pode-se citar o projeto Interlegis e o Serpro. O proposito do Interlegis
e integrar as casas do poder legislativo e Serpro e uma empresa especializada
em fornecer servicos de TI para organizacoes publicas federais.
262
Captulo 26
Web Services
26.1 O que
e Web Services?
Web Service e um componente de software identificado por uma URI que in-
depende de implementac ao ou de plataforma e pode ser descrito, publicado e
invocado sobre uma rede por meio de mensagens padr ao XML. As mensagens
XML s ao transportadas usando protocolos padr oes da Internet. Com web ser-
vice e possvel realizar a integrac
ao entre sistemas desenvolvidos em diferentes
linguagens e plataforma, e disponibilizar servicos interativos na Web. E uma
tecnologia de padr ao aberto e padronizada pelo W3C.
A arquitetura do Web Service e constituda por tres componentes b asicos:
o servidor de registro (broker server ou service registry), o provedor de servicos
(service provider) e o solicitante de servicos (service requestor). As interac oes
entre esses componentes s ao de busca, publicacao e interac
ao de operacoes.
Na operac ao de publicacao o provedor publica a descric ao do servico de
tal forma que um solicitante possa localiz a-la. Na operac ao de busca o solici-
tante obtem a descricao do servico diretamente ou consulta o servidor de registro
procurando pelo tipo de servico desejado. Essa operac ao pode ser executada em
duas fases distintas: desenvolvimento ou execuc ao. Na operac ao de interacao
o solicitante chama ou inicia uma interac ao com o provedor, em tempo de ex-
ecuc
ao, utilizando os detalhes contidos na descric ao do servico para localizar,
contactar e chamar o servico. A figura 26.1 mostra os componentes e a interac ao
entre eles.
O provedor de servicos representa a plataforma que hospeda o web service
permitindo que os clientes acessem o servico. O provedor de servicos fornece o
servico e e responsavel por publicar a descric ao do servico que prove. O solic-

itante de servicos e a aplicacao que est
a procurando, invocando uma interac ao
com o web service, ou seja, requisita a execuc ao de um servico. O solicitante de
servico pode ser uma pessoa acessando por meio do browser ou uma aplicac ao
realizando uma invocac ao aos metodos descritos na interface do web service. O
servidor de registro e um reposit orio central que contem a descric
ao (informacao)
de um web service, e e por meio do servidor de registro que essas descric oes sao
publicadas e disponibilizadas para localizac ao.
Os clientes buscam por servicos no servidor de registro e recuperam in-
formacoes referentes ` a interface de comunicac ao para os web service durante
263
Figura 26.1: Componentes b

asicos da arquitetura do Web Service
a fase de desenvolvimento ou durante a execuc ao do cliente, denominadas in-

terac
ao estatica (static bind) e interacao din
amica (dinamic bind), respecti-
vamente. Na interac ao est
atica, o cliente recupera a assinatura do servico,
necess aria `
a codificac
ao. Na interac
ao dinamica, o cliente recupera os valores
de par ametros e a localizac
ao do servico.
O ciclo de vida de um web service compreende quatro estados distintos,
figura 26.2:
Publicac
ao processo, opcional, por meio do qual o fornecedor do web services
da a conhecer a existencia do seu servico, efetuando o registro do mesmo
no reposit
orio do web service;
Descoberta processo, opcional, por meio do qual uma aplicacao cliente toma
conhecimento da existencia do web services pretendido pesquisando num
reposit
orio UDDI;
Descri
cao processo pelo qual o web service exp oe a sua API (documento
WSDL). Desta maneira a aplicacao cliente tem acesso a toda a interface
do web service, onde encontram descritas todas as funcionalidades por ele
disponibilizadas;
Invoca
cao (Mensagens) processo pelo qual o cliente e o servidor interagem,
por meio do envio de mensagens;
A conjugac
ao desses quatro estados permite constituir o ciclo de vida de um
web service:
O fornecedor constroi o servico utilizando a linguagem de programac
ao que
entender;
De seguida, especifica a interface/assinatura do servico que definiu em
WSDL;
264
Figura 26.2: Ciclo de vida do web service
Apos a conclus
ao dos dois primeiros passos, o fornecedor registra o servico
no UDDI;
O utilizador (aplicac
ao cliente) pesquisa num reposit
orio UDDI e encontra
o servico;
A aplicac
ao cliente estabelece a ligac
ao com o web service e estabelece um
di
alogo com este, via mensagens SOAP.
A interac
ao entre os web services se da sob varios protocolos abertos, em
diferentes nveis de abstrac
ao. Os protocolos utilizados para realizar a comu-
nicac
ao s
ao 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 comunicac

ao de Web services
As mensagens trocadas sao formatadas no protocolo SOAP, o que permite

a interoperabilidade entre diferentes plataformas, em um processo denominado
serializac
ao XML. Porem, antes que as mensagens SOAP sejam trocadas, suas
caractersticas s
ao explicitadas por meio de documentos WSDL, que descrevem
quais dados estar ao sendo trocados, e como estes dados estar
ao organizados nas
mensagens SOAP. Adicionalmente, os servicos dos web services podem ser pub-
licados atraves de UDDI, que e um formato utilizado para seu armazenamento
265
em reposit orios disponveis na Internet. Assim, se um desenvolvedor precisar

resolver uma determinada tarefa, pode encontrar o web service que mais se
adequar ` a sua necessidade.
Como os firewalls convencionais e proxies n ao bloqueiam a porta utilizada
pelo protocolo HTTP, n ao existem grandes restric
oes para o uso deste tipo de
aplicac
ao em redes de longa dist ancia.
Pode-se definir, resumidamente, o web service como sendo um servico 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 disseminacao no uso de web services nos u
ltimos anos incentivou o mercado
a oferecer uma grande variedade de ferramentas e aplicac oes para prover suporte
a essa tecnologia. Atualmente, as principais plataformas para web services s ao:
Sun Microsystems, IBM, BEA, Apache, Systinet e Microsoft.
26.2 SOAP
O SOAP (Simple Object Access Protocol) e um protocolo leve para troca de
informacoes em um ambiente descentralizado e distribudo que permite comu-
nicac
ao entre aplicacoes de forma simples e completamente independente de
sistema operacional, linguagem de programac o protocolo
ao ou plataforma. E
de comunicac ao para os Web Services.
A comunicac ao e realizada por meio de trocas de mensagens, transmitidas
em formato XML, incluindo os par ametros usados nas chamadas, bem como
os dados de resultados. Tambem pode ser utilizado para invocar, publicar e
localizar web services no registro UDDI.
Parte da sua especificac ao e composta por um conjunto de regras de como
utilizar o XML para representar os dados. Outra parte define o formato de
mensagens, convenc oes para representar as chamadas de procedimento remoto
(RPC Remote Procedure Calls) utilizando o SOAP, e associac oes ao protocolo
HTTP. O protocolo HTTP e o u nico protocolo padronizado pelo SOAP, mas
existem algumas implementac oes que suportam outros protocolos como SMTP,
TCP/IP, FTP e etc.
Uma mensagem SOAP nada mais e do que um fragmento XML bem formado,
encapsulado por um par de elementos SOAP. A mensagem SOAP consiste dos
seguintes elementos, figura 26.4:
Envelope toda mensagem SOAP deve conte-lo. E o elemento raiz do docu-
mento XML. Define o incio e o fim das mensagens;
Header e um cabecalho opcional. Ele carrega informac

oes adicionais, como
exemplo, se a mensagem deve ser processada por um n o intermediario.
Quando utilizado, o Header deve ser o primeiro elemento do envelope;
Body e obrigat
orio e contem o payload, os dados em XML a serem transporta-
dos. O elemento Body possui um campo opcional Fault, usado para car-
regar mensagens de status e erros retornadas pelos nosao processarem
a mensagem;
RPCs ou chamadas remotas de procedimento s ao chamadas locais a metodos
de objetos (ou servicos) remotos. Portanto, pode-se acessar os servicos de um
266
Figura 26.4: Estrutura da mensagem SOAP
objeto localizado em outro ponto da rede, atraves de uma chamada local a este
objeto. Cada chamada ou requisic ao exige uma resposta.
O processo de uma chamada RPC: Antes de serem enviadas pela rede, as
chamadas de RPC (emitidas pela aplicac ao cliente) s
ao encapsuladas (ou serial-
izadas) segundo o padr ao SOAP. O servico remoto, ao receber a mensagem faz
o processo contr ario, desencapsulando-a e extraindo as chamadas de metodo.
A aplicac
ao servidora ent ao processa esta chamada, e envia uma resposta ao
cliente. O processo ent ao se repete: a resposta e tambem serializada e enviada
pela rede. Na m aquina cliente, esta resposta e desencapsulada e e repassada
para a aplicac
ao cliente.
A especificac
ao SOAP define as seguintes informac oes, como necess
arias em
toda chamada de RPC:
A URI do objeto alvo;

O nome do metodo;
Os par
ametros do metodo (requisic
ao ou resposta);
Uma assinatura do metodo opcional;
Um cabecalho (header) opcional.
26.3 WSDL
O WSDL (Web Services Description Language) e uma linguagem baseada em
XML, utilizada para descrever um web service. Um web service deve definir
todas as suas interfaces, operac oes, esquemas de codificac ao, o conteudo das
mensagens, onde o servico est a disponvel e quais os protocolos de comunicac ao
s
ao usados para conversar com o servico e entre outros neste documento. Um
documento WSDL define um XML Schema para descrever um web service.
A descric
ao de um servico consiste de duas partes, figura 26.5: definic ao de
implementac ao do servico e definic
ao da interface do servico. A separac
ao entre
as duas camadas permite que elas sejam utilizadas separadamente.
A parte de definic
ao de interface do servico descreve o web service, incluindo
metodos que s ao invocados e par ametros que s ao enviados. A parte de definicao
267
Figura 26.5: Camada de descric

ao de servicos da WSDL
de implementac
ao de servicos descreve como uma interface de servico e im-
plementada por um provedor: onde o servico est a instalado e como pode ser
acessado. As descric
oes dos elementos das duas partes:
Binding descreve protocolos, formato de data, seguranca e outros atributos

para uma interface (portType) em particular;
Porttype informa elementos de operac

oes do web service;
Message define entrada e sada de dados referentes a operac
oes;
Type define tipos de dados complexos em uma mensagem;

Service contem uma colec
ao de elementos port com elementos binding;
Port e a combinacao de um binding com endereco de rede, fornecendo o en-

dereco alvo para a comunicac
ao dos servicos.
Tao logo o cliente tenha acesso ` a descric

ao do servico a ser utilizado, a
implementac ao do Web Service pode ser feita em qualquer linguagem de pro-
gramacao. Normalmente s ao utilizadas linguagem construdas para interac ao
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 obtem a descric ao do servico (atraves da localizac
ao do
respectivo documento WSDL), e em seguida constr oi a mensagem, passando os
tipos de dados corretos (par ametros, etc) de acordo com a definic ao encontrada
no documento. As duas partes envolvidas em uma interac ao web service pre-
cisam ter acesso ` a mesma descric ao WSDL para conseguirem entender uma ` a
outra. Em seguida, a mensagem e enviada para o endereco onde o servico est a
localizado, a fim de que possa ser processada. O web service, quando recebe esta
mensagem valida-a conforme as informac oes contidas no documento WSDL. A
partir de ent ao, o servico remoto sabe como tratar a mensagem, sabe como
processa-la (possivelmente enviando-a para outro programa) e como montar a
resposta ao cliente.
268
26.4 UDDI
Para que um servico seja utilizado e necess ario que o cliente consiga localiz a-
lo, e essa localizac
ao pode ser feita por meio do UDDI (Universal Description,
Discovery and Integration), que e uma especificac ao tecnica para descrever,
descobrir e publicar web services.
Uma implementac ao de UDDI corresponde a um registro web service, que
prove um mecanismo para busca e publicac ao de web services. Um registro
UDDI contem informac oes categorizadas sobre os servicos e as funcionalidades
que eles oferecem, e permite a associac ao desses servicos com suas informac oes
tecnicas, geralmente definidas usando WSDL.
O UDDI possui um componente central chamado UDDI Project, que ma-
nipula um registro global e p ublico chamado business registry. A informac ao
oferecida pelo bussines registry consiste de tres componentes: white pages, yel-
low pages e green pages.
A informacao fornecida por um registro UDDI pode ser comparada ` a uma
lista telef
onica. As p aginas brancas (white pages), fornecem informac oes tais
como nome da organizac ao, contato e identificadores. As p aginas amarelas
(yellow pages) s ao compostas por um ndice de servicos e produtos e as p aginas
verdes (green pages) contem informac oes a respeito de transac
oes, descric
oes de
servico e invocac
ao de aplicacoes.
As informacoes contidas em arquivos de descric ao de servico (WSDL) com-
pletam aquelas que est ao no registro. No entanto, UDDI n ao fornece suporte
a varios tipos de descric
ao de servico, mas n ao suporta a criacao de descric
oes
WSDL de forma direta.
Uma descric ao WSDL completa consiste da combinac ao dos documentos de
interface e de implementac ao de servico. A primeira e publicada no registro
UDDI como businessservice e a segunda como tmodel.
26.5 Seguranca
A seguranca no envio de mensagens SOAP e um t opico importante. Em um nvel
mais baixo, mensagens SOAP podem ser trocadas pela rede utilizando HTTPS
ao inves de HTTP. Como HTTPS utiliza SSL no seu transporte, fica garantida
a protec
ao contra possveis intervenc
oes. Alem disso, o cliente e servidor podem
verificar cada um suas respectivas identidades.
Embora HTTPS resolva o problema de protec ao das mensagens contra possveis
invasores, este n ao ajuda muito quando se necessita da seguranca necess aria
para a autenticac ao de usuarios de web services especficos. Estes servicos ir

ao
fornecer algum tipo de combinac ao de usuario/senha durante a fase inicial de
registro no servico e ent
ao esta ser
a utilizada para acessos futuros. N ao h
a ainda
um padr ao de autenticacao para Web services, mas pode utilizar os firewalls,
VPNs, NTFS, produtos de single-in para oferecer a autenticac ao e autorizac
ao
de usuarios.
269
Parte VI
Redes de Comunica
c
ao
270
Captulo 27
T
ecnicas B
asicas de
Comunicac
ao
27.1 Base Te
orica da Comunica
cao de Dados
As informac oes podem ser transmitidas por fios fazendo-se variar alguma pro-
priedade fsica, como voltagem ou corrente. Representando o valor dessa volt-
agem ou corrente como uma func ao de tempo com uma valor u nico, f(t), pode-se
criar um modelo para o comportamento do sinal e analis a-lo matematicamente.
Tal an
alise e conhecida como An alise de Fourier e ela afirma que qualquer
funcao peri
odica razoavelmente est avel, g(t), com o perodo T pode ser con-
struda como a soma de um n umero (possivelmente infinito) de senos e co-senos.
A decomposic ao dos harm onicos que comp oe que comp oe a func
ao e a chamada
serie de Fourier.
Nenhum recurso de transmiss ao e capaz de transmitir sinais sem perder
parte da energia no processo. Se todos os coeficientes da seria de Fourier fossem
igualmente reduzidos, o sinal resultante seria reduzido em amplitude, mas n ao
seria distorcido. Infelizmente, todos os meios de transmiss ao reduzem diferentes
componentes de Fourier por diferentes valores e, em conseq uencia disso, intro-
duzem distorc oes. Em geral, as amplitudes s ao transmitidas sem reduc ao, de
0 a alguma freq uencia fc, com todas as freq uencias acima dessa freq uencia de
corte sendo atenuadas A faixa de freq uencias transmitidas sem serem fortemente
atenuadas denomina-se largura de banda. Na pr atica, o corte n ao e ntido; as-
sim, muitas vezes a largura de banda varia desde 0 ate a freq uencia em que a
metade da potencia e transmitida.

A largura de banda e uma propriedade fsica do meio de transmiss ao, e
em geral depende da construc ao, da espessura e do comprimento do meio. Em
alguns casos um filtro e introduzido no circuito para limitar o volume de largura
de banda disponvel para cada cliente. Por exemplo, uma linha telef onica pode
ter uma largura de banda de 1MHz para curtas dist ancias, mas as empresas de
telefonia limitam essa faixa a cerca de 3100 Hz.
271
27.2 Taxa M
axima de Dados em um Canal
Em 1924, Henry Nyquist percebeu que ate mesmo um canal perfeito tem uma
capacidade de transmiss ao finita. Ele derivou uma equac ao expressando a taxa
m axima de dados de um canal sem rudo com largura de banda finita. Em 1948,
Claude Shannon aprofundou o trabalho e o estendeu ao caso de uma canal com
rudo aleatorio (isto e, termodin amico).
Nyquist provou que, se um sinal arbitr ario atravessar um filtro com baixa
frequencia de corte H, o sinal filtrado poder a ser completamente reconstrudo
a partir de apenas 2H amostras (exatas) por segundo. Fazer uma amostragem
da linha com uma rapidez maior que 2H/s seria in util, pois os componentes
de freq uencia mais alta que essa amostragem poderia recuperar j a teriam sido
filtrados. Se o sinal consistir em V nveis discretos o teorema de Nyquist afirma
que:
S
Maximum Data Rate = 2Hlog2 (1 + ) (27.1)
N
Se houver rudo aleat orio, a situac
ao ir
a se deteriorar mais rapidamente.
Alem disso, sempre existe rudo aleat orio (termico) presente, devido ao movi-
mento das moleculas no sistema. O volume de rudo termico presente e medido
pela relac
ao entre a potencia do sinal e a potencia do rudo, chamada relacao
sinal/rudo. Dessa forma, o principal resultado de Shannon e que a taxa m axima
de dados de um canal com rudos cuja largura de banda e H Hz, e cuja relac ao
sinal/rudo e S/N, e dada por:
S
Maximum Number of Bits/sec = Hlog2 (1 + ) (27.2)
N
Por exemplo, um canal com largura de banda de 3000 Hz com uma relac ao
sinal/rudo de 30 db nunca pode transmitir muito mais que 30000 bps, inde-
pendente da quantidade de nveis de sinal utilizados e da freq
uencia com que as
amostras s ao obtidas.
27.3 Sinais Digitais Bin

arios
Os sinais digitais binarios podem ser estudados como se fossem um sinal quadrado.
Atraves da Serie de Fourier, e possvel reconstruir um sinal quadrado a partir
da correspondente sen oide fundamental. Ao incluirmos as freq uencias harm
onicas
de ordem mpar, o sinal reconstrudo aproxima-se cada vez mais do sinal quadrado
original. A figura 27.1 ilustra a reconstituic ao de um sinal quadrado a partir da
senoide fundamental e suas harm onicas mpares ate a quinta ordem.

Assim sendo, na transmiss ao digital entre dois pontos, deveramos ter um
meio de transmiss ao com largura de faixa (banda passante) infinita, para que
o sinal digital transmitido fosse recebido sem nenhuma distorc ao. Entretanto,
fisicamente isso n ao possvel. Poderia-se pensar, ent ao, em aumentar a largura
de faixa do canal ao m aximo para atenuar as distorc oes, no entanto isso n
ao e
viavel economicamente.
A soluc
ao e adaptar o sinal digital aos tipos de degradac ao inerentes aos
meios de transmiss ao. Para isto, foram desenvolvidos dispositivos capazes de
transformar o sinal digital do computador em uma forma possvel de ser transmi-
tida pelo meio sem que ocorram danos graves. Estes dispositivos s ao chamados
272
Figura 27.1: Reconstituic

ao de um sinal bin
ario
de Modems(Modulator/Demodulator). Este equipamento executa uma trans-

formac
ao por modulacao (modem anal ogico) ou por codificac
ao (modem digital)
dos sinais digitais gerados pelo computador. A rigor, os modems digitais n ao
deveriam receber esse nome, pois eles n ao executam a modulac ao/demodulacao
do sinal digital, apenas a codificac
ao. Em complemento, os modems digitais
tambem recebem os nomes modem banda-base e modem data set. Mesmo us-
ando o modem digital, devido a`s caractersticas da onda quadrada, a transmiss
ao
s
o podera ocorrer a curtas dist
ancias e com linhas de boa qualidade.
27.4 Transmiss
ao em Banda Base
Banda base e freq
uentemente utilizada para a transmiss ao digital de dados, um
u
nico canal utiliza a largura de banda total disponvel. Assim, a transmiss ao
de um sinal em banda base consiste em enviar o sinal de forma digital atraves
da linha (forma de onda digital), ou seja, enviar os bits conforme a necessidade,
de acordo com um padr ao digital. Desde que a distancia entre o transmissor e
receptor seja de alguns quilometros, a banda de transmiss ao disponvel seja em
torno de 15 KHz e o meio de transmiss ao tenha certas caractersticas, e possvel
realizar a Codificac
ao Banda Base do sinal digital. Nesse sentido, a dist ancia
alcancada na transmissao diminui conforme aumenta a velocidade transmiss ao.
O alcance m aximo e definido como sendo a distancia m axima em que e possvel
transmitir mantendo a taxa de erro abaixo de um valor predeterminado.
27.5 Classificac
ao dos Sinais
Os sinais em Banda Base podem ser classificados quanto a durac
ao e polaridade
de seus pulsos:
Durac
ao:
o NRZ (non return to zero): cada bit 0 e representado por um pulso

OFF e cada bit 1 por um pulso ON ocupando todo o intervalo signi-
ficativo do bit;
273
RZ (return to zero): os bits 1 s

ao representados por pulsos ON com
durac
ao de meio intervalo significativo bit.
Polaridade:
Unipolar: os dois nveis tem a mesma polaridade (exemplo: 0 e +).

Esse tipo de sinal resulta em codificac ao com componente DC que n ao
leva informacao, mas consome energia. Alem disso, a ocorrencia de
uma longa seq uencia de bits 0 resulta em um sinal que n
ao apresenta
transic
oes, dificultando a sincronizac ao dos equipamentos.
Polar: este sinal possui pulsos com polaridades opostas (exemplo: o
bit 0 e representado por pulso -e o bit 1 por pulso +), zerando
a componente DC se a mensagem contiver uma proporc ao igual de
bits 0 e 1.O numero de transic
oes depender
a completamente do sinal
transmitido.
Bipolar: os sucessivos bits 1 s
ao representados com pulsos de polari-
dade alternada.
27.6 T
ecnicas de Codifica
c
ao de Linha
As diversas tecnicas de codificac
ao do sinal digital procuram gerar o sinal codi-
ficado com muitas transicoes, a fim de facilitar a recuperac
ao do sincronismo no
modem receptor (recuperac ao do relogio). Alem disso, procura-se concentrar o
espectro de transmiss ao do sinal codificado dentro de uma faixa de freq uencia
com pouco componente DC. Diversas tecnicas de codificac ao s
ao ilustradas na
figura 27.2 e descritas adiante.
Figura 27.2: Exemplos de ondas codificadas
27.6.1 Codifica
cao NRZ
Com o c odigo NRZ, o nvel do sinal e mantido constante em uma de duas
tens
oes possveis, pela duracao de um intervalo de bit. Se as duas voltagens
274
permitidas sao 0 e V, a forma de onda NRZ e dita UNIPOLAR. Este sinal tem
uma componente DC diferente de zero. Por outro lado, o sinal NRZ BIPOLAR
usa duas polaridades, +V e -V, deste modo prove uma componente DC nula.
A codificac
ao NRZ apresenta carencia de transic oes de dados, o que resulta
em um pobre desempenho na recuperac ao de relogio no receptor. A recuperacao
do rel
ogio nesse contexto significa recuperar o relogio usado no transmissor para
temporizar a codificac
ao do sinal e assim permitir a recuperac ao da informacao
no lado receptor. Esta caracterstica limita o seu uso apenas para pequenas
dist
ancias de transmissao e conex oes entre estac
oes.
27.6.2 Codifica
cao RZ
O nvel do sinal que representa o bit de valor 1 dura a primeira metade do
intervalo do bit, ap
os o qual o sinal retorna para o nvel de referencia (zero) para
o restante meio intervalo de bit. Um bit 0 e indicado por uma n ao mudanca,
com o sinal continuando no nvel de referencia (zero).
Sua principal vantagem reside no aumento das transic oes e comparac ao
com o NRZ, com uma resultante melhoria na recuperac ao do rel ogio no re-
ceptor. Nota-se que uma seq uencia muito grande de 0 resulta em um sinal sem
transic
oes, o que representa um problema para os circuitos de recuperac ao de
rel
ogio.
27.6.3 Codifica
cao AMI (Alternate Mark Invertion)
Na codificac
ao AMI (bipolar), o bit 0 e sempre codificado como nvel zero, e os
bits 1 s
ao codificados como +V ou -V, onde a polaridade e alternada para cada
ocorrencia de bit 1. A codificac
ao AMI resulta em uma componente DC nula.
A representacao AMI pode ser NRZ (100 % do tempo de bit) ou RZ (50% do
tempo de bit).
A garantia de transicao dos nveis para cada bit 1, proporciona um otimo
desempenho na recuperac ao de rel
ogio, melhorando ainda mais quando o sinal
for RZ. Esta codificac
ao apresenta ainda a capacidade de detecc ao de erro, pois
amplitudes positivas consecutivas sem uma amplitude negativa intermedi aria (e
vice-versa) constituem uma violac ao da regra AMI e indicam que ocorreu um
erro na transmiss ao. Entretanto, quando ocorrer uma seq uencia longa de zeros,
o sinal codificado fica muito tempo sem transic oes na linha, o que dificulta a
obtenc
ao do relogio de sincronismo.
27.6.4 Codifica
cao HDB-3 (High Density Bipolar with 3
Zero Maximum Tolerance)

Nesse tipo de codificac
ao, o sinal digital a ser transmitido e analisado e, cada
vez que e detectada uma seq uencia de quatro zeros consecutivos, esta seq uencia
e substituda por uma outra seq uencia padronizada. Para isso, e utilizado o
recurso da violac
ao, que consiste no uso de um pulso que tenha a mesma
polaridade que o pulso anterior (o que viola o princpio b asico do AMI).
No HDB-3, os quatro zeros consecutivos s ao substitudos pela seq
uencia 000V
ou V00V, onde Ve a violac ao, e a substituic
ao depender a do u
ltimo pulso
transmitido, observando sempre o princpio da altern ancia de pulsos. Caso o
u
ltimo pulso transmitido n ao seja uma violac ao e tenha polaridade oposta ` a
275
polaridade da violac ao anterior, transmitir a 000V. No caso em que o u ltimo

pulso transmitido seja uma violac ao ou tenha polaridade identica ` a polaridade
da violacao anterior, transmitira V00V. Essa escolha entre 000V e V00V faz
com que violac oes sucessivas sejam de polaridades opostas, o que garante a n ao
existencia de sinal DC na linha.
Na recepcao, o decodificador tem de verificar, inicialmente, a violac ao AMI
e, posteriormente, o n umero de zeros que precede esta violac ao, para determinar
se o ultimo pulso transmitido e tambem uma violac ao. Isto e feito da seguinte
forma: se na recepc ao houver dois pulsos, com mesma polaridade, separados por
tres zeros, o segundo pulso e violac
ao, logo, e eliminado. Se na recepc ao houver
dois pulsos, com mesma polaridade, separados por dois zeros, ambos os pulsos
s
ao violac
ao, logo, ambos sao eliminados. Nota-se que na codificac ao HDB-3 s ao
contornados os problemas do aparecimento do nvel DC e da falta de transic oes
para recuperac ao do sinal de rel
ogio.
27.6.5 Codifica
cao Manchester
Na codificacao Manchester, cada perodo de bits e dividido em dois intervalos
iguais. Um bit 1 bin ario e enviado quando a voltagem e definida como alta du-
rante o primeiro intervalo, e como baixa no segundo intervalo. Um bit 0 bin ario
e exatamente o oposto: primeiro baixo depois alto. Esse esquema garante que
cada perodo de bit ter a uma transicao na parte intermediaria, tornando facil
para o receptor sincronizar-se com o transmissor. Uma desvantagem da cod-
ificac
ao Manchester e que ela exige duas vezes mais largura de banda que a
codificac
ao bin
aria direta, pois os pulsos s
ao a metade da largura. Por exemplo,
para transmitir dados a 10 Mbps, o sinal precisa mudar 20 milh oes de vezes por
segundo.
A codificac
ao Manchester diferencial e uma variacao da codificac
ao Manch-
ester apresentada. Nela um bit 1 e indicado pela ausencia de uma transic ao
no incio do intervalo. Um bit 0 e indicado pela presenca de uma transic ao
no incio do intervalo. Em ambos os casos tambem existe uma transic ao na
parte intermedi aria. O esquema diferencial exige equipamento mais complexo,
mas oferece maior imunidade a rudos. Todos os sistemas Ethernet usam a
codificac
ao Manchester devido a sua simplicidade.
Figura 27.3: Codificac

oes Bin
aria, manchester e diferencial
27.7 Modulac
ao
Modulacao e o processo pelo qual alguma caracterstica de uma onda portadora
e variada de acordo com a mensagem (sinal modulante), produzindo um sinal
276
modulado cujas propriedades s ao mais compatveis com as caractersticas do

canal. Essa descric
ao e resumida na figura 27.4.
Figura 27.4: Processo de Modulac

ao
A figura 27.5 resumo a classificac

ao dos tipos de modulac
ao.
Figura 27.5: Tipos de Modulac

ao
27.7.1 Modula
cao de Onda Contnua
As linhas de transmiss ao enfrentam tres problemas principais: atenuac ao, dis-
torc
ao de retardo e rudo. Devido a esses problemas e principalmente ao fato
de a atenuac ao e a velocidade de propagac ao variarem em func ao da freq
uencia,
nao e interessante ter uma grande variedade de freq uencias no sinal. Infeliz-
mente, as ondas quadradas usadas em sinais digitais tem um amplo espectro de
frequencias e, portanto, estao sujeitas a uma forte atenuac ao e a uma distorc ao
de retardo. Esses efeitos tornam a sinalizac ao em banda base (DC) inadequada,
exceto em baixas velocidades e em dist ancias curtas.

Para contornar os problemas associados ` a sinalizacao DC e usada a sinal-
izac
ao AC. E introduzido no sinal um tom contnuo na faixa de 1000 a 2000 Hz,
denominado onda portadora senoidal. Sua amplitude, freq uencia ou fase pode
ser modulada para transmitir informac oes.
Basicamente, existem dois tipos de modulac ao de onda contnua, a anal ogica
e a digital. Pode-se citar como exemplo de modulac ao anal ogica a modulac ao
AM (Amplitude Modulation) onde a variac ao da amplitude da portadora ocorre
de acordo com a variac ao do sinal modulante. Este tipo de modulac ao tem
algumas derivac oes, tais como, AM-DSB (Double-Sideband Amplitude Modula-
tion), AM-DSB-SC (Double-Sideband Suprisse Carrier Amplitude Modulation)
277
e AM-VSB (Vestigial-Sideband Amplitude Modulation). A modulac ao FM (Fre-

quency Modulation) tem melhor qualidade que a AM por ser menos susceptvel
a rudos. Neste tipo de modulac
ao ocorre a variac
ao de freq
uencia da portadora
em funcao da variac
ao do sinal modulante. A Modulac ao PM (Phase Modu-
lation) tem como principal caracterstica a variac ao da fase da portadora em
func
ao da variac
ao do sinal modulante. A figura 27.6 mostra alguns exemplos
de modulacao analogica.
Figura 27.6: Modulac

ao Anal
ogica
A modulac
ao digital consiste em aplicar um sinal digital (bin ario) como
sinal modulante da portadora ao inves de um sinal anal ogico como ocorre na
modulac
ao anal
ogica descrita anteriormente. As modulac oes digitais mais us-
adas s
ao ASK (Amplitude Shift Keying), FSK (Frequency Shift Keying), PSK
(Phase Shift Keying). Essas tecnicas de modulac
ao s
ao representadas na figura
27.7.
Figura 27.7: Modulacao Digital: Amplitude, Frequencia e Fase
Para atingir velocidades cada vez mais altas nao basta apenas aumentar
a taxa de amostragem. O teorema de Nyquist afirma que mesmo com uma
linha de 3000Hz perfeita nao ha raz
ao para uma amostragem mais rapida que
6000Hz. Na pr atica, a maioria dos modens realizam amostragens 2400 vezes/s
e se concentra em obter mais bits por amostra.
278
O n umero de amostras por segundo e medido em baud. Durante cada baud, e

enviado um smbolo. Desse modo, uma linha de n bauds transmite n smbolos/s.
Se o smbolo consiste em 0 volts para representar um valor l ogico 0 e 1 volt para
indicar um valor l ogico 1, a taxa de bits e 2400 bps. Porem se as voltagens
0, 1, 2, 3 volts s ao usadas, cada smbolo consiste em dois bits, e assim uma
linha de 2400 bauds pode transmitir 2400 smbolos/ s a uma taxa de dados de
4800 bps. De modo semelhante, com quatro deslocamentos de fase possveis,
tambem existem 2bits/smbolo, e portanto mais uma vez a taxa de bits e o dobro
da taxa em bauds. Essa u ltima tecnica e amplamente usada e se denomina
QPSK (Quadrature Phase Shift Keying). Desse modo, a tecnica de modulac ao
determina o n umero de bits/smbolo.
Todos os modens avancados utilizam uma combinac ao de tecnicas de mod-
ulac
ao para transmitir v arios bits por baud. Com freq uencia, v
arias ampli-
tudes e v arios deslocamentos de fase s ao combinados para transmitir diversos
bits/smbolo. A figura 27.8 (b) abaixo apresenta uma estrutura de modulac ao
na qual s ao usadas quatro amplitudes e quatro fases, dando um total de 16 com-
binacoes diferentes. Esse esquema de modulac ao pode ser usado para transmitir
4 bits por smbolo. Ele e chamado QAM-16 (Quadrature Amplitude Modula-
tion). A figura 27.8 (c) permite 64 combinac oes diferentes. Diagramas como os
apresentados na figura 27.8 s ao denominados de diagramas de constelac ao.
Figura 27.8: QPSK, QAM 16 e QAM 64
Com muitos pontos no padr ao de constelac

ao, ate mesmo uma pequena
quantidade de rudo na amplitude ou fase detectada pode resultar em um erro
e, potencialmente, em muitos bits incorretos. Para reduzir a chance de um
erro, e efetuada a correc
ao de erros adicionando bits extras a cada amostra. Os
esquemas s ao conhecidos como TCM (Trellis Coded Modulation).
27.7.2 Modula
cao de Pulsos
A modulac ao por pulsos iniciou a partir da teoria da amostragem, a qual estab-

elece que a informac
ao contida em qualquer sinal anal ogico pode ser recuperada
a partir de amostras do sinal tomadas a intervalos regulares de tempo.
A modulacao por pulsos pode ser analogica ou codificada. No caso analogico,
os valores das amostras do sinal s ao transferidos para as amplitudes, durac oes
ou posic
oes de pulsos de formato fixo conhecido. No caso digital, os valores das
amostras sao convertidos para n umeros binarios que por sua vez s
ao codificados
em sequencias de pulsos que representam cada um dos valores bin arios. Um
exemplo desse tipo de modulac ao e o PCM.
279
Modula
cao de C
odigo de Pulso
O processo de transformac ao das redes telefonicas em redes totalmente digitais
tanto no que diz respeito ` a comutac
ao como ` a transmissao teve incio quando
da introduc
ao, em escala comercial, dos sistemas de transmiss ao PCM. O PCM
(Modulacao por C odigo de Pulso) transforma um sinal anal ogico em uma serie
de pulsos binarios que podem ser manipulados. Sendo assim, o objetivo da mod-
ulac
ao PCM e fazer com que um sinal anal ogico possa ser transmitido atraves
de um meio fsico com transmiss ao digital.
O processo de modulac ao PCM consiste basicamente em tres etapas, nessa
ordem: amostragem, quantizac ao e codificac
ao. A figura 27.9 ilustra o processo
de modulacao PCM, passo a passo. Uma etapa adicional chamada compress ao
pode ser inserida ap os a etapa de quantizac ao para manipular a sada desse
processo e transform a-lo em uma quantizac ao nao-linear, melhorando assim a
robustez a problemas de rudo no canal.
Figura 27.9: Pulse Code Modulation
O sinal PCM resultante e enviado atraves do canal por transmiss ao em

banda base. Esse sinal ainda pode usar alguma das tecnicas de codificac ao de
linha apresentadas anteriormente, como, por exemplo, a AMI que, inclusive,
foi desenvolvida originalmente para esse fim. Cabe ressaltar que o processo
de codificac
ao do PCM tem a func ao de transformar os valores quantificados
em uma seq uencia de bits. Essa seq

uencia de bits constitui o sinal PCM que
pode ser transmitido pelo canal. Entretanto, o sinal PCM pode ser codificado
novamente, mas agora usando uma tecnica de codificac ao de linha para ent
ao
ser transmitido pelo canal.
27.8 T
ecnicas de Multiplexa
cao
Multiplexac
ao e a transmiss
ao simult
anea de v
arios sinais por um unico canal.
Desse modo, v arias fontes com esquemas de modulac ao individuais podem ser
multiplexados em um mesmo canal. O objetivo b asico para a utilizac
ao desta
280
tecnica e economia, pois utilizando o mesmo meio de transmiss ao para diversos

canais economiza-se em linhas, suporte, manutenc ao, instalac
ao, etc.
Figura 27.10: Multiplexac

ao de 3 fontes
As principais tecnicas de multiplexac

ao s
ao FDM, TDM e WDM. Cada uma
delas ser
ao discutidas a seguir.
27.8.1 FDM - Frequency Division Multiplexing

Com a tecnica FDM (Frequency Division Multiplexing) a multiplexac ao e re-
alizada dividindo todo o espectro de freq uencia em diversos canais mais estre-
itos que sao alocadas entre os terminais em uma relac ao um para um. Ban-
das de guarda s ao usadas entre subportadoras adjacentes para n ao ocorrer so-
breposic
ao, entretanto parte da capacidade de transmiss ao e desperdicada para
esse fim. Alem disso, FDM e utilizada apenas em sistemas anal ogicos. A Figura
27.11 ilustra a tecnica segundo os eixos de tempo e freq
uencia.
Figura 27.11: FDM - Frequency Division Multiplexing
27.8.2 TDM - Time Division Multiplexing

A tecnica de multiplexacao TDM (Time Division Multiplexing) e baseada no
domnio do tempo e s o pode ser empregado em sistemas digitais. Nesse es-
quema, a linha do tempo e dividida em quadros que por sua vez e dividida em
slots. Dessa forma, o acesso ao meio e garantido atraves da alocac ao desses
slots de tempo entre as estac oes que compoe o sistema. E mais eficiente em
comparacao ao sistema anterior, entretanto necessita acrescentar bits adicionais
ao sinal original para sincronia e gerenciamento da rede. A Figura 27.12 ilustra
o esquema.
27.8.3 OFDM
O metodo de multiplexac
ao OFDM e uma tecnica de transmiss
ao multiporta-
dora que surgiu no fim da decada de sessenta como uma evolucao de FDM.
281
Figura 27.12: TDM - Time Division Multiplexing
O princpio basico em OFDM e eleger freq uencias ortogonais entre si, dito de
outra forma, deve-se garantir que nenhuma subportadora seja produto de com-
binac
ao linear das demais presentes no canal. Isso permite prescindir da banda
de guarda presente na tecnica FDM. O benefcio imediato obtido com OFDM e
a economia de largura de banda. Essa tecnica e particularmente u til nos casos
de transmiss oes sem fio, pois alem da eficiencia espectral, a tecnica OFDM se
apresenta mais robusta em relac ao aos problemas inerentes ao canal sem fio.
Figura 27.13: Comparac

ao entre uso de banda FDM e OFDM
27.8.4 WDM -Wavelength Division Multiplexing

A tecnica WDM (Wavelength Division Multiplexing) e uma variac ao da mul-
tiplexac
ao por divis
ao de frequencia empregada em canais de fibra optica. As
informacoes s
ao transportadas sobre faixas de comprimentos de onda por meio
da tecnologia fotonica.
Nesse contexto, os sinais transmitidos sao combinados em um multiplexador
optico para ser enviado atraves de um u
nico cabo de fibra
optica. Dessa forma,
a capacidade de transmiss ao e aumentada e a largura de banda da fibra e usada
efetivamente. A figura 27.14 representa o esquema de multiplexac ao por divis
ao
de comprimento de onda.
Figura 27.14: WDM -Wavelength Division Multiplexing
282
27.9 Protocolos de Acesso M

ultiplo
Basicamente existem dois tipos de enlaces: ponto-a-ponto e broadcast. O
primeiro caso consiste em um u nico remetente em uma extremidade do en-
lace e um u nico receptor na outra extremidade do enlace. O segundo tipo
pode ter m ultiplos nos remetentes e receptores, todos conectados ao mesmo,
u
nico compartilhado canal de transmiss ao. Nesse contexto surge uma quest ao:
como coordenar o acesso dos m ultiplos nos remetentes e receptores a um canal
broadcast compartilhado. Essa coordenac ao e realizada pelos protocolos de
acesso m ultiplo. Formalmente, podem-se classificar esses protocolos em: pro-
tocolos protocolo de alocac ao fixa (tambem chamado protocolo de divis ao do
canal), protocolos de acesso aleat orio e protocolo de alocac
ao din
amica (tambem
chamado protocolo de revezamento).
Os protocolos de alocacao fixa caracterizam-se por atribuir uma parte do
canal para cada estacao, de maneira fixa. O TDMA (Time-Division Multiple Ac-
cess, baseado na tecnica de multiplexac ao TDM) e o FDMA (Frequency-Division
Multiple Access, baseado na tecnica de multiplexac ao FDM) s ao exemplos deste
tipo de protocolo. S ao extremamente f aceis de implementar. Porem, quando
uma estac ao nao tem pacotes para enviar durante o perodo de tempo em que
o meio est a alocado para ela, o canal ficar a ocioso enquanto outros terminais
poderiam estar utilizando-o.
Por outro lado, os protocolos de acesso aleat orio n
ao possuem um controle
rgido para alocacao do canal. O ALOHA e o CSMA (Carrier Sense Multiple
Access) sao exemplos desta categoria. Tambem s ao relativamente simples de
implementar, porem, a possibilidade de ocorrer colis oes quando duas ou mais
estac
oes tentam transmitir ao mesmo tempo provoca desperdcio no canal de
transmiss ao.
Nos protocolos de alocac ao dinamica o canal e alocado de acordo com as
necessidades das estac oes. Este controle pode ser implementado de v arias
maneiras, como por exemplo: na forma de polling (onde uma estac ao espera ser
questionadase necessita acessar o canal), ou na forma de reservas explcitas,
como no RPAC (Reservation-Priority Access Control). Com a utilizac ao destes
protocolos n ao existe a possibilidade de colis oes e o canal e alocado sob de-
manda, evitando perodos de tempo ociosos no canal. Porem, h a uma sobre-
carga na rede devido aos sinais de controle transmitidos no meio. A tabela 27.1
resume as principais vantagens e desvantagens de cada tipo de protocolo.
Canal Ocioso Colis

oes Sobrecarga
Alocac
ao Fixa sim nao nao
Acesso Aleatorio nao sim nao

Alocac
ao Dinamica nao nao sim
Tabela 27.1: Alocac

ao de Canais
283
Captulo 28
Topologias de Redes
A topologia de uma rede de comunicac ao refere-se `

a forma como os enlaces
fsicos e os n
os est
ao organizados, determinando os caminhos fsicos existentes e
utilizaveis entre quaisquer pares de estac
oes conectadas a essa rede. A topologia
de uma rede muitas vezes caracteriza o seu tipo, eficiencia e velocidade. As
topologias mais comuns s ao as seguintes:
Malha
A interconex
ao e total garantindo alta confiabilidade, porem a complexi-
dade da implementac ao fsica e o custo inviabilizam seu uso comercial;
Estrela
A conex
ao e feita atraves de um n o central que exerce controle sobre a
comunicac
ao. Sua confiabilidade e limitada à confiabilidade do n
o central,
cujo mau funcionamento prejudica toda a rede;
Barramento
As estac
oes s
ao conectadas atraves de um cabo com difus
ao da informac
ao
para todos os n os. E necess
aria a adoc
ao de um metodo de acesso para
as estac
oes em rede compartilharem o meio de comunicac ao, evitando
colis
oes. E de f
acil expans
ao, mas de baixa confiabilidade, pois qualquer
problema no barramento impossibilita a comunicac ao em toda a rede;
Anel
O barramento toma a forma de um anel, com ligac oes unidirecionais ponto
a ponto. A mensagem e repetida de estac ao para estac
ao ate retornar `
a
estac
ao de origem, sendo entao retirada do anel. Como o sinal e recebido
por um circuito e reproduzido por outro h a a regenerac
ao do sinal no meio
de comunicac ao; entretanto ha tambem a inserc
ao de um atraso a cada
estac
ao. O tr
afego passa por todas as estac
oes do anel, sendo que somente
a estac
ao destino interpreta a mensagem;

Arvore
a expans
E ao da topologia em barra herdando suas capacidades e limitac oes.
O barramento ganha ramificac
oes que mantem as caractersticas de difus
ao
das mensagens e compartilhamento de meio entre as estac oes;
284
Mistas
Combinam duas ou mais topologias simples. Alguns exemplos s ao o de es-
trelas conectadas em anel e as
arvores conectadas em barramento. Procu-
ram explorar as melhores caractersticas das topologias envolvidas, procu-
rando em geral realizar a conex ao em um barramento u nico de m odulos
concentradores aos quais sao ligadas as estacoes em configurac
oes mais
complexas e mais confi
aveis.
Figura 28.1: Topologias de Rede

285
Captulo 29
Arquitetura de Redes
29.1 Organizac
ao em Camadas
Para reduzir a complexidade do projeto, a maioria das redes e organizada como
uma pilha de camadas colocadas umas sobre as outras. O n umero de camadas
e suas func
oes podem ser diferentes de uma rede para outra. No entanto, em
todas as redes o objetivo principal da implementac ao em camadas e fazer com
que uma camada ofereca servicos ` as camadas superiores, isolando a camada
superior dos detalhes de implementacao. A camada n de uma m aquina se co-
munica com a camada n de outra m aquina utilizando um conjunto de regras
e convenc
oes chamado protocolo. Essas entidades situadas em m aquinas difer-
entes s
ao chamadas de pares. Na verdade, a camada n de uma m aquina nao
se comunica com a camada n da outra m aquina diretamente. As informacoes
s
ao passadas para as camadas inferiores ate que se alcance a camada mais baixa.
Abaixo desta est

a o meio fsico atraves do qual a comunicac
ao propriamente
dita ocorre. Entre as camadas adjacentes existe uma interface. A interface
define o conjunto de operac
oes e servicos que a camada inferior pode oferecer
a camada imediatamente superior. Em uma arquitetura em camadas deve-se
estarem bem definidos quais s ao as funcoes de cada uma das camadas.
Este tipo de arquitetura proporciona a independencia das camadas per-

mitindo que a implementac ao de uma camada possa ser totalmente substituda
tendo como u nico requisito da nova implementac
ao oferecer no mnimo os mes-
mos servicos oferecidos pela implementac
ao anterior. Uma arquitetura em ca-
madas deve se preocupar com diversos aspetos como: Enderecamento, Modo de

Transmiss ao(Simplex,Half-Duplex,Full-Suplex), Canais Logicos(Dados,Controle),
Controle de Erros, Controle de Fluxo, Fragmentac
ao / Montagens, Multiplexac
ao
/ Demultiplexacao e Roteamento.
286
Captulo 30
Protocolos de Rede
30.1 ARP - Address Resolution Protocol

O protocolo ARP e destinado a realizar a associac ao entre um endereco de
camada 3 e um endereco de camada 2. O endereco de camada 3 e um en-
dereco l
ogico e est
a relacionado com protocolos como IP, IPX, Appletalk,etc. O
endereco mac e um endereco fsico que est
a relacionado com a interface de hard-
ware. Um computador pode ter in umeros enderecos de camada 3 por interface,
porem s o pode ter um endereco fsico por interface de rede.
Quando o computador tem dados para enviar para algum destinat ario rep-
resentado por um endereco IP, por exemplo, ele encapsula esses dados em um
pacote IP e ent ao tem que realizar algumas etapas antes de enviar. Primeiro ele
verifica se o endereco IP destino pertence ou n ao a mesma rede em que ele est a
conectado. Em caso afirmativo, ele precisa ent ao determinar qual o endereco
fsico correspondente ao endereco IP destino, para que ent ao possa encapsular
o pacote IP em um frame e coloc a-lo no meio de transmiss ao. Para determinar
o endereco fsico destino o computador primeiramente verifica se existe uma
entrada em sua tabela de Cache de ARP. Caso exista,ele encapsula o pacote IP
em um frame e envia, caso contr ario e necess
ario que se envie uma mensagem
ARP em broadcast com a seguinte pergunta: Quem possui o endereco IP end?
Todas as m aquinas da rede local ir
ao receber a mensagem e analisar o conte udo.
Aquela que possuir endereco end responder a a mensagem arp enviando seu en-
dereco fsico.
30.2 DHCP - Dynamic Host Configuration Pro-

tocol
O DHCP (Dynamic Host Configuration protocol) e um protocolo que obje-
tiva realizar a configurac
ao din
amica de hosts em uma rede ou na Internet. O
DHCP consiste de dois componentes b asicos que s
ao um protocolo para trocar
mensagens e transportar informac oes relativas a configurac
oes do host e um
mecanismo para controlar a alocac ao de enderecos de rede.
287
O DHCP e baseado no modelo cliente-servidor, onde o cliente requisita os

par
ametros de configurac
ao e os servidores recebem os pedidos, os analisa e prove
as configurac
oes para os hosts. Vale ressaltar que e possvel a coexistencia de
mais de um servidor DHCP em uma rede.
Tambem e possvel o servidor DHCP estar fora da rede em que se encon-

tram os hosts solicitantes (clientes). Neste caso, e necess
aria a instalac
ao de um
agente de retransmiss ao DHCP (DHCP Relay Agent). A u nica informacao que
este agente precisa ter e o endereco IP do servidor DHCP que est a fora da rede.
As tres formas de assinalar um endereco IP s

ao:
Alocac
ao Autom atica - um endereco IP e fornecido para de forma perma-
nente pelo servidor de DHCP;
Alocac
ao Din
amica - as configuracoes do host s
ao fornecidas por um de-
terminado perodo de tempo chamado lease. As configurac oes podem
ser canceladas antes desse perodo expirar caso seja de interesse do host;
Alocac
ao Manual - as configurac
oes do host s
ao ajustadas manualmente
pelo administrador da rede.
Em geral em uma rede essas formas de assinalar enderecos s ao utilizadas

em conjunto. Entre os requisitos de um servico de DHCP em uma rede est ao:
garantir que um mesmo endereco nao estar
a em uso mais de um host ao mesmo
tempo; estar preparado para funcionar em mais de um em uma rede de forma
aumentar a performance e redund ancia; estar preparado para lidar com hosts
estaticamente configurados.
Entre os par ametros de configuracao fornecidos pelo DHCP, est ao, o en-
dereco de rede, a m
ascara de subrede, o tempo de durac ao da licenca (lease),
endereco do gateway padrao, endereco dos servidores de DNS, etc.
A alocac
ao din
amica de endereco e o mais importante servico fornecido pelo
DHCP. Para um host adquirir configurac oes as seguintes etapas s
ao necess
arias:
Um cliente faz um broadcast de uma mensagem DHCPDISCOVER para

na sua rede local fsica. Caso o servidor de DHCP n
ao esteja naquela rede
fsica, os agentes relay encaminham as mensagens para frente atraves dos
roteadores;
Os servidores recebem a mensagem DHCPDISCOVER e respondem com

uma mensagem DHCPOFFER com as configurac
oes que ele pode fornecer;
O cliente recebe uma ou mais mensagem DHCPOFFER e escolhe qual

delas respondera enviando um broadcast da mensagem DHCPREQUEST
indicando qual servidor escolheu e possivelmente adicionando novos req-
uisitos de configurac
ao;
O servidor recebe a mensagem DHCPREQUEST e checa em sua base de

dados se e possvel fornecer as configurac
oes desejadas pelo host. Caso
seja possvel, envia uma mensagem com o DHCPACK, sen ao envia um
288
DHCPNAK. O processo e reiniciado ap

os um tempo determinado por
backoff exponencial;
O host, caso tenha recebido ACK, checa as configurac oes fornecidas us-
ando ARP, por exemplo, e caso detecte que configurac
oes n
ao s
ao validas,
envia uma mensagem do tipo DHCPDECLINE, cancelando a negociac ao.
30.3 DNS - Domain Name System

Originalmente, o mapeamento de nomes em enderecos era todo registrado em
um unico arquivo chamado HOSTS.TXT. Esse arquivo era gerenciado por uma
entidade chamada NIC (Network Information Center). A distribuic ao das at-
ualizac
oes desse arquivo era feita via FTP, o que consumia uma banda muito
grande. O perfil do usuario de redes e da Internet mudou muito, ocorrendo um
grande crescimento das redes locais, com suas pr oprias necessidades de mapear
nomes que s o faziam sentido em seus ambientes. O perfil das aplicacoes de In-
ternet tambem evoluiu bastante, surgindo a necessidade de se criar um sistema
de mapeamento de nomes mais geral e eficiente. Foi neste contexto que surgiu
o DNS.
O DNS e (1) um banco de dados distribudo implementado em uma hier-

arquia de servidores de nome, e (2) um protocolo de camada de aplicac ao que
permite que hospedeiros consultem o banco de dados distribudo. Para tratar
a quest
ao da escala, o DNS usa um grande n umero de servidores organizados,
de maneira hierarquica e distribuda, por todo o mundo. Os principais compo-
nentes do DNS s ao:
Domain Name Space (Espaco de Nomes): e uma especificac ao para uma
arvore estruturada para armazenar os espacos de nomes. Esta
arvore e
dividida em ZONAS n ao-superpostas. Normalmente, cada zona tem um
servidor de nome principal (onde os registros s
ao mantidos em disco) e um
ou mais servidores secund
arios;
Resource Records (Registro de Recursos): A principal func ao do DNS
e mapear nomes de domnios em registros de recursos (n ao somente en-
dereco IP). Um registro de recurso e uma tupla de cinco campos: Do-
main name (normalmente existem muitos registros, de tipos diferentes,
para cada domnio); Time to live (tempo de vida do registro); Class (IN
quando relacionado ` a Internet, outros c odigos s
ao raramente encontra-
dos); Type (tipo de registro); e Value (sua sem antica depende do tipo de
registro). Os tipos de registros existentes s
ao:
Name Servers (Servidores de Nomes): s ao programas servidores que detem
informac
ao sobre a estrutura da arvore de domnio e tambem tem a ca-
pacidade de registrar informac
oes. Resumidamente, h a quatro classes de
servidores de nomes: servidores de nomes raiz (cerca de 13 servidores);
servidores DNS de domnio de nvel superior (.int, .com, .mil, .net, .br, .jp,
etc. - cerca de 200 servidores); servidores DNS com autoridade (chama-
dos de AUTHORITH - os que detem os registros de recursos de servidores,
localizados em sua zona, que podem ser acessados publicamente); e servi-
dores intermediarios;
289
Tipo Significado Valor

SOA Incio de autoridade Par
ametro para essa zona
A Endereco IP de um host In-
teiro de 32 bits
MX Troca de mensagens de cor- Prioridade, domnio disposto
reio a aceitar correio eletr
onico
NS Servidor de nomes Nome de um servidor para
este domnio
CNAME Nome canonico Nome de domnio
PTR Ponteiro Nome alternativo de um en-
dereco IP
HINFO Descric
ao de host CPU e sistema operacional
em ASCII
TXT Texto Texto ASCII n
ao-
interpretado
Tabela 30.1: Principais tipos de registros de recursos do DNS para o IPv4
Resolvers (Resolvedores): s ao programas, executados tanto nos clientes

quanto nos servidores, que extraem informac oes dos Name Servers em
resposta a requisic
oes feitas por clientes. Esses programas s ao aptos a
responder as queries diretamente ou ent ao encaminhar a queries caso a
informac
ao n
ao esteja disponvel naquele Name Server. S
ao programas que
podem ser acessados diretamente por programas de usu arios ou rotinas do
sistema operacional sem a necessidade de utilizacao de protocolos;
Cache DNS: uma caracterstica muito importante usada para aumentar o

desempenho quanto a atraso e reduzir o n umero de mensagens DNS na In-
ternet. Em cada elemento da cadeia (cliente, servidores local, secund arios,
primarios, com autoridade, de nvel superior, etc.) informac
oes (registros)
de respostas podem ser armazenadas em mem oria local. Para evitar o uso
de registros desatualizados, e associado a cada registro um n umero TTL
(Time to Live) que determina seu tempo de vida;
Existem dois metodos de consulta: recursiva, onde cada servidor que n ao

tiver as informac
oes solicitadas podera encontr
a-las, por meio de novas consul-
tas, em algum lugar e informar ao solicitante o que encontrou. Iterativa, onde
quando a consulta n ao pode ser satisfeita no local, haver a uma falha, mas e
retornado o nome do pr oximo servidor a ser consultado, pelo solicitante, ao

longo da linha. Para cada consulta, os tipos b asicos de resposta s
ao: authorita-
tive answer (consulta resolvida pelo servidor com autoridade); positive answer;
referral answer (nao contem resoluc
ao da consulta, e sim uma referencia para
uma nova consulta - usada no metodo iterativo); e negative answer (ou o nome
pesquisado n ao existe ou o tipo de registro n
ao confere - sempre indicado pelo
servidor com autoridade).
importante observar que o DNS n

E ao somente prove o servico de traducao
de nomes em enderecos IPs. Ele tambem prove outros servicos mais sofisticados,
tais como:
290
Distribuic
ao de carga: implementado por meio do tipo de registro A com
mais de um IP de servidores replicados (ex. Web ou FTP) utilizados na
distribuic
ao de carga. Ao resolver o nome, o DNS faz um rodzio entre os
IPs cadastrados;
Apelidos de hospedeiros: implementado por meio do tipo de registro

CNAME (um hospedeiro com nome complicado pode ter um ou mais
apelidos);
Apelidos de servidores de correio: implementado por meio do tipo de

registro MX;
O DNS utiliza UDP/53 para resoluc

ao de nomes e TCP/53 para realizar
transferencia de zonas.
O nome completo de um host da rede e conhecido como FQDN - Full Quali-

fided Domain Name. Por exemplo, ftp.abc.com.br e um FQDN. ftp (a primeira
parte do nome) e o nome de host e o restante representa o domnio DNS no qual
est
a o host.
Dica Importante: O administrador do servidor DNS local pode desabilitar o

recurso de recursao em um servidor DNS em situac oes onde os usu
arios devem
estar limitados a utilizar apenas o servidor DNS da Intranet da empresa. Desta
forma, somente os enderecos internos (armazenados no disco do servidor DNS
local - AUTHORITH) ser ao resolvidos.
O nslookup e uma ferramenta, comum ao Windows e ao Linux, utilizada

para se obter informacoes sobre registros de DNS de um determinado domnio,
host ou IP. Podemos utilizar esta ferramenta em dois modos diferentes. No
modo direto, onde digitamos o comando nslookup e mais alguns par ametros, e
no modo interativo, onde digitamos somente o comando nslookup e um prompt
e aberto para que sejam realizadas consultas ao servidor DNS. Alguns exemplos
de par
ametros/consultas s ao: nslookup nome do host/nomes e enderecos do
servidor DNS e do host; nslookup -querytype=ANY nome do host/todas as
informac
oes disponveis do servidor DNS e do host.
30.4 TCP - Transmission Control Protocol

O protocolo TCP (Transmission Control Protocol) e um protocolo da camada
de transporte cujo principal objetivo e prover um servico de conex ao confi

avel
entre um par de processos que desejam se comunicar. prover facilidades como
transferencia b
asica de dados, controle de fluxo, multiplexac ao, precedencia,
controle de conex oes, e alguma seguranca. A express ao conexao confi
avel est
a
relacionada com a capacidade do protocolo TCP em lidar com dados danifica-
dos, perdidos ou duplicados utilizando para isso n umeros de seq
uencia, ACKs,
buffers de retransmiss ao. O TCP implementa tambem a multiplexac ao para
permitir que m ultiplos processos utilizem as facilidades do TCP em um mesmo
host. Para isso utiliza um identificador de conex ao chamado soquete, que e
formado pela porta e endereco de rede.
291
O cabecalho do TCP e formado pelos seguintes campos: (i) Source Port

- porta de origem; (ii) Destination Port - porta de destino; (iii) Sequence
Number - numero de seq uencia do segmento; (iv) Acknowledgment Number
- o numero de seq uencia que o sender do segmento espera receber; (v) Data
Offset - Indica onde os dados comecam. M ultiplo de 32 bits; (vi) Control
Bits - (URG/ACK/PSH/RST/SYN/FIN); (vii) Window - tamanho da janela
aceit
avel. Indica range de n umeros de sequencia aceitos; (viii) Checksum -
Checksum calculado sobre headers e dados; (ix) Urgent Pointer - Indica o offset
dos dados urgentes em um dado segmento. S o tem sentido com o flag URG se-
tado. (x) Options: opcoes adicionais (Ex: Maximum Segment Size. Esta opc ao
s
o deve ser utilizada no estabelecimento da conex ao. Caso contr ario qualquer
tamanho de segmento e aceito); (xi) Padding - usado para garantir que o header
seja multiplo de 32 bits e o campo data offset trabalhe corretamente.
Para manter uma conex ao TCP e necess

ario que se guarde o status de v arias
vari
aveis referentes a recebimento e envio de segmentos, informac oes sobre o
segmento corrente, informacao sobre o estado da conex ao e identificador da
conexao. Todas essas conex oes s
ao guardadas em uma estrutura chamada TCB
- Transmission Control Block. Entre as informac oes guardadas nos TCBs est ao,
por exemplo, o tamanho da janela, numero de seq uencia inicial da conex
ao e o
estado dos bits de controle.
As conex
oes TCP podem se encontrar nos seguintes estados:
LISTEN - A espera de um pedido de conex

ao;
SYN-SENT - A aplicac
ao comecou a abrir uma conex
ao;
SYN-RECEIVED - Uma solicitac

ao chegou. Espera por um ack;
ESTABILISHED - Estado normal para envio de dados;
FIN-WAIT-1 - A aplicac
ao informou que acabou de transmitir;
FIN-WAIT-2: O outro lado concordou em encerrar;
TIMED-WAIT - Aguarda a entrega de todos os pacotes;
CLOSE-WAIT - Um lado deu inicio ao encerramento;
LAST-ACK - Aguarda entrega de todos os pacotes;

CLOSING - Ambos tentaram encerrar simultaneamente.
A conex
ao passa de um estado para o outro em resposta a eventos que s
ao
as chamadas as func
oes OPEN, SEND, RECEIVE, CLOSE, ABORT, STATUS
ou ent
ao segmentos contendo flags SYN, ACK, RST, e FIN, alem dos timeouts.
As duas causas de congestionamento s ao a sobrecarga na rede e a sobre-

necess
carga no receptor. E ario lidar com cada uma das causas separadamente.
Se o mecanismo de Janela de Transmiss ao for obedecido pelo transmissor, n
ao
haver
a problemas devido a sobrecarga de buffers mas somente devido a conges-
tionamentos internos da propria rede. Para isso utiliza-se uma segunda janela
292
chamada Janela de Congestionamento.
O valor mnimo entre essas janelas reflete o numero m aximo de bytes que um
transmissor pode enviar. O mecanismo de janela de congestionamento funciona
da seguinte maneira: Ao estabelecer a conex ao o valor da janela de congestion-
amento e setado para o valor m aximo do segmento (MSS) cordado na conex ao.
feita ent
E ao a transmiss ao de um segmento de tamanho MSS. Caso n ao tenha
ocorrido timeout, o valor da janela de congestionamento e aumentado para duas
vezes o anterior. Esse procedimento segue ate que uma transmiss ao resulte em
timeout. Caso isso ocorra o procedimento e reiniciado a partir do valor inicial.
Esse e um algoritmo exponencial. Existe uma variante que permite a utilizac ao
de um limiar a partir do qual o crescimento passa a ser linear e nao exponencial.
Na internet essa tecnica e utilizada.
O mecanismos de abertura de conex ao e conhecido como Three-Way Hand-

shake. E formado pelas seguintes etapas: (1) A - B (SYN my sequence number
is X); (2) A - B ACK (your sequence number is X) e SYN (my sequence number
is Y); (3) A B ACK (your sequence number is Y).
Os timers utilizados pelo TCP s

ao: Timer de Retransmissao - responsavel
por indicar se um segmento deve ser retransmitido; Timer de Persistencia -
utilizado para evitar o impasse quando o anuncio do tamanho de janela se
perder, Timer de keepAlive - pode expirar quando uma conex
ao fica inativa por
muito tempo.E feita ent
ao uma checagem para ver se o outro lado ainda esta
ativo; TIME WAIT - utilizado no estado da conex ao.
30.5 UDP - User Datagram Protocol

O UDP e um dos principais protocolos da Internet. E um protocolo destinado
ao envio de mensagens custas. Por isso se diz que ele e um protocolo orientado a
mensagens e tambem stateless. Nao proporciona nenhuma garantia de entrega
nem ordenacao. No entanto, e muito mais leve e eficiente do que o TCP. Esse
e um dos motivos pelos quais o UDP e muito utilizado em aplicac oes sensveis
ao tempo.
Entre as in
umeras aplicac
oes do protocolo UDP est ao os servicos de RIP,
SNMP, DHCP, DNS, VoIP, jogos online, aplicac oes de multimdia, entre out-
ras. Em um servico de transmiss ao de voz, a retransmiss ao do dado n ao e
u
til devido ao atraso, assim como em uma transmiss um proto-
ao de vdeo. E
colo da camada de transporte e possui um cabecalho simplificado com apenas
4 campos que sao:(i)Source Port;(ii) Destination Port;(iii)Lenght;(iv)Checksum.
Cada um e formado por 16 bits. Os campos Source Port e Checksum s ao

opcionais. Na pratica, o campo e quase sempre utilizado, enquanto o campo
Source Port pode ser utilizado quando se deseja receber uma resposta. E impor-
tante lembrar que na comunicacao UDP nao existem mensagens de confirmacao.
Quando essas ocorrem se devem a iniciativa da aplicacao que est
a utilizando o
UDP e n ao das regras de comunicacao do protocolo em si. Exemplo: Uma
querie DNS e enviada ao servidor que por sua vez responde utilizando tambem
293
uma mensagem UDP.
Como o campos Source Port e opcional, caso n ao seja preenchido, no mo-

mento do calculo do Checksum ele e considerado 0. Nos casos em que o Check-
sum tambem nao e calculado, o valor enviado consiste em 16 bits 0. Caso o
checksum calculado seja 16 bits 0, o valor do checksum enviado e composto por
16 bits 1.
30.6 HTTP - Hyper Text Transfer Protocol

o protocolo de CAMADA DE APLICAC
E da Web definido no RFC 1945
AO
(HTTP 1.0) e no RFC 2616 (HTTP 1.1). Ele e implementado em dois pro-
gramas, um cliente e outro servidor, portanto, ele e classificado como aplicac
ao
cliente-servidor. Estes dois programas, executados em sistemas finais distintos,
conversam entre si por meio de troca de mensagens HTTP. O HTTP define a
estrutura dessas mensagens e o modo como o cliente e o servidor as trocam.
Uma p
agina Web (ou documento) e constituda de OBJETOS. Um objeto e
simplesmente um arquivo. Exemplos de objetos s ao: arquivo HTML, imagem
JPEG, imagem GIF, applet JAVA, etc. Cada objeto e referenciado por uma
u
nica URL. Cada URL tem dois componentes: o nome do hospedeiro e o nome
do caminho do objeto. Por exemplo, na URL http://www.universidade.br/departamento/figura.gif,
www.universidade.br e o nome do hospedeiro e /departamento/figura.gif e o
nome do caminho do objeto.
Um BROWSER e um AGENTE DE USUARIO para a Web. Eles imple-

mentam o lado cliente do HTTP a fim de apresentar p aginas Web e fornecer
numerosas caractersticas de navegac
ao e de confirmac
ao. Vale salientar que
dois browsers distintos podem apresentar p aginas Web de formas ligeiramente
diferentes, pois o protocolo HTTP n ao define nada sobre apresentacao. Os
SERVIDORES WEB implementam o lado servidor do HTTP a fim de abrigar
objetos Web. Os Servidores Web mais utilizados atualmente s ao os Apache e o
Microsoft Internet Information Server (IIS).
O HTTP usa o TCP como seu protocolo de transporte. Por padr ao, as por-
tas utilizadas s
ao as 80 (prim
aria) e 8080 (alternativa). Desta forma, as trocas
de mensagens s ao realizadas de forma orientada a conex ao. Estas conexoes po-
dem ser persistentes ou nao-persistentes.
As conex
oes n
ao-persistentes seguem o seguinte fluxo:
O processo cliente abre uma conex
ao TCP executando a APRESENTAC
AO
DE TRES VIAS (three way handshake);
Durante a terceira via do three way handshake, o processo cliente envia

uma mensagem de requisicao HTTP ao servidor;
O processo servidor recebe a mensagem de requisic
ao, encapsula o objeto
requisitado em uma mensagem de resposta HTTP, e a envia ao cliente;
O processo servidor solicita o encerramento da conex
ao TCP;
294
Apos o tempo de transmiss

ao da mensagem resposta, o processo cliente
recebe a mensagem de resposta, extrai o arquivo da mensagem de resposta
e o apresenta.
Desta forma, para cada objeto transferido h

a a exigencia de abertura de
uma nova conexao TCP. Como geralmente as p aginas Web s ao consistidas de
um arquivo-base HTML e diversos objetos referenciados, este tipo de conexao
se mostrou um tanto quanto ineficiente.
O tipo de conexao persistente permite um aumento consider avel na eficiencia

das trocas de mensagens. Neste tipo de conex ao, o servidor deixa a conexao TCP
aberta apos enviar resposta. Ou seja, requisic
oes e respostas subseq uentes entre
os mesmos cliente e servidor podem ser enviadas por meio da mesma conex ao.
Em geral, o servidor HTTP fecha uma conex ao quando ela n ao e usada durante
certo tempo (configur avel).
H a duas vers
oes de conex oes persistentes: SEM PARALELISMO e COM
PARALELISMO. Na vers ao sem paralelismo, o cliente emite uma nova req-
uisic
ao somente quando a resposta anterior foi recebida. O modo default do
HTTP usa conex oes persistentes com paralelismo. Nesse caso, o cliente emite
uma requisicao logo que encontra uma referencia, mesmo antes de receber uma
resposta a uma requisicao anterior (PIPELINE).
Uma outra forma de paralelismo e o cliente abrir conexoes paralelas com um

servidor. Nos modos default, a maioria dos browsers abre de cinco a dez conexoes
TCP paralelas, cada uma delas manipula uma transac ao requisic
ao/resposta.
importante salientar que o servidor envia as respostas HTTP ao cliente

E
sem armazenar nenhuma informac ao de estado sobre este. Se um determinado
cliente solicita o mesmo objeto duas vezes em um perodo de poucos segundos,
o servidor n ao responde dizendo que acabou de enviar o objeto. Em vez disso,
ele envia novamente o objeto ao cliente. Em outras palavras, o HTTP e um
PROTOCOLO SEM ESTADO.
Como j a se pode notar, as mensagens s

ao de dois tipos: mensagem de req-
uisic
ao e mensagem de resposta. Antes de apresentar os principais campos do
tipo de mensagem de requisicao, vamos a um exemplo tpico.
GET /somedir/page.html HTTP/1.1

Host: www.someschool.edu
Connection: close
User-agent: Mozilla/4.0
Accept-language: fr
Em primeiro lugar, vemos que esta mensagem est a escrita em texto ASCII
comum. Embora ela tenha cinco linhas, ela poderia ter de uma a diversas lin-
has. A primeira linha sempre e denominada LINHA DE REQUISIC
AO. As
subseq uentes s
ao denominadas LINHAS DE CABEC ALHO. A linha de req-
uisic
ao e composta por tres campos: o campo do METODO; o da URL; e o da
VERSAO do HTTP. A linha de cabecalho Host especifica o hospedeiro no qual o
295
objeto reside (este campo e utilizado para buscar objetos em servidores proxy).
Ao incluir a linha de cabecalho Connection: close, o browser est a encerrando
a conex ao. A linha de cabecalho User-agent especifica o agente de usu ario, ou
seja, o tipo de browser (o servidor pode enviar versoes diferentes de um mesmo
objeto). Por fim, o cabecalho Accept-language mostra que o usu ario prefere
receber uma vers ao em frances do objeto se este existir.
O formato geral de uma mensagem de requisic

ao e mostrado na figura abaixo.
Figura 30.1: Formato geral de uma mensagem de requisic

ao HTTP
Agora que j
a apresentamos um exemplo de mensagem de requisic
ao, vamos
a um exemplo tpico de mensagem de resposta.
HTTP/1.1 200 OK
Connection: close
Date: Thu, 03 Jul 2003 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Sun, 5 May 2003 09:23:24 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data data ...)
Este exemplo tem tres secoes: a LINHA DE ESTADO; seis LINHAS DE

CABEC ALHO; e CORPO DA ENTIDADE (contem os objetos propriamente
ditos). A linha de estado tem tres campos: o campo da VERSAO do HTTP; um

CODIGO DE ESTADO; e uma MENSAGEM de texto correspondente. A linha
de cabecalho Connection: close indica que o servidor fechar a a conex
ao ap os o
envio da mensagem. A linha de cabecalho Date indica a hora e a data em que
a resposta foi criada e enviada pelo servidor (nao se refere `
a data de criac
ao do
objeto nem de sua u ltima alterac
ao). A linha de cabecalho Server mostra por
qual tipo de servidor a mensagem foi criada. A linha de cabecalho Last-Modified
indica a hora e a data em que o objeto foi criado ou sofreu a u ltima modificacao
(fundamental para a implementac ao de servidores proxy). A linha de cabecalho
Content-Length indica o n umero de bytes do objeto que est a sendo enviado.
Por fim, a linha de cabecalho Content-Type mostra o tipo de objeto presente
296
no corpo da mensagem. E importante notar a linha em branco antes do corpo

da entidade. Esta linha e obrigat
oria e indica que n
ao h
a mais nenhuma linha
de cabecalho.
O formato geral de uma mensagem de resposta e mostrado na figura abaixo.
Figura 30.2: Formato geral de uma mensagem de resposta HTTP
Os metodos implementados pelo HTTP 1.1 s

ao:
GET - Este metodo solicita um objeto, identificado por uma URL in-
dicada na mensagem de requisic ao. Um GET condicional e um tipo
especfico de GET. Ele deve possuir pelo menos uma linha de cabecalho
do tipo If-Modified-Since ou If-UnModified-Since. De uma forma geral,
ele permite melhorar o desempenho transmitindo apenas os dados que
atendem determinada condic ao. Existe tambem o GET parcial que
permite que apenas parte da informacao seja transmitida. Isso pode ser
utilizado quando o cliente j
a possui uma parte dos dados. Para isso o
campo Range do cabecalho deve ser preenchido. A grande maioria das
mensagens de requisic
ao tem a forma de metodo GET;
HEAD - Este metodo e semelhante ao GET, contudo e utilizado para
trazer apenas os cabecalhos da mensagem que s
ao exatamente os retorna-
dos pelo GET e n ao os objetos requisitados;
POST - Este metodo e utilizado para acrescentar informac oes a uma req-
uisic
ao. Por exemplo, quando o cliente preenche algum formul ario de
busca. Com esta mensagem, o cliente continua requisitando um objeto

(ou objetos), mas seu conte udo depende do conte udo do formulario. Os
conte udos do formulario s ao transmitidos no corpo da entidade. OBS:
n
ao necessariamente as requisic oes geradas com um formulario utilizam o
metodo POST. E possvel utilizar o metodo GET com os conte
udos do for-
mul ario como parte da URL (ex. www.somesite.com/animalsearch?monkey&bananas);
PUT - Este metodo solicita o armazenamento de um objeto, enviado no
corpo da entidade, em um diret orio em um determinado Servidor Web
(indicados por uma URL). Na pr atica este metodo n
ao e muito utilizado
hoje em dia;
297
DELETE - Este metodo solicita que um objeto determinado por uma URL
seja deletado no Servidor Web;
TRACE - Este metodo requisita o destino final a refletir (enviar de volta)
a mensagem que est a recebendo. O campo de cabecalho Max-Fowards
pode ser preenchido de forma limitar o n
umero de proxies para detectar
possveis loops;
CONNECT: N
ao e utilizado atualmente. Ele e reservado para uso futuro;
OPTIONS: fornece um meio para que o cliente consulte o servidor sobre
suas propriedades ou sobre as de um objeto especfico.

Os CODIGOS DE ESTADO s ao c
odigos para representar o atual estado do
servidor. S
ao separados nas seguintes classes:
1xx (Informational) - Raramente utilizados na pr

atica. Ex. 100 - Indicam
que servidor concorda em atender ou continuar atendendo requisic ao do
cliente;
2xx (Successful) - Indicam que a requisicao foi corretamente recebida,
entendida, aceita e que o conteudo (se houver) est
a sendo retornado. Ex.
200 - requisic
ao bem-sucedida; 204 - sem conte
udo;
3xx (Redirection) - Indica que o cliente deve procurar em outro lugar,
usando um URL diferente ou seu pr oprio cache. Ex. 301 - a p
agina foi
movida; 304 - a p
agina no cache ainda e v
alida;
4xx (Client Error) - Indica um erro do cliente ao fazer a requisic
ao. Ex.
403 - p
agina;
5xx (Server Error) - Indica um erro do servidor ao processar a requisic
ao.
Cabe ressaltar que o HTTP n ao e somente utilizado no contexto Web. Ele

tambem e frequentemente utilizado em aplicacoes de comercio eletr
onico para
transferir arquivos XML de uma m aquina para outra, sem que nenhuma dessas
maquinas envolva um browser ou um usu ario. O HTTP tambem e utilizado para
transferir VoiceXML, WML e outros tipos de XML. Outra utilidade do HTTP
e servir como protocolo de transferencia de arquivos no compartilhamento de
arquivos em redes P2P.
Outra observacao importante e o fato do HTTP n ao exigir conexoes es-

pecficas e distintas para transferencia de mensagens de controle e para trans-

ferencia de mensagens de dados. Desta forma, dizemos que as mensagens de
controle sao enviadas NA BANDA.
A vers
ao 1.1 do HTTP e totalmente compatvel com a vers
ao 1.0, contudo
h
a algumas diferencas. As duas principais s
ao:
A vers
ao 1.0 n
ao suporta conexoes persistentes. J
a a vers
ao 1.1 suporta
ambos os tipos de conex
ao, persistente e n
ao-persistente;
A vers
ao 1.0 permite somente tres tipos de metodos: GET, POST e
HEAD.
298
30.7 SMTP - Simple Mail Transfer Protocol

E do modelo OSI definido pela
AO
RFC 2821. Ele e o principal protocolo do correio eletr onico da Internet. Ele e
implementado em dois programas, um cliente e outro servidor, portanto, ele e
classificado como aplicac
ao cliente-servidor. Estes dois programas, executados
em sistemas finais distintos, conversam entre si por meio de troca de mensagens
SMTP.
Antes de apresentarmos as principais caractersticas do SMTP, se faz necess

ario
abordar alguns assuntos relevantes a cerca do sistema de correio eletr onico na
Internet. Uma grande caracterstica deste sistema e o fato das comunicac oes
serem assncronas. Ou seja, as pessoas enviam e recebem mensagens quando for
conveniente para elas. Este sistema e composto basicamente por tres compo-
nentes: AGENTES DE USUARIOS; SERVIDORES DE CORREIO (tambem
chamado de AGENTE DE TRANSFERENCIA DE MENSAGEM); e o SMTP.
Os Agentes de Usu arios s

ao executados localmente na m aquina do usu
ario,
permitindo-o a ler, responder, retransmitir, salvar e escrever mensagens.
Exemplos de Agentes de Usu arios com interface gr
afica s
ao: Eudora, Out-
look e o Messenger da Netscape. Outros Agentes sem interface gr afica
s
ao: mail, pine e elm;
Os Servidores de Correio formam o n ucleo da infra-estrutura do sistema.

Cada usu ario tem uma CAIXA POSTAL. Diversos Agentes de Usu arios
podem se conectar ao Servidor de Correio no intuito de enviar/receber
mensagens. Eles implementam tanto o lado cliente quanto o lado servidor
do SMTP. Quando um Servidor de Correio envia correspondencia para
outros, age como um cliente SMTP. Quando um Servidor de Correio recebe
correspondencia de outros, age como um servidor;
O SMTP define a estrutura das mensagens trocadas, principalmente entre

os Servidores de Correio.
O SMTP usa o TCP como seu protocolo de transporte. Desta forma, as

trocas de mensagens s ao realizadas de forma orientada a conex ao. Por padr
ao,
a porta utilizada e a 25 e as conex
oes s
ao sempre persistentes. Ou seja, em uma
mesma sess ao SMTP, diversas mensagens podem ser enviadas.
Para ilustrar uma operacao tpica do SMTP, vamos recorrer a um cen

ario
bem comum descrito pela figura 30.3. Suponha que Alice queira enviar a Bob
uma simples mensagem ASCII. Os seguintes passos s ao seguidos:
Alice comp
oe a mensagem e solicita ao seu Agente de Usu
ario a entregar
esta mensagem a Bob;
O Agente de Usu ario de Alice envia a mensagem para seu Servidor de

Correio por meio do SMTP. Esta mensagem ser a colocada em uma fila
de mensagens. Na verdade, este Agente de Usu
ario poderia dialogar dire-
tamente com o Servidor de Correio de Bob, porem na pratica esta n
ao e
uma abordagem tao comum;
299
O lado cliente do SMTP, que funciona no Servidor de Correio de Alice, ve

a mensagem na fila e abre uma conex ao TCP para um servidor SMTP, que
funciona no Servidor de Correio de Bob. Caso esta conex ao n
ao possa ser
aberta, em geral, novas tentativas serao feitas a cada 30 minutos, se nao
obtiver sucesso ap
os alguns dias, o Servidor de Correio de Alice remover
aa
mensagem da fila e a notificar
a. Os Servidores de Correio se encontram na
Internet usualmente consultando o DNS, mais especificamente o registro
MX (Mail eXchange);
Apos alguns procedimentos iniciais de apresentac

ao, o cliente SMTP envia
a mensagem de Alice para dentro da conex ao TCP;
No Servidor de Correio de Bob, o lado servidor do SMTP recebe a men-

sagem e a coloca na caixa postal dele;
Bob chama seu Agente de Usu ario para ler a mensagem quando for mais
conveniente para ele. Vale salientar que a comunicacao entre o Agente de
Usuario de Bob e seu Servidor de Correio nao pode se dar via SMTP. Este
u
ltimo passo do processo dever a ser feito via um dos protocolos: HTTP,
POP3 ou IMAP.
Figura 30.3: Protocolos de e-mail e suas entidades comunicantes
Uma diferenca marcante entre o HTTP e o SMTP e o fato do HTTP ser

um PROTOCOLO DE RECUPERACAO DE INFORMAC
OES (pull proto-
col). Nesse tipo de protocolo, as conex oes s
ao abertas pelas m aquinas que
desejam receber as informacoes. Ja o SMTP e um PROTOCOLO DE ENVIO
DE INFORMAC
OES. Neste tipo de protocolo, as conex oes sao abertas pelas
maquinas que desejam enviar as informac oes (cliente SMTP). E por este motivo
que o u
ltimo passo da transferencia entre dois usuarios, entre Agente de Usuario
destinat
ario e seu Servidor de Correio, nao pode ser feito via SMTP.
importante observar que o SMTP normalmente n

E ao usa servidores de cor-
reio intermediarios para enviar correspondencia, mesmo quando os dois servi-

dores estao localizados em lados opostos do mundo. Isto porque ele utiliza
o TCP como protocolo de transporte, que e orientado a conex ao. Portanto,
geralmente os Servidores de Correio cliente e servidor se conectam diretamente
(virtualmente falando).
A cada comando enviado pelo cliente SMTP, haver a uma resposta enviada
pelo servidor SMTP via um c odigo de resposta e eventualmente uma mensagem
de explicac
ao. Os principais comandos sao:
DATA: inicializa a transmiss

ao do corpo da mensagem;
300
HELO: identifica o emissor da mensagem;

HELP: solicita ao servidor SMTP informac
oes de ajuda;
MAIL FROM: inicializa uma transac

ao de mail;
QUIT: determina que o servidor SMTP envie um ok e ent
ao feche a
conex
ao;
RCPT TO: identifica o destinatario da mensagem. M

ultiplos destinat
arios
s
ao definidos por m
ultiplos usos deste comando;
TURN: faz com que os cliente e servidor troquem de papel, o cliente passa
a ser servidor e vice-versa;
. (ponto): identifica o fim do corpo da mensagem.
Todo correio eletronico e dividido em duas partes: MENSAGEM e EN-

VELOPE. O conte udo da parte envelope e determinado pelo protocolo de ap-
resentac
ao SMTP. A mensagem e subdividida em CABEC ALHO e CORPO.
As informacoes contidas no cabecalho s ao determinadas no RFC 822. Cada
cabecalho deve ter obrigatoriamente uma linha From: e uma To: e pode incluir
tambem uma Subject:, bem como outras linhas opcionais. E importante notar
que essas linhas de cabecalho s ao diferentes dos comandos SMTP, ainda que
contenham algumas palavras em comum.
Uma caracterstica marcante do SMTP e o fato dele exigir que o formato

de representac
ao, tanto dos cabecalhos quanto do corpo da mensagem, seja
ASCII. Desta forma, conte udos nao ASCII, por exemplo, imagens, audio, vdeo
e caracteres especiais, devem ser codificados em ASCII antes de serem enviados
pelo SMTP. Ap os a transferencia, estes dados s
ao decodificados novamente em
formato ASCII. Para que isto seja possvel, ha necessidade de incluir cabecalhos
adicionais na mensagem. Esses cabecalhos extras s ao definidos no RFC 2045 e
no RFC 2046, que s ao extensoes do RFC 822 referentes ao MIME (Multipurpose
Internet Mail Extentions). Os dois cabecalhos MIME fundamentais para suporte
de multimdia sao: Content-Type e Content-Transfer-Encondig. O primeiro
permite que o Agente de Usu ario destinat
ario realize uma acao adequada sobre
a mensagem, por exemplo, execuc ao de uma rotina de descompress ao JPEG. O
segundo alerta o Agente de Usu ario destinat
ario que o corpo da mensagem foi
codificado em ASCII.
30.8 POP3 - Post Office Protocol Version 3

E do modelo OSI definido no RFC
AO
1939. Ele e um protocolo de acesso de correio eletr
onico extremamente simples,
e como conseq uencia bastante limitado. Por padr ao, ele utiliza o TCP como
protocolo de transporte via porta 110.
Seu funcionamento tpico e da seguinte forma. O Agente de Usu ario, agindo

como cliente, abre uma conex ao TCP com o Servidor de Correio que age como
servidor. Com a conex
ao ativada, o protocolo passa por tres fases: AUTORIZAC
AO,
301
TRANSAC e ATUALIZAC
AO
AO.
Durante a fase de autorizac ao, o Agente de Usu ario envia um nome de

usuario e uma senha (às claras) para autenticar o usu
ario. Na fase de transac
ao,
as mensagens s tambem nesta fase que o Agente
ao transferidas ao cliente. E
de Usu ario pode marcar/desmarcar as mensagens que dever ao ser apagadas, e
obter estatsticas de correio. A fase de atualizacao ocorre apos o cliente ter
solicitado o encerramento da conex ao. Nesse momento, o Servidor de Correio
apaga as mensagens que foram marcadas.
Em uma transac
ao POP3, o Agente de Usu
ario emite comandos e o Servidor
de Correio emite uma resposta a cada comando recebido. Ha duas respostas
possveis:
+OK: indica que correu tudo bem com o comando anterior. Esta resposta
as vezes vem seguida de dados do servidor para o cliente;
`
-ERR: indica que houve algo errado com o comando anterior.
Os comandos do POP3 s
ao definidos na RFC 1939. Os principais s
ao:
USER: informa o nome de usu

ario;
PASS: informa a senha de usu

ario;
LIST: solicita a listagem das mensagens, e seus respectivos tamanhos,

presentes na caixa postal;
RETR: solicita o descarregamento de uma mensagem;
DELE: marca uma mensagem para ser deletada na fase de atualizac

ao;
QUIT: determina que o servidor envie um ok e ent
ao feche a conex
ao.
Uma caracterstica importante deste protocolo e o fato dele realizar uma

conex ao persistente, ou seja, em uma mesma sess ao TCP entre cliente e servi-
dor e possvel a transferencia de diversas mensagens.
Um Agente de Usu ario que utiliza POP3 frequentemente pode ser configu-
rado pelo usu ario final para LER-E-APAGAR ou para LER-E-GUARDAR. A
sequencia de comandos emitida por um Agente de Usu ario depende desta con-
figurac
ao.
No modo ler-e-apagar, os seguintes comandos s ao emitidos: LIST, RETR e

DELE. M ultiplas mensagens s
ao transferidas por meio de m ultiplas seq
uencias
de comandos RETR e DELE, uma seq uencia para cada mensagem. H a um
problema com o modo ler-e-apagar. O usu ario destinat
ario pode ser nomade e
querer acessar sua caixa de postal de muitas m aquinas. Desta forma, as men-
sagens ficam repartidas entre as m aquinas que estabeleceram conex ao com o
Servidor de Correio, n
ao permitindo a visualizac
ao em uma m aquina de men-
sagens baixadas por outra maquina diferente.
302
No modo ler-e-guardar, o Agente de Usu ario deixa as mensagens no Servidor

de Correio ap
os descarrega-las. Desta forma, o problema anterior de repartic
ao
de mensagens e resolvido.
Cabe ressaltar que o Agente de Usu ario, ao se conectar ao Servidor de Cor-

reio, descarrega todas as mensagens que est ao na caixa postal. Por este fato,
diz-se que este protocolo e off-line. Ou seja, o usu
ario final recebe todas as suas
mensagens e ent ao pode le-las e apaga-las do servidor de arquivo local mesmo
estando offline. Portanto, este protocolo se mostra interessante para usu arios
que pagam pelo acesso a Internet por tempo de conex ao, por exemplo, conex ao
discada.
Uma caracterstica bastante importante do POP3 e o fato dele guardar

informac
oes de estados durante uma sessao POP3. Em particular, monitora
as mensagens do usu ario marcadas para apagar. Contudo, n ao mantem in-
formac
oes de estado entre sess
oes POP3. Portanto, de certa forma diz-se que
este protocolo e COM ESTADO.
Este protocolo e bastante difundido atualmente. Contudo, h a desde 2003

uma proposta de atualizac
ao que recebe o nome de POP4. Porem, praticamente
nenhum progresso tem sido observado na utilizac
ao desta atualizac
ao.
30.9 IMAP - Internet Mail Access Protocol

E do modelo OSI definido no RFC
AO
2060. Ele e um protocolo de acesso de correio eletr
onico complexo e com muitos
recursos. Por padrao, ele utiliza o TCP como protocolo de transporte via porta
143.
Seu funcionamento tpico se assemelha bastante com o funcionamento do

POP3. Contudo, h a alguns novos recursos bastante interessantes para o usu ario.
A principal diferenca e com relac
ao `
a possibilidade do usu
ario poder criar pastas,
mover/copiar mensagens de uma pasta para outra e tambem realizar procurar
por palavras chaves. No POP3 todas essas funcionalidades s o podem ser exe-
cutadas com as mensagens na m aquina local do cliente. Enquanto que o IMAP
implementa comandos que permitem fazer essas manipulac oes com as mensagens
no Servidor de Correio, o que trouxe um avanco consider avel.
Uma outra caracterstica contrastante com o POP3 e com relac

ao `
a manutenc
ao
de informac
oes de estado. O POP3 somente mantem informac oes de estado du-
rante uma sessao POP3, enquanto o IMAP mantem informac oes tanto durante
sess
oes quanto entre sessoes IMAP. Por exemplo, os nomes das pastas e quais
mensagens estao associadas a elas devem ser mantidos. Portanto, diz-se que o
POP3 e um protocolo COM ESTADO.
Uma explicac ao sucinta do fluxo das mensagens e a seguinte. O servidor

IMAP sempre associa as mensagens que chegam ` a pasta INBOX do destinatario,
que, ent ao, pode transferir estas mensagens para uma nova pasta criada por ele,
le-las, apaga-las e assim por diante.
303
Outra caracterstica importante do IMAP e que ele tem comandos que per-
mitem que um Agente de Usu ario obtenha componentes de mensagens. Por
exemplo, um Agente de Usuario pode obter apenas o cabecalho ou somente
uma das partes de uma mensagem MIME multiparte. Essa caracterstica e u til
quando ha uma conex ao de largura de banda estreia entre o Agente de Usuario
e seu Servidor de Correio. Com uma conex ao deste tipo, o usu
ario pode decidir
n
ao baixar todas as mensagens de sua Caixa Postal, evitando, em particular,
mensagens longas que possam conter, por exemplo, arquivos grandes.
Hoje, um n umero cada vez maior de usu arios est

a enviando e acessando
e-mails por meio de seus browsers Web. Esse tipo de servico e provido por
praticamente todos os sites ISPs, bem como universidades e empresas impor-
tantes. Com esse servico, o Agente de Usu ario e um browser Web comum e o
usuario se comunica com sua Caixa Postal, tanto enviando quanto recebendo
mensagens, via HTTP, e n ao via os protocolos SMTP, POP3 ou IMAP. Con-
tudo, os Servidores de Correio continuam se comunicando entre si via SMTP.
Essa soluc
ao tambem e extremamente conveniente quando o usu ario est
a em
tr
ansito. Pois, como ocorre com o IMAP, usu arios podem organizar suas men-
sagens em uma hierarquia de pastas no servidor remoto. Na verdade, muitas
implementac oes de e-mail pela Web utilizam um servidor IMAP para prover a
funcionalidade de pastas e busca. Nesse caso, o acesso às pastas e mensagens e
provido por scripts que rodam em um servidor HTTP e usam o protocolo IMAP
para se comunicar com um servidor IMAP.
A tabela a seguir apresenta os principais aspectos na comparac

ao entre
IMAP e POP3.
Caracterstica POP3 IMAP

Onde o protocolo e definido RFC 1939 RFC 2060
Porta TCP usada 110 143
Onde as mensagens s ao armazenadas PC do usu
ario Servidor
Como as mensagens s ao lidas Offline Online
Tempo de conex ao exigido Pequeno Grande
Utilizac
ao de recursos do servidor Mnima Intensa
V
arias caixas de correio (pastas) Nao Sim
Bom para usu ario em transito Nao Sim
Controle do usu ario sobre o download Pequeno Grande
Downloads de mensagens parciais Nao Sim
Quotas de disco consistem um problema Nao Possvel

Implementac ao simples Sim Nao
Tabela 30.2: Comparac

ao entre IMAP e POP3
304
30.10 LDAP - LightWeight Directory Access Pro-

tocol
O LDAP e mais um protocolo de camada de aplicac ao que roda sobre o proto-
colo TCP. O servico LDAP segue o modelo cliente servidor, onde um ou mais
servidores contem as informac oes sobre os diret
orios em uma rede. Um cliente
LDAP se conecta ao servidor e faz um request, que e respondido pelo servidor
ou entao redirecionado para outro servidor. Os servidores LDAP armazenam
informac
oes como direitos de acesso, espaco disponvel por usu
arios, entre out-
ras. Cada um dos diret orios gerenciados pelo LDAP contem informac oes a
seu repeito como CreatorsName, CreateTimestamp, ModifiersName, Modifier-
sTimestamp. As estruturas no LDAP s ao armazenadas de forma hier arquica
e nao existe limitac
ao quanto a organizac
ao hierarquica como nos sistemas de
arquivos. Pode-se, por exemplo, adicionar as estruturas partes de nomes de
domnio, ou sistema operacional. As entradas no LDAP s ao chamadas Dis-
tinguished Names (DNs). Ao configurar um servidor utiliza-se o conceito de
sufixo (suffixe) para determinar qual o nvel mais alto da hierarquia est a sob
seu controle.
30.11 SNMP - Simple Network Management Pro-

tocol
O SNMP e um protocolo da camada de aplicac ao que foi desenvolvido para per-
mitir a execuc
ao de v
arias func
oes como: (i) Configurar Dispositivos Remotos;
(ii) Monitorar Performance da Rede (iii) Detectar Problemas na Rede e Acessos
Indevidos; (iv) Auditar a utilizac
ao da Rede.
Os componentes do servico de SNMP s ao o sistema de gerenciamento, que

pode ser qualquer m aquina rodando um software de gerenciamento, e os agentes
que sao as maquinas gerenciadas. Essas m aquinas podem ser computadores pes-
soais, servidores, switches, roteadores, etc. O sistema de gerenciamento envia
um request para um agente ou tambem pode enviar informac oes em alguns ca-
sos. O servico de SNMP pode ser configurado para especificar quais informac oes
devem ser informadas ao sistema de gerenciamento e quais sistemas de gerenci-
amento est ao autorizados a requisitar informacoes. Em geral, s
ao os sistemas de
gerenciamento que requisitam informac oes dos agentes, porem os agentes podem
utilizar mensagens chamadas traps para comunicar algo ao sistema em ocasi oes
especiais. Exemplos dessas situac oes s

ao temperatura elevada, tentativas de in-
vasao, altas taxas de utilizac
ao de mem oria ou CPU, etc.
Os sistemas de gerenciamento s ao organizados em comunidades por prop ositos

administrativos e seguranca. Quando um sistema de gerenciamento requisita
alguma informac ao dos agentes, os agentes recuperam as informac oes de uma
base chamada MIB - Managment Information Base. As mensagens do protocolo
SNMP s ao as seguintes: (i) Get - A mensagem mais simples onde o sistema de
gerencia solicita uma informacao especfica; (ii) Get-Next - Pesquisa por uma
informacao em toda a MIB; (iii) Set - Se for permitida a escrita na MIB; (iv)
Getbulk - Solicita que os dados enviados pelo agente sejam o maior possvel
305
respeitando um determinado valor e o MTU da linha; (v) Trap - Mensagem

n
ao solicitada enviada do agente para o sistema de gerenciamento. O protocolo
SNMP utiliza o as portas UDP/161 e UDP/162 (traps).
30.12 FTP - File Transfer Protocol

E do modelo OSI no RFC 959. Ele
AO
e implementado em dois programas, um cliente e outro servidor, portanto, ele
e classificado como aplicac
ao cliente-servidor.
Como seguranca mnima o protocolo FTP implementa um processo de au-

tenticac
ao e outro de permiss ao. A autenticacao e verificada atraves de um
c
odigo de usu ario e senha, j
a a permiss
ao, e dada em nvel de diret
orios e ar-
quivos.
Em uma sess ao FTP tpica, o usuario, sentado `

a frente de um hospedeiro (o
local), quer transferir arquivos de ou para um hospedeiro remoto. Na realidade,
um usu ario tambem pode transferir arquivos de um hospedeiro remoto para
outro hospedeiro remoto. Para acessar a conta remota, o usu ario deve fornecer
uma identificac
ao e uma senha (processo de autenticac ao). O usu ario final in-
terage com o FTP por meio de um AGENTE DE USUARIO FTP. Alguns dos
agentes mais utilizados atualmente s ao: SmartFTP; Cute FTP; FTP via Web;
Filezilla; Core FTP; WS FTP; LeechFTP; e gFTP.
Assim como o HTTP, o FTP tambem usa o TCP como protocolo de ca-
mada de transporte. Contudo, h a algumas diferencas importantes. Diferente
do HTTP, o FTP usa duas conex oes TCP paralelas para transferir um ar-
quivo: uma CONEXAO DE CONTROLE e uma CONEXAO DE DADOS. A
primeira e utilizada para enviar informacoes de controle, por exemplo, identi-
ficac
ao de usu
ario, senha, comandos para trocar diret orio remoto e comandos
de inserir/pegar arquivos. A conex ao de dados e usada para enviar efetivamente
os dados. Como s ao usadas conexoes distintas para controle e dados, dizemos
que o FTP envia informac oes de controle FORA DA BANDA. Por padr ao, as
portas utilizadas sao as 21 (conex
ao de controle) e 20 (conex ao de dados).
Diferentemente do HTTP, o FTP precisa manter informac oes de estado so-

bre cada usuario conectado ao servidor. Em particular, o servidor deve associar
a conexao de controle com uma conta de usu ario especfica e tambem deve
monitorar o diretorio corrente do usu

ario enquanto este passeia pela arvore do
diret
orio remoto. Portanto, diz-se que o FTP e um PROTOCOLO COM ES-
TADO.
Uma caracterstica bastante importante do FTP e o fato da conexao de con-

trole permanecer aberta durante toda uma sess ao enquanto e necess
aria uma
nova conexao de dados para transferencia da cada arquivo. Ou seja, se for
necess
aria a transferencia de dois arquivos entre os mesmos cliente e servidor,
em uma mesma sess ao FTP, somente uma conex ao de controle ser
a aberta, mas
ser
ao abertas duas conex oes de dados, uma para cada arquivo.
306
O FTP implementa tres modos de transferencias. S

ao eles:
Modo Ativo: o cliente e respons avel pela abertura da conex

ao de controle
e o servidor e respons
avel pela abertura da conexao de dados. O processo
acontece da seguinte forma. O cliente abre uma conex ao de controle em
uma porta rand omica, por exemplo 1553, com o servidor que est a escu-
tando em sua porta 21. O cliente envia ao servidor, por meio do comando
PORT, uma outra porta rand omica, por exemplo 1500, e seu endereco IP.
Entao, o servidor abre uma conex ao de dados com o cliente utilizando sua
porta 20 e a porta 1500 do cliente;
Modo Passivo: o cliente e respons

avel pela abertura de ambas as conexoes.
O processo acontece da seguinte forma. O cliente abre uma conex ao de
controle em uma porta rand omica, por exemplo 1553, com o servidor que
est
a escutando em sua porta 21. O cliente envia um comando PASV ao
servidor informando que o modo de conex ao ser
a passivo. Em resposta, o
servidor envia, por meio do comando PORT, uma porta rand omica, por
exemplo 1728, e seu endereco IP. Ent ao, o cliente abre uma conexao de
dados com o servidor utilizando uma outra porta rand omica, por exemplo
1500, e a porta 1728 do servidor;
Modo Passivo Estendido: este modo e muito similar ao modo passivo.

Contudo, o servidor, ao enviar o comando PORT, transmite ao cliente
somente o n umero da porta randomica (nao transmite seu endereco IP)
que estara escutando para o estabelecimento da conex ao de dados. O
cliente assume entao que ele dever
a se conectar ao mesmo endereco IP
que foi originalmente conectado. Este modo foi adicionado no protocolo
por meio da RFC 2428.
Cabe salientar que toda conex ao rand

omica acontece em portas maiores que
1023 e s ao conexoes n
ao privilegiadas. Os processos de conex ao em moto ativo
e passivo sao exemplificados na figura 30.4.
O FTP implementa dois tipos de conex ao: a an
onima e a com autenticacao.
A primeira e a mais utilizada, onde n ao e necess
ario o usuario informar login
e senha, basta identificar-se como anonymous. Contudo, somente arquivos e
diretorios p
ublicos do servidor de arquivo remoto ser ao acessados. Dependendo
da implementac ao do servidor FTP, e solicitada ao usu ario a entrada de seu
endereco de e-mail como campo de senha. Isto permite aos administradores
algum tipo de controle. Em alguns casos o pr oprio servidor FTP suprime a
solicitac
ao de senha preenchendo este campo com valores padr oes (ex. lftp@ e
[email protected]).
O protocolo FTP, assim como o HTTP, envia comandos e respostas por meio
da conexao de controle no formato ASCII. Contudo, o FTP permite que o cliente
especifique o formato dos dados armazenados a serem transferidos na conex ao
de dados. Os formatos mais utilizados s
ao: ASCII, Binary, EBCDIC e USASCII.
A lista de comandos do FTP e de tamanho consider

avel. Os principais s
ao:
CD: permite alterar o diret

orio de trabalho remoto;
307
Figura 30.4: Modos de transmiss

ao do FTP
CLOSE: solicita o encerramento da sess

ao FTP, ou seja, o encerramento
da conex
ao de controle;
DELE: solicita ao servidor a deletar um arquivo no servidor remoto;
EPSV: informa ao servidor a entrada no modo de transferencia passivo
estendido (n
ao especificada na RFC 959, especificada em outra RFC);
GET: solicita ao servidor a transferencia de uma c
opia de um arquivo
do servidor remoto (n
ao especificada na RFC 959, especificada em outra
RFC);
HELP: retorna a documentac
ao sobre como usar o FTP, inclusive a lista
de comandos;
FTP: inicia uma sec
ao FTP (inicializa o programa FTP);
LIST: retorna a listagem de arquivos em um diret
orio remoto ou conte
udo
de um arquivo do servidor remoto;
OPEN: abre uma conex ao com um servidor FTP, ou seja, abre uma
conex
ao de controle servidor remoto;
PASS: informa ao servidor a senha do usu

ario;
PASV: informa ao servidor a entrada no modo de transferencia passivo;
PORT: envia um endereco IP e uma porta que ser
ao utilizados na abertura
de uma conex
ao futura, ou pelo servidor ou pelo cliente;
PUT: realiza a transferencia de uma c
opia de um arquivo da m
aquina local
ao servidor remoto (nao especificada na RFC 959, especificada em outra
RFC);
PWD: informa o diret
orio de trabalho corrente no servidor remoto;
308
QUIT: fecha uma sec

ao FTP (finaliza o programa FTP);
RETR: solicita ao servidor a transferencia de uma c
opia de um arquivo
do servidor remoto;
REST: solicita ao servidor o reincio da transferencia de uma c

opia de um
arquivo do servidor remoto a partir de certo ponto;
STOR: realiza a transferencia de uma c
opia de um arquivo da m
aquina
local ao servidor remoto;
TYPE: configura o formato de arquivo a ser transferido;
USER: informa ao servidor remoto o nome do usu

ario.
No FTP, cada comando e seguindo de uma resposta, que e enviada do servi-

dor ao cliente. Assim como no HTTP, as respostas s ao codificadas em n
umeros
de tres dgitos com uma mensagem opcional ap os o n
umero. As respostas mais
tpicas, junto com suas possveis mensagens s
ao as seguintes:
1xx: Resposta preliminar positiva. A acao requisitada se iniciou, mas

haver
a uma outra resposta antes de seu comeco;
2xx: Resposta definitiva positiva. A acao requisitada se completou. Agora

o cliente pode fazer outra solicitac
ao;
3xx: Resposta intermediaria positiva. O comando teve sucesso, mas um
outro comando e necess
ario antes do servidor poder executar efetivamente
a solicitac
ao feita;
4xx: Resposta preliminar negativa. O comando n
ao foi bem sucedido, mas
o cliente pode tent
a-lo novamente;
5xx: Resposta definitiva negativa. O comando n
ao foi bem sucedido e o
cliente n
ao deve solicit
a-lo novamente;
x0x: A falha se deu por motivos de erro de sintaxe;
x1x: Resposta a uma solicitacao de informac ao. Por exemplo, 125 -

Conex
ao de dados j
a aberta, iniciando transferencia;
x2x: Resposta a uma solicitac ao de informac
ao referente `
a conex
ao. Por
exemplo, 425 - N
ao e possvel abrir a conex
ao de dados;
x3x: Resposta a uma solicitac

ao de informac
ao referente autenticac
ao e
conta de usu
ario. Por exemplo, 331 - Nome de usu ario OK, senha requi-
sitada;
x4x: Ainda n
ao especificada;
x5x: Indica o estado do servidor de arquivo. Por exemplo, Erro ao escrever

o arquivo.
309
Vale mencionar que o protocolo TFTP (Trivial File Transfer Protocol) e uma
opc
ao para quem n ao necessita da robustez do protocolo FTP. O TFTP usa o
protocolo UDP/69 para fazer a entrega dos pacotes, ao contr ario do protocolo
FTP que usa o protocolo TCP. As principais caractersticas deste protocolo
s
ao: nao permite visualizac
ao dos diretorios; n
ao implementa autenticac
ao de
usuarios; e n
ao implementa mecanismos de criptografia. As operac oes de es-
crita/leitura s
ao descritas pelas figuras 30.5
Figura 30.5: Processo de escrita/leitura do TFTP
30.13 IP - Internet Protocol

O IP (Internet protocol) e um protocolo de camada de rede que prove mecan-
ismos de fragmentacao e remontagem de unidades chamadas datagramas para
a transmissao por diversas redes com diferentes unidades m aximas de trans-
ferencias. O protocolo IP n ao e orientado a conex ao e nao possui controle
de fluxo, confirmac
oes ou sequenciamento. O IP utiliza um esquema de en-
derecamento de 32 bits que e dividido em tres partes que s ao rede, subrede e

host. Os enderecos IP podem der divididos em classes de acordo com o n umero
de bits que reservam para identificac
ao da rede. As mascaras de sub-rede servem
para identificar qual a rede e quantos host s ao possveis na rede. As mascaras
s
ao compostas por diversos bits 1 seguidos de bits 0. As formas de enderecar
um pacote IP s ao o unicast, multicast e broadcast.
O cabecalho do IP e formado pelos seguintes campos: (1) Vers ao: Indica

a vers
ao utilizada. (2) IP Header Lenght: Indica o tamanho do cabecalho em
multiplo de 32 bits. (3) Type of Service: Especifica a maneira com a qual os pro-
tocolos de camadas superiores querem que o pacote IP seja tratado. Os nveis
310
de QoS s ao assinalados por meio desse campo do cabecalho. (4) Total Lenght:
Tamanho total do datagrama (dados e cabecalho). (5) Identification: Identi-
fica a qual datagrama pertence um fragmento. (6) Time to Live: Contador de
tempo de vida do pacote. Decrementado a cada hop. (7) Protocol: Identifica
qual protocolo de camada superior est a encapsulado. (8) Header Checksum:
Identifica se cabecalhos estam corrompidos. (9) Source/Destination Address.
(10) Options e Padding: Suporta opc oes (Ex: Seguranca) e Preenchimento.
Com o crescimento das redes os enderecos IP est ao se tornando um prob-

lema para os administradores da Internet. Apesar de matematicamente serem
possveis em torno de 4 bilh
oes de enderecos, muitos deles nao podem ser uti-
lizados ou simplesmente s ao desperdicados devido ao esquema de distribuic ao
de enderecos inadequado baseado em classes. Um outro problema decorrente e
a sobrecarga das tabelas de roteamento. Para solucionar o problema surgiu o
IPv6 porem ate que a migrac ao ocorra por completo ser ao necessarios alguns
anos segundo especialistas. Uma outra solucao para este problema e chamada IP
Classless. O esquema de enderecamento padr ao divide os enderecos nas classes
A,B e C onde a diferenca entre a quantidade de enderecos em cada uma das
classes e muito grande, fazendo com que ocorra um desperdcio muito grande
de enderecos. O esquema IP Classless utiliza uma mascara de 32 bits para
identificar a rede. Exemplos de mascara s ao:
11111111 11111111 11111111 00000000 255.255.255.0

11111111 11111111 00000000 00000000 255.255.0.0
11111111 11111111 11111111 11111000 255.255.255.252
11111111 11100000 00000000 00000000 255.32.0.0
Com esta estrategia e possvel criar redes com tamanhos mais adequados as
necessidades. Para identificar como um datagramas deve ser encaminhado por
um roteador, por exemplo, e feito um AND l ogico da mascara com o endereco
IP de destino do datagramas para pesquisar por qual linha ele deve sair.
O endereco de broadcast em uma rede IP e sempre o u ltimo endereco da

faixa. Por exemplo: Na rede 10.0.0.0/24, o endereco de broadcast e 10.0.0.255,
enquanto em na rede 172.22.4.0/22 o endereco de broadcast seria 172.22.7.255.
30.14 TELNET - TELetype NETwork

o protocolo de CAMADA DE APLICAC do modelo OSI definido no RFC
E AO
854 (na verdade tambem em diversos outros RFCs). Ele e um protocolo popular
utilizado para fazer login remoto entre qualquer par de hospedeiros. Por padr
ao,
ele utiliza o TCP como protocolo de transporte via porta 23. Na verdade, nada
impede que sejam utilizadas outras portas.
Este protocolo e implementado em dois programas, um cliente e outro servi-

dor, portanto, ele e classificado como aplicac
ao cliente-servidor. Porem, o termo
Telnet tambem e utilizado para se referir ao software que implementa o pro-
grama cliente do protocolo. A m aquina que abre a conex ao e a que pretende
enviar caracteres, e portanto, e a considerada cliente. A m aquina que recebe os
311
caracteres enviados e a considerada servidora.
As tres caractersticas mais marcantes deste protocolo s

ao:
Todos os dados, inclusive senhas, n

ao s
ao criptografados (o que o torna
bastante vulner
avel);
Nao h
a autenticac
ao para se garantir que o servidor e realmente quem ele
diz que e;
Cada caractere digitado pelo usu ario (no cliente) ser
a enviado ao hos-
pedeiro remoto e este devolver a uma c opia (eco) do caractere digitado
que sera apresentado na tela do Telnet do usu ario. Esse eco e utilizado
para garantir que os caracteres vistos pelo usuario do Telnet j
a foram re-
cebidos e processados no local remoto. Assim, cada caractere atravessa
literalmente a rede duas vezes.
A figura 30.6 apresenta o cen ario tpico de envio de caracteres via Telnet.
A seguir, s
ao examinados os segmentos TCP que s ao enviados entre o cliente e
o servidor deste cen
ario. Admite-se que os n umeros de seq
uencia iniciais sejam
42 e 79 para cliente e servidor, respectivamente. Lembre-se que estes n umeros
representam os n umeros dos segmentos aguardados cada m aquina. Vamos aos
segmentos:
O primeiro e enviado do cliente ao servidor, contendo em seu campo de

dados um byte com a representac ao ASCII para a letra C (digitada pelo
usuario). Este segmento tambem tem 42 em seu campo de n umero de
seq
uencia. E mais, como o cliente ainda n ao recebeu nenhum dado do
servidor, esse segmento ter
a o n
umero 79 (n ao foi incrementado) em seu
campo de n umero de reconhecimento;
O segundo e enviado do servidor ao cliente. Esse segmento tem dupla
finalidade. A primeira e fornecer um reconhecimento para os dados que o
servidor recebeu. Ao colocar 43 no campo de reconhecimento, o servidor
esta dizendo ao cliente que recebeu com sucesso tudo ate o byte 42 e que
est
a aguardando os bytes de 43 em diante. A segunda finalidade e ecoar a
letra C. Ele tem o n umero de sequencia 79, que e o numero de seq
uencia
inicial do fluxo de dados de servidor para cliente dessa conex
ao TCP. Note
que o reconhecimento para dados do cliente para servidor e levado em um
segmento que carrega dados do servidor para o cliente. Tecnicamente essa
carona recebe o nome de PIGGYBACK;

O terceiro e enviado do cliente ao servidor. Seu u
nico prop
osito e recon-
hecer os dados que recebeu do servidor. Ele tem o campo de dados vazio,
tem o numero 80 no campo de n umero de reconhecimento porque o cliente
agora est
a aguardando os bytes de 80 em diante.
Vale a pena comentar que este protocolo vem perdendo bastante espaco para
o protocolo SSH. Pois o SSH prove todas as funcionalidades do Telnet com a
adic
ao de uma forte criptrografia de dados, inclusive senhas, e de uso de chaves
p
ublicas para a realizac
ao de autenticac
ao. Com este tipo de autenticac ao, se
garante que o servidor e realmente quem ele diz que e.
312
Figura 30.6: Cen

ario tpico de envio de caracteres via Telnet
313
Captulo 31
O Modelo de Refer
encia
OSI
O modelo de referencia OSI (Open Systems Interconnection) foi o primeiro passo

para a padronizacao internacional dos processos de comunicac ao de sistemas
abertos. Sistemas abertos sao aqueles que est ao abertos a comunicacao com
outros sistemas. Os princpios aplicados para se chegar ao modelo de 7 camadas
foram os seguintes:
Uma camada deve ser criada onde houver necessidade de abstrac

ao acional;
Cada camada deve executar tarefa bem definida;
O limite das camadas deve minimizar o fluxo de informac
oes sobre as
interfaces.
O modelo OSI n ao e uma arquitetura, pois n

ao especifica servicos e proto-
colos exatos de cada camada. Ele apenas indica o que cada camada deve fazer.
As 7 camadas propostas no modelo OSI e suas respectivas func oes sao:
1. Camada Fsica - Respons avel pela transmiss

ao de bits brutos por um canal
de comunicacao. As questoes mais comuns s ao representac
ao dos bits 0 e
1, tempo de vida de um bit, permitir ou nao transmiss oes simult
aneas nos
dois sentidos, pinagens, etc; (2)
2. Camada de Enlace - Transformar o canal de comunicac ao bruto em uma
linha que pareca livre de erros para a camada de rede. Deve implementar
mecanismos de fragmentac ao e montagem, controle de fluxo, tratamentos
de erros e mecanismos de confirmac ao caso o servico seja confi
avel. Para
melhorar o desempenho pode-se utilizar a tecnica de Pipelining. Deve
possuir tambem mecanismos de retransmiss ao;
3. Camada de Rede - Determinar como os pacotes s ao roteados da origem ao
destino. Evitar congestionamentos e atrasos excessivos. Deve se preocu-
par tambem com enderecamento e tamanhos de pacotes,que podem ser
diferentes nas diversas redes. E papel da camada proporcionar interoper-
abilidade entre as redes. Deve implementar servicos orientados a conex
ao
(circuitos virtuais) e n
ao orientados a conex
ao (datagramas).
314
4. Camada de Trasnporte - Deve receber dados da camada acima, dividi-los

em unidades menores e repassar essas unidades para a camada de rede.
A camada de transporte deve assegurar que todos os dados chegar ao cor-
retamente ao destino. E a camada que realiza o controle fim-a-fim. Um
processo em uma m aquina h
a mantem uma conversacao diretamente com
um processo em alguma outra m aquina. Entre as tarefas mais comuns
realizadas pelos protocolos dessa camada estao transferencia b
asica de
dados, multiplexac
ao, abertura de conex
oes, controle de fluxo e conges-
tionamento;
5. Camada de Sess ao - Permite que usu arios de diferentes maquinas esta-

belecam sessoes entre eles. Os servicos sao controle de dialogo (quem
deve transmitir a cada momento), gerenciamento de token (impedindo
que duas m aquinas tentem executar sess ao crtica ao mesmo tempo) e a
sincronizac
ao (que permite que transmiss oes longas parem e reiniciem do
ponto onde ocorreu interrupcao);
6. Camada de Apresentaca o - Preocupa-se com a sintaxe e a sem antica das
informac
oes transmitidas. O objetivo e permitir a transferencia de dados
entre entidades com diferentes representac
oes de dados. Definem as estru-
turas de dados a serem intercambiadas juntamente com a codificac ao dos
dados;
7. Camada de Aplicac ao - Contem os protocolos que implementam de fato

as aplicac
oes dos usu
arios.
315
Captulo 32
Roteamento
Tres importantes protocolos rote aveis s

ao o IP, o IPX e o AppleTalk. O IP e o
protocolo oficial da Internet e faz parte da pilha de protocolos TCP/IP, por isso
e o mais importante. Embora a maior atenc ao deve ser dada no IP, e impor-
tante saber que existem outros protocolos rote aveis (IPX/SPX e o AppleTalk).
Protocolos como o IP, o IPX/SPX e o AppleTalk fornecem suporte ` a camada 3
e s
ao, portanto, roteaveis.
Entretanto, h a protocolos que nao suportam a camada 3. Eles s ao classi-

ficados como protocolos n ao-rote
aveis. O mais comum desses protocolos n ao-
rote
aveis e o NetBEUI. O NetBEUI e um protocolo pequeno, r apido e eficiente,
cuja execucao se limita a um segmento. Para um protocolo ser rote avel, ele deve
propiciar a habilidade de atribuir um n umero de rede, assim como um n umero
de host, a cada dispositivo individual. Alguns protocolos, como o IPX, exigem
apenas que voce atribua um n umero de rede, porque usam um endereco MAC
de host para o n umero fsico. Outros protocolos, como o IP, exigem que voce
forneca um endereco completo, alem de uma m ascara de sub-rede. O endereco
de rede e obtido pela operacao AND do endereco com a m ascara de sub-rede.
Os protocolos de roteamento determinam os caminhos que os protocolos

roteados seguem para seus destinos. Exemplos de protocolos de roteamento
incluem o Routing Information Protocol (RIP), o Interior Gateway Routing
Protocol (IGRP), o Enhanced Interior Gateway Routing Protocol (EIGRP) e o
Open Shortest Path First (OSPF). Os protocolos de roteamento permitem que
os roteadores conectados criem internamente um mapa de outros roteadores na
rede ou na Internet. Isso permite o roteamento (ou seja, selec

ao do melhor
caminho e comutacao). Tais mapas tornam-se parte da tabela de roteamento
de cada roteador.
Os dois tipos de protocolos de roteamento s ao os Exterior Gateway Pro-

tocols (EGPs) e os Interior Gateway Protocols (IGPs). Os Exterior Gateway
Protocols roteiam os dados entre sistemas aut
onomos. Um exemplo de EGP e o
BGP (Border Gateway Protocol), o principal protocolo de roteamento externo
da Internet. Os protocolos RIP, OSPF, IGRP e EIGRP s ao exemplos de IGPs.
O administrador de rede pode inserir as informac

oes manualmente no roteador.
316
Os roteadores podem conhecer as informac oes uns dos outros durante o pro-
cesso. As entradas manuais nas tabelas de roteamento s ao chamadas de ro-
tas est aticas. As rotas descobertas automaticamente s ao chamadas de rotas
din amicas. Quando um algoritmo de roteamento atualiza uma tabela de rotea-
mento, seu principal objetivo e determinar as melhores informacoes para incluir
na tabela. Cada algoritmo de roteamento interpreta ` a sua maneira o que e
melhor. O algoritmo gera um n umero, chamado valor metrico, para cada cam-
inho atraves da rede. Geralmente, quanto menor o n umero da metrica, melhor
e o caminho. Voce pode calcular a metrica com base em uma u nica carac-
terstica do caminho; voce pode calcular metricas mais complexas combinando
v
arias caractersticas. As metricas comumente usadas pelos roteadores s ao as
seguintes:
Largura de banda - a capacidade de dados de um link;

Atraso - o tempo necess
ario para mover um pacote por cada link, da
origem ate o destino;
Carga - a quantidade de atividade em um recurso de rede, como um
roteador ou um link;
Confiabilidade - geralmente se refere `
a taxa de erros de cada link da rede;
N
umero de hops - o n umero de roteadores atraves dos quais um pacote
deve trafegar antes de chegar ao seu destino;
Pulsos (ticks) - o atraso em um enlace de dados que usa os pulsos de clock
do PC IBM (aproximadamente 55 milissegundos);
Custo - um valor arbitr
ario, geralmente baseado na largura de banda,
despesas monet
arias ou outras medidas, atribudo por um administrador
de rede.
32.1 Link State e Distance Vector

A maioria dos algoritmos de roteamento pode ser classificada como um dos dois
algoritmos b
asicos:
Vetor de Dist
ancias (Distance Vector );
Estado do Link (Link State).
A abordagem do roteamento de vetores de dist ancia determina a direc

ao
(vetor) e a dist
ancia de todos os links na internetwork. A abordagem do link
state (tambem chamado de shortest path first) recria a topologia exata da in-
ternetwork inteira (ou de pelo menos da parte onde o roteador est
a situado). A
abordagem hbrida balanceada combina aspectos dos algoritmos do link state e
do vetor de distancia. A seguir s
ao apresentados os procedimentos e os prob-
lemas de cada um desses algoritmos de roteamento e apresentam tecnicas para
minimizar os problemas.
Cada roteador que usa roteamento de vetor de dist

ancia comeca identificando
seus pr ` medida que o processo de explorac
oprios vizinhos. A ao de rede de vetor
317
de dist
ancia prossegue, os roteadores descobrem o melhor caminho para as redes
de destino, com base nas informac oes que recebem de cada vizinho. Quando
a topologia em uma rede de protocolo de vetor de dist ancia e alterada, devem
ocorrer atualizac
oes na tabela de roteamento. Da mesma forma que acontece
com o processo de explorac ao da rede, as atualizac
oes das alterac
oes na topolo-
gia prosseguem passo a passo, de roteador para roteador. Os algoritmos de vetor
de distancia solicitam que cada roteador envie toda a sua tabela de rotea-
mento para cada um dos vizinhos adjacentes. As tabelas de roteamento incluem
informacoes sobre o custo total do caminho (definido pela sua metrica) e o en-
dereco l
ogico do primeiro roteador no caminho para cada rede contida na tabela.
Loops de roteamento podem ocorrer se a convergencia lenta de uma rede em

uma configuracao nova provoca entradas de roteamento inconsistentes. Os algo-
ritmos de roteamento de vetores de dist
ancia sao autocorrigveis, mas um prob-
lema de loop de roteamento pode exigir primeiro uma contagem ate o infinito.
Para evitar esse problema prolongado, os protocolos de vetores de dist ancia de-
finem o infinito como um n umero m aximo especfico. Esse numero se refere a
uma metrica de roteamento (por exemplo, um contador de saltos simples).
O segundo algoritmo b asico usado para roteamento e o algoritmo de link

state. Os algoritmos de roteamento baseados em link state, tambem conheci-
dos como algoritmos SPF (shortest path first - primeiro caminho mais curto),
mantem um banco de dados complexo de informac oes sobre a topologia. En-
quanto o algoritmo de vetor de dist
ancia tem informac
oes n
ao especficas sobre
redes distantes e nenhum conhecimento sobre roteadores distantes, um algoritmo
de roteamento de link state mantem conhecimento completo sobre roteadores
distantes e de como est
ao interconectados. O roteamento de link state usa:
LSAs (Link-State Advertisements - aviso de estado do link);
Um banco de dados topol
ogico;
O algoritmo SPF e a
arvore SPF resultante;
Uma tabela de roteamento de caminhos e portas para cada rede.
Os engenheiros implementaram esse conceito de link state no roteamento
OSPF (Open Shortest Path First). Sempre que uma topologia de link state e
alterada, os roteadores que primeiro tomam conhecimento da alteracao enviam
informac
oes para outros roteadores ou para um roteador designado, as quais
todos os outros roteadores podem usar para atualizac
oes. Isso envolve o envio
de informac
oes comuns de roteamento a todos os roteadores na internetwork.
Existem duas quest oes relacionadas ao link state:
Requisitos de processamento e mem oria: Executar protocolos de rotea-
mento de link state, na maior parte das situacoes, requer que os roteadores
usem mais mem oria e executem mais processamento que os protocolos
de roteamento de vetor de dist ancia. Para roteamento de link state, a
mem oria deve ser capaz de reter informacoes de diversos bancos de dados,
da
arvore de topologia e da tabela de roteamento. Usar o algoritmo de
Dijkstra para calcular o SPF requer uma tarefa de processamento propor-
cional ao numero de links na internetwork, multiplicado pelo n umero de
roteadores na internetwork;
318
Requisitos de largura de banda: consumida para a sobrecarga inicial do

pacote de link state. Durante o processo inicial de explorac
ao, todos os
roteadores usando protocolos de roteamento de link state enviam pacotes
LSA para todos os outros roteadores. Essa acao sobrecarrega a internet-
work à medida que os roteadores fazem uma demanda em massa de largura
de banda e reduzem temporariamente a largura de banda disponvel para
o tr
afego roteado que transporta dados de usu arios. Depois dessa sobre-
carga inicial, os protocolos de roteamento de link state requerem geral-
mente apenas uma largura de banda mnima para enviar pacotes LSA
raros ou desencadeados por eventos que reflitam alterac
oes na topologia.
32.1.1 Vetor de Dist

ancias vs. Estado do Link
Voce pode comparar o roteamento de vetor de dist
ancia com o roteamento de
link state em diversas
areas-chave:
O roteamento de vetor de dist

ancia obtem dados topol
ogicos das informac
oes
da tabela de roteamento dos vizinhos. O roteamento de link state obtem
uma ampla vis ao de toda a topologia da internetwork acumulando todos
os LSAs necessarios;
O roteamento de vetor de dist ancia determina o melhor caminho, adicio-

nando ao valor metrico recebido `
a medida que informac
oes de roteamento
s
ao passadas de roteador para roteador. Para o roteamento de link state,
cada roteador opera separadamente para calcular o seu caminho mais curto
para as redes de destino;
Com a maior parte de protocolos de roteamento de vetor de dist ancia,

atualizac
oes de alterac
oes na topologia chegam em atualizacoes peri
odicas
de tabelas. As informac oes passam de roteador para roteador, geralmente
resultando em uma convergencia mais lenta. Com protocolos de rotea-
mento de link state, as atualizac oes s
ao normalmente desencadeadas por
alterac
oes na topologia. LSAs relativamente pequenos passados para todos
os outros roteadores resultam geralmente em um tempo de convergencia
mais r apido em qualquer alterac ao na topologia da internetwork.
Os protocolos de roteamento hbrido balanceado usam vetores de dist ancia

com metricas mais precisas para determinar os melhores caminhos ate as redes
de destino. Entretanto, eles diferem da maior parte dos protocolos de vetores
de distancia porque utilizam alterac
oes na topologia para desencadear atual-
izac
oes de bancos de dados de roteamento. O protocolo de roteamento hbrido
balanceado converge rapidamente, como os protocolos de link state. Entretanto,
ele difere dos protocolos de vetor de dist
ancia e de link state porque usa menos
recursos, como largura de banda, mem oria e sobrecarga de processador. Ex-
emplos de protocolos hbridos s
ao o IS-IS (Intermediate System-to-Intermediate
System) da OSI e EIGRP (Enhanced Interior Gateway Routing Protocol) da
Cisco.
319
32.2 Protocolos de Roteamento

32.2.1 RIP - Routing Information Protocol
O protocolo mais comumente usado para transferir informac oes de roteamento
entre roteadores localizados na mesma rede e o Routing Information Protocol
(RIP). Esse Interior Gateway Protocol (IGP) calcula a distancia para um host
de destino em termos do n umero de hops. O RIP permite aos roteadores atu-
alizar suas tabelas de roteamento em intervalos programaveis, normalmente a
cada 30 segundos. Uma desvantagem dos roteadores que usam RIP e o fato deles
estarem constantemente se conectando aos roteadores vizinhos para atualizar as
suas tabelas de roteamento, criando assim uma grande quantidade de trafego de
rede. O RIP e um protocolo de vetor dist
ancia. Como o contador de saltos e a
u
nica medida de roteamento usada pelo RIP, ele nao seleciona necessariamente
o caminho mais r apido para um destino.
Quando se usa o RIP, o numero m aximo de saltos pelos quais os dados podem
ser encaminhados e 15. Alguns avancos foram introduzidos na nova vers ao do
RIP, chamada de RIP2. Esta nova vers ao trata da questao de VLSMs (m ascara
de tamanho vari avel), autenticac
ao, e atualizac
oes de roteamento simultaneas
(multicast). RIP2 nao apresenta avancos expressivos em relacao ao RIP porque
ainda apresenta limitacoes na contagem de hops e lenta convergencia, o que
essencial nas grandes redes atuais.
32.2.2 OSPF - Open Shortest Path First

Uma descric
ao pode ser determinac ao de um caminho otimo, pois esse Interior
Gateway Protocol realmente usa v arios criterios para determinar a melhor rota
para um destino. Esses criterios incluem as medidas de custo, que s ao subdividi-
das em itens como a velocidade de rota, o tr afego, a confiabilidade e a seguranca.
H
a duas caractersticas principais no OSPF. A primeira, e um protocolo de
padrao aberto,. A segunda, e um protocolo baseado no algoritmo SPF (link-
state), tambem chamado de algoritmo de Dijkstra. O OSPF utiliza o conceito
de roteamento hierarquico.
OSPF apresenta algumas caractersticas importantes que s

ao:
N
ao h
a limite na contagem de hops;
O uso eficiente de VLSM e muito u

til na alocac
ao de enderecos IP;
OSPF usa multicast de IP para enviar atualizac

oes de link-state. Isto
garante menor processamento nos roteadores que nao est
ao escutando os
pacotes OSPF;
Apresenta melhor convergencia que o RIP;

Permite um melhor balanceamento de carga;.
Permite uma divisao l

ogica da rede, onde roteadores podem ser divididos
em
areas. Isto limita a explos
ao de atualizac
oes de link state por toda a
320
rede. Tambem fornece um mecanismo para agregar roteadores a limita a

propagac
ao desnecess
aria de informac
oes de subrede;
Permite a autenticac
ao de rota utilizando diferentes metodos para a aut-
enticac
ao de senha;
Permite a transferencia e marcac

ao de rotas externas inseridas em um Sis-
tema Aut onomo-AS. Isto rastreia rotas externas inseridas por protocolos
externos como o BGP.
32.2.3 IGRP e EIGRP

O IGRP(Interior Gateway Routing Protocol) e o EIGRP(Enhanced Interior
Gateway Routing Protocol) s ao protocolos de roteamento desenvolvidos pela
Cisco Systems, Inc. e, portanto, s ao considerados protocolos de roteamento
propriet
arios. O IGRP foi desenvolvido especificamente para tratar problemas
associados ao roteamento em grandes redes de v arios fabricantes, que estivessem
alem do escopo de protocolos como o RIP. Como o RIP, o IGRP e um protocolo
de vetor de dist ancia. Entretanto, ao determinar o melhor caminho, ele tambem
leva em considerac ao itens como largura de banda, carga, atraso e confiabilidade.
Os administradores de rede podem determinar a import ancia dada a qualquer
uma dessas metricas ou permitir que o IGRP calcule automaticamente o melhor
caminho. O EIGRP e uma vers ao avancada do IGRP. Especificamente, o EIGRP
fornece eficiencia operacional superior e une as vantagens dos protocolos de Link
State com as dos protocolos de vetor de dist ancia.
321
Captulo 33
Redes Ethernet
A rede Ethernet e um padr ao de rede local que foi padronizado pelo comite
IEEE 802 como IEEE 802.3. As redes Ethernet vem sendo, desde 1990, as mais
utilizadas para implementac
ao de LANs.
A Ethernet foi originalmente baseada na ideia de comunicar computadores

a partir de um cabo coaxial compartilhado que funcionava como um meio de
transmissao em broadcast. Dessa forma, os computadores disputam o meio para
realizar uma transmiss ao e podem ocorrer colisoes. Para controlar o acesso
ao meio de transmiss ao e as colis
oes, as redes Ethernet utiliza um protocolo
chamado CSMA/CD (Carrier Sense for Multiple Access with Colision Detec-
tion), que ser
a detalhado mais adiante.
No entanto, essa configurac ao era problem atica na medida que problemas

em qualquer parte do cabo interrompiam a comunicac ao em toda a rede. Para
contornar esse problema, foram introduzidos os os hubs. Porem, em termos do
domnio de colis
ao, nao h a diferencas entre um hub e um cabo u nico compar-
tilhado, o que imp oe restric
oes praticas ao tamanho da rede. A soluc ao para
esse problema e a utilizac
ao de switches, que limitam o domnio de colis
ao `
a um
enlace ponto-a-ponto.
33.1 Protocolo CSMA/CD

O CSMA/CD e um protocolo que permite acesso m ultiplo ao meio de trans-

miss
ao baseando-se em tres mecanismos b asicos que sao: (i) escuta da por-
tadora; (ii) detecc
ao de colis
oes e (iii) mecanismo de contencao. O protocolo
funciona da seguinte maneira:
1. Um adaptador pode comecar a transmitir a qualquer tempo, ou seja, n

ao
s
ao utilizados compartimentos slots;
2. Um adaptador nunca transmite um quadro quando percebe que que algum

outro adaptador est a transmitindo. Para isso, um adaptador que deseja
transmitir precisa escutar a portadora;
322
3. Um adaptador que est a transmitindo aborta sua transmiss

ao quando percebe
que algum outro adaptador est a transmitindo, ou seja, detecta colis
oes.
Alem disso, ao detectar uma colis
ao, um adaptador que esta transmitindo
tambem emite um sinal de reforco de 48 bits (jam signal ) para garantir
que os demais adaptadores tambem tomar ao conhecimento da colisao;
4. Apos abortar a transmiss
ao o adaptador entra em fase de contenc
ao, du-
rante a qual ter
a que esperar um tempo aleatorio antes de tentar trans-
mitir novamente. Esse tempo e determinado pelo algoritmo de backoff
exponencial.
O algoritmo de backof exponencial diz que, ap os a detecc

ao da n-esima co-
lis
ao, um adaptador dever a esperar por um tempo igual a 512Kt0 , onde t0 e o
tempo de transmis ao de um bit e K e um valor escolhido com igual probabili-
dade entre o conjunto {0, 1, 2, ..., 2m 1}, sendo m igual ao mnimo entre n e 10.
Dessa forma, apos um adaptador detectar uma colis ao pela primeira vez (n =
1) escolher
a um valor de K no conjunto {0, 1}. No caso de uma rede de 10Mbps,
o tempo de transmiss ao de um bit e igual a 0.1 microssegundos e supondo que
o K escolhido seja 1, ent ao o adaptador ter a que esperar por um tempo igual
a 51.2 microssegundos antes de uma nova tentativa de transmiss ao. Ap os a
segunda deteccao de colis
ao, o valor de K ser
a escolhido entre 0, 1, 2, 3. A partir
da decima colis
ao o valr de K ser a escolhido no conjunto {0, 1, 2, 4, ..., 1023}.
33.2 Fast Ethernet

O Padrao Fast Ethernet (IEEE 802.3u) foi lancado em 1995 como a evoluc ao
do padrao Ethernet original. As principais modificac
oes introduzidas foram o
aumento da velocidade de transmiss ao de 10 para 100 Mbps, a possibilidade
de transmiss
ao no modo full-duplex. O protocolo de acesso ao meio utilizado
e o CSMA/CD, assim como no padr ao Ethernet. No modo full-duplex, um
adaptador esta apto a receber e transmitir a qualquer momento e a utilizacao
do CSMA/CD e dispensada, na medida em que n ao existem mais colisoes nem
disputa pelo meio.
No padr
ao Fast Ethernet tambem foi introduzido um mecanismo de controle
de fluxo. Quando um receptor deseja que o tansmissor interrompa a transmiss
ao
por um tempo, ele envia um quadro especial chamado pause frame, que indica
o tempo que o transmissor deve esperar antes de continuar com a transmiss ao

(time-to-wait).
O padrao Fast Ethernet e subdividido em sub-padr oes de acordo com o meio

de transmissao utilizado. As principais sub-divis
oes do padrao Fast-Ethernet s
ao
as seguintes:
100Base-TX: E o sub-padr
ao mais utilizado para redes Fast Ethernet.
Ele funciona sobre cabos UTP de categoria 5 ou superior, embora utilize
apenas os pares laranja e verde do cabo de acordo com o padr oes de
terminac
ao TIA/EIA-568A e TIA/EIA-568B. Cada enlace pode ter no
323
maximo 100 metros de comprimento. O esquema de codificac

ao utilizado
no padr
ao 100Base-TX e o MLT-3;
100Base-FX: Essa e uma vers
ao que utiliza um par de fibras
opticas multi-
modo com terminadores do tipo SC, ST ou MIC. O esquema de codificac ao
utilizado e o NRZI;
100Base-SX: Assim como o padr ao 100Base-FX, tambem utiliza um par de
fibras opticas multimodo. O padr ao SX difere do FX por utilizar
optica
de ondas de comprimento curto (short wavelength), o que o torna mais
acessvel. No entanto, o padr
ao FX permite alcancar dist
ancias maiores;
100Base-BX: Transmiss ao e recebimento s
ao realizados por um u
nico cabo
de fibra, utiliza para isso, tecnicas de multiplexac
ao por comprimento e
onda.
33.3 Gigabit Ethernet

Em 1999, o padr ao Gigabit Ethernet (IEEE 802.3z) extendeu a velocidade das
redes Ethernet de 100 Mbps para 1 Gbps. Assim como o Fast-Ethernet, o padrao
Gigabit permite operacao nos modos half e full-duplex e utiliza o mecanismo
de controle de fluxo baseado em pause frames.No modo half-duplex ainda e uti-
lizado o protocolo CSMA/CD.
No entanto, com aumento da velocidade de transmis ao, para garantir que as

colis
oes sejam corretamente detecadas pelo CSMA/CD, foi necess ario extender
o slot-time mnimo de 64 para 512 bytes. Para cumprir este requisito e utilizado
o campo carrier extension, que e preenchido ate que o slot-time de um quadro
pequeno alcance 512 bytes. No receptor, o conte udo do campo de extens ao e
descartado. A diferenca entre o quadro Ethernet original e o quadro do padr ao
Gigabit e mostrada na figura 33.3.
Figura 33.1: Quadros Ethernet e Gigabit Ethernet
Utilizada puramente, esta modificac

ao afeta o desempenho na transmissao
de quadros pequenos devido a grande quantidade de carga inutil transmitida.
Para contornar esse problema, o padrao Gigabit tambem utiliza o recurso de
transmiss
ao em rajadas (frame bursting), permitindo que um conjunto de pa-
cotes pequenos sejam transmitidos em conjunto dentro de um unico quadro.
Assim como o padr ao Fast Ethernet, o padr

ao Gigabit tambem tem suas
sub-divis
oes. As princiapais sao:
324
1000Base-SX: Este padr ao opera utilizando optica de ondas de compri-

mento curto sobre um par de fibras multimodo. Com fibras opticas de
qualidade j
a e possve alcancar dist
ancias maiores que 500 metros com
esse padr
ao;
1000Base-LX: Opera utilizando optica de ondas de comprimento longo,

permitindo alcancar dist
ancias de ate 20 kil
ometros com fibras monomodo.
Quando utilizado com fibras multi-modo permite dist ancias de ate 500
metros;
1000Base-T: E o padrao para redes gigabit que utiliza cabos UTP. O

requisito mnimo do padr ao e um cabo da categoria 5, porem, cabos da
categoria 5e ou 6 s ao recomendados. A distancia maxima alcancada com
este padrao e de 100 metros;
1000Base-CX: Criado como uma alternativa para dist ancias de ate 25

metros. Ao inves de fibra
optica, utiliza cabos twiaxiais. Na pr
atica s
ao
pouco utilizados, uma vez que o o padr ao 1000Base-T usa cabos UTP, que
s
ao mais baratos e podem desempenhar a mesma func ao;
1000BASE-ZX e 1000BASE-LH: Esses dois padr oes utilizam transmiss

ao
em fibra monomodo, usando um comprimento de onda de 1550 nan ometros
para alcancar dist
ancias de ate 70 kil
ometros.
325
Captulo 34
Cabeamento Estruturado
34.1 Par Trancado

O cabeamento por par trancado (Twisted pair) e um tipo de fiac ao na qual
dois condutores s ao enrolados ao redor dos outros para cancelar interferencias
magneticas de fontes externas e interferencias m utuas (crosstalk) entre cabos
vizinhos. A taxa de giro (normalmente definida em termos de giros por metro)
e parte da especificac ao de certo tipo de cabo. Quanto maior o n umero de
giros, mais o rudo e cancelado. Foi um sistema originalmente produzido para
transmissao telef
onica analogica. Utilizando o sistema de transmiss ao por par
de fios aproveita-se esta tecnologia que j
a e tradicional por causa do seu tempo
de uso e do grande n umero de linhas instaladas.
Existem dois tipos de cabos par trancado:
Unshielded Twisted Pair - UTP (cabo sem blindagem): S ao quatro pares

de fios entrelacados e revestidos por uma capa de PVC e o mais usado
atualmente e mais barato.
Shield Twisted Pair - STP (cabo com blindagem): E igual ao UTP a
diferenca e que possui uma blindagem feita com a malha do cabo, que o
protege mais que o UTP. Porem e mais caro, menos usado e necessita de
aterramento. Este genero de cabo, por estar revestido diminui as inter-
ferencias eletromagneticas externas, protege mais da umidade, etc.
Considerando que o fator principal para determinar o alcance m aximo possvel

de um sistema e a atenuac
ao do sinal ao longo do cabo, foi necessario estabelecer
alguns modos de classificac
ao para o cabeamento em par met alico e o respectivo
hardware de conex ao. Criou-se ent
ao a subdivisao em uma serie de categorias e
classes por capacidades de desempenho. Nessa classificac ao, uma categoria ou
classe de desempenho superior do cabo significa maior eficiencia e uma menor
atenuac
ao. Dentre as categorias destacam-se a 5e e a 6.
34.1.1 Interfer
encias nos Cabos de Par Trancado
O Crosstalk nao ocorre apenas no par adjacente (pair to pair NEXT), mas em
todos os outros pares de um cabo UTP podem interferir com seus pr
oprios nveis
326
em ambas as extremidades do cabo, multiplicando o efeito dessa interferencia

sobre o par transmissor ou receptor.
Em razao destes nveis de interferencia poderem debilitar redes de alta veloci-
dade, alguns fabricantes de cabos comecaram a apresentar as taxas de NEXT,
FEXT, PSNEXT, ELFEXT e PS-ELFEXT para seus cabos CAT5e e Categoria
6. A Figura ?? ilustra essas interferencias
Figura 34.1: Interferencias entre fios em um cabo de par trancado
O NEXT (Near-End Crosstalk) e a interferencia no sinal de um par sobre

um outro na mesma extremidade do cabo.
O PS-NEXT e uma medida de crosstalk mais rigorosa que inclui a soma
total de todas as interferencias que podem ocorrer entre um par e todos os
pares adjacentes de um cabo.
O FEXT mede a interferencia de um par em uma extremidade do cabo em
outro par na outra extremidade do cabo. Essa medida utiliza operac ao full
duplex para detectar onde os sinais s ao gerados simultaneamente em ambas as
extremidades.
O ELFEXT (Equal-Level Far-End Crosstalk) mede o FEXT em relac ao ao
nvel do sinal recebido medido no mesmo par. Ele mede basicamente a inter-
ferencia sem os efeitos da atenuac
ao.
O PS-ELFEXT, uma medida comum em progress ao, mede a soma total
de todas as interferencias dos pares de uma extremidade em um par da outra
extremidade sem os efeitos da atenuac ao.
34.2 Categorias 5e
A letra eno nome da categoria significa Enhanced, ou seja, a categoria 5e
representa uma melhoria das caractersticas dos materiais utilizados na categoria
5, permitindo um melhor desempenho. Pode ser usado para freq uencias de ate
100MHz em redes 1000BASE-T e 1000BASE-TX. Ele e igual a categoria 5,
porem com especificac
oes adicionais como os parametros PS NEXT, Balanco,
PS ELFEXT, Return Loss.
O cabeamento Categoria 5 e normalmente direcionado para o mercado resi-
dencial, mas sua utilizac
ao vem caindo devido ao seu custo ser praticamente o
mesmo da Categoria 5e. Reforcando essa afirmativa, nos projetos atuais de infra-
estrutura e recomendada a utilizac
ao de cabeamento de, no mnimo, Categoria
5e para pequenas redes com poucos servicos ou que tenham car ater provis
orio
e Categoria 6 para as redes novas ou de maior porte.
327
34.3 Categoria 6
A Categoria 6 pode ser vista como um aperfeicoamento no projeto de infra-
estrutura das redes locais. Ela segue seus predecessores, as categorias 3, 4, 5 e 5e,
cada uma provendo maior capacidade de transporte de informac ao para usu arios
finais. Torna-se uma opcao que oferece alta performance para a distribuicao hor-
izontal em um sistema estruturado, permitindo suporte para aplicac oes como
voz tradicional (telefone anal
ogico ou digital), VoIP, Ethernet (10Base-T), Fast
Ethernet (100Base-TX) e Gigabit Ethernet a 4 pares (1000Base-T), com mel-
hor performance em relac ao a Categoria 5e. Ela permite ainda suporte para
aplicac
oes ATM e novas tecnologias como Ethernet a 10Gbps sem investimen-
tos adicionais na infra-estrutura existente.
Os sistemas Categoria 6 foram projetados para atender basicamente os seguintes
objetivos:
manter boa relacao custo x benefcio dos sistemas UTP, bem como facilitar
sua instalac
ao e operacao;
garantir a interoperabilidade com os atuais sistemas Categoria 5e;
roporcionar uma nova infra-estrutura com capacidade para servicos fu-
turos (redes de pr
oxima gerac
ao).
34.4 Categoria 5e vs. Categoria 6

A principal diferenca entre a Categoria 5e e a Categoria 6 est a na performance
de transmiss ao e na largura de banda estendida de 100MHz da Categoria 5e para
250MHz da Categoria 6. A largura de banda e a medida da faixa de freq uencia
que o sinal de informac ao ocupa. O termo e tambem usado em referencia ` as
caractersticas de resposta em freq uencia de um sistema comunicac ao. No sen-
tido mais qualitativo, a largura de banda e proporcional ` a complexidade dos
dados transmitidos. J a a performance se traduz em uma menor atenuac ao, mel-
hor NEXT, perda de retorno e ELFEXT, possibilitando uma melhor relac ao
sinal/rudo.
Devido a esses fatores (performance e largura de banda), associando uma
melhor imunidade ` as interferencias externas, os sistemas que operam em Cat-
egoria 6 sao mais est aveis em relac
ao aos sistemas baseados na Categoria 5e.
Isto significa reduc
ao nas retransmiss oes de pacotes, proporcionando uma maior
confiabilidade e estabilidade para a rede.
Outro fato que deve ser considerado e que os requisitos para o link (meio de
transmiss ao entre dois pontos, nao incluindo a conexao de equipamentos) e canal
(meio de transmiss ao fim-a-fim entre dois pontos no qual existem equipamentos
de aplicac
oes especficos conectados) na Categoria 6 s ao compatveis com os da
Categoria 5e, fazendo com que os projetistas escolham a Categoria 6, substi-
tuindo as redes Categoria 5e. A tabela 34.2 resumo as principais informac oes
sobre as categorias de cabos UTP.
328
Figura 34.2: Principais Caracteristicas do cabeamento UTP
34.5 Cabeac
ao Estruturada Norma EIA/TIA
568
Pode-se definir a cabeac
ao estruturado como um sistema baseado na padronizacao
das interfaces e meios de transmiss
ao, de modo a tornar o cabeac
ao independente
da aplicac
ao e do layout. O cabeac
ao estruturado descreve ainda os sistemas de
rede interna e de campus e sua interconex ao com a planta externa.
34.5.1 Sistemas de Cabeamento Estruturado

Reconhecendo a necessidade de padronizar o Sistema de Cabeac ao Estrutu-
rado diversos profissionais, fabricantes, consultores e usuarios reuniram-se sob
a orientac
ao de organizacoes como ISO/IEC, TIA/EIA, CSA, ANSI, BICSI e
outras para desenvolver normas que garantissem a implementac ao do conceito
do mesmo. Apesar deste trabalho resultar em diversas normas a mais conhecida
no Brasil e a ANSI/TIA/EIA 568-A (vers ao revisada da ANSI/TIA/EIA 568
que inclui as especificac
oes para cabeac
ao categoria 4 e 5)
O conceito de Sistema de Cabeac ao Estruturada baseia-se na disposic ao
de uma rede de cabos, com integrac ao de servicos de dados e voz, que facil-
mente pode ser redirecionada por caminhos diferentes, no mesmo complexo de
cabeac
ao, para prover um caminho de transmiss ao entre pontos da rede distin-
tos. Um Sistema de Cabeac ao Estruturada EIA/TIA 568A e formado por seis
subsistemas conforme ilustrado na figura 34.3 e descritos a seguir.
Entrada do Edifcio;
Sala de Equipamentos;
Cabeac
ao do Backbone;
Arm
ario de Telecomunicac
oes;
Cabeac
ao Horizontal;

Area de Trabalho.
As instalac
oes de entrada no edifcio fornecem o ponto no qual e feita a inter-
face entre a cabeacao externa e a cabeac ao intra-edifcio e consistem de cabos,
329
Figura 34.3: Sistema de Cabeac

ao Estruturada
equipamentos de conex ao, dispositivos de protec ao, equipamentos de transicao

e outros equipamentos necess arios para conectar as instalac
oes externas ao sis-
tema de cabos local.
As salas de equipamento geralmente alojam equipamentos de maior com-
plexidade que os do arm ario de telecomunicac oes. Qualquer uma ou todas das
func
oes de um arm ario de telecomunicac oes podem ser atendidas por uma sala
de equipamentos. Ela tambem contem a conex ao cruzada principal ou a conex ao
secundaria, usada conforme a hierarquia do sistema de cabeac ao backbone.
O subsistema de cabeamento backbone, tambem chamado de cabeamento
vertical, propicia a interligacao entre os arm arios de telecomunicacoes, salas
de equipamento e instalac oes de entrada. Ele consiste dos cabos de Back-
bone, cross-connects intermedi ario e principal, terminac
oes mecanicas e cabos
de conex ao ou de jumper utilizados para a ligac ao de backbone para backbone.
Isto inclui:
Ligac
ao vertical entre os pisos (subidas ou risers)
Cabos entre a sala de equipamentos e o local das instalac

oes de entrada
dos cabos no predio
Cabos entre os predios (inter-predios)
Os cabos homologados na norma EIA/TIA 568A para utilizac

ao como Back-
bone s
ao mostrados na tabela 34.1:
Tipos Dist
ancias M
aximas
Cabo UTP de 100 ohms (22 ou 24 AWG) 800 metros(2625 pes) Voz
Cabo STP (par trancado blindado) de 150 ohms 90 metros(295 pes) Dados*

Fibra Optica Multimodo de 62,5/125 m 2000 metros (6560 pes)

Fibra Optica Monomodo de 8,5/125 m 3000 metros (9840 pes)
Tabela 34.1: Cabos homologados para cabeac

ao Backbone e as respectivas
dist
ancias m
aximas
330
Vale ressaltar que o alcance do Backbone depende da aplicac

ao. As dist
ancias
maximas especificadas acima s ao baseadas na transmiss
ao de voz em UTP e de
dados em STP e fibras opticas. A dist
ancia de 90 metros para STP d a-se para
aplicac
oes com um espectro de largura de banda de transmiss ao de 20 a 300
MHz. Esta mesma dist ancia tambem se aplica ao UTP para espectros com
largura de banda de 5 a 16 MHz para Cat 3, 10 a 20 MHz para Cat 4 e de 20 a
100 MHz para Cat 5.
Outros requisitos de projeto s ao:
Topologia em estrela
N
ao possuir mais do que dois nveis hier
arquicos de cross-connects
N
ao s
ao permitidos Bridge Taps
Os cabos de conex
ao ou de jumper no cross-connect principal ou inter-
medi
ario n
ao podem exceder 20 metros (66 pes)
Evitar a instalac
ao em areas onde existam fontes de interferencias eletro-
magneticas ou de radio freq
uencia.
As figuras 34.4 e 34.5 representam o modelo geral de cabeamento backbone

em topologia estrela e as respectivas configurac
oes limites.
Figura 34.4: Cabeamento Backbone em topologia estrela

Figura 34.5: Estrutura geral e as configurac

oes limites para o subsistema de
cabeac
ao Backbone
331
O arm ario de telecomunicacoes e a

area dentro de um edifcio que aloja
o equipamento do sistema de cabeamento de telecomunicac oes. Inclui as ter-
minacoes mecanicas e/ou cross-connects para o sistema de cabeamento horizon-
tal e backbone.
O subsistema de Cabeac ao Horizontal compreende os cabos que v ao desde a
Tomada de Telecomunicac
oes da Area de Trabalho ate o Armario de Telecomu-
nicac
oes. O subsistema de Cabeac ao Horizontal possui os seguintes elementos:
Cabeac
ao Horizontal;
Tomada de Telecomunicac
oes, tambem chamado Sada de Informac
ao;
Terminac
oes de Cabo;
Cross-Connections.
Existem tres tipos de meios de transmiss

ao a serem considerados como opc
oes
para o cabeamento horizontal, todos para a dist ancia m
axima de 90 metros:
Cabo UTP de 4-pares, 100 ohms (condutores s

olidos de 24 AWG)
Cabo STP de 2-pares, 150 ohms

Cabo de Fibra Optica de 2-fibras, 62,5/125 m
Atualmente o cabo coaxial de 50 ohms e reconhecido como um meio de

transmiss
ao. Entretanto, nao recomenda-se a sua utilizac
ao em instalac
oes no-
vas. Espera-se a remoc
ao deste meio na proxima revis
ao desta norma.
A figura 34.6 apresenta as dist
ancias limites para o subsistema de cabec ao
horizontal bem como para o subsistema da area de trabalho que ser
a apresentado
em seguida.
Figura 34.6: Dist

ancias limite para os subsistemas de cabeac
ao horizontal e
area
de trabalho
A norma preve 100 metros total para a Cabeac

ao Horizontal: 90 metros entre
o Armario de Telecomunicac
oes e as Tomadas de Telecomunicac oes (conectores
de parede); 10 metros para cabos entre uma estac ao de trabalho e o conector
332
de parede, (em geral, 3 metros) mais as conex oes internas do Armario de Tele-
comunicac oes e entre este e os equipamentos ativos (7 metros restantes). Em
complemento, cada area de trabalho deve ter no mnimo DUAS posic oes de
sada de informac
ao: uma para voz e outra para dados.
Figura 34.7: Tomada de Telecomunicac

oes
Os componentes da area de trabalho estendem-se da tomada de telecomu-

nicac
oes ate o equipamento da estac
ao. A fiac
ao da
area de trabalho e projetada
para ser de interconex ao relativamente simples, de forma que deslocamentos, ex-
pans oes e alterac
oes possam ser efetuados com facilidade. Os componentes da
area de trabalho s
ao:
Equipamento da estac
ao: computadores, terminais de dados, telefone, etc.;
Cabos de ligac
ao - cord
oes modulares, cabos de adaptac
ao, jumpers de
fibra;
Adaptadores.
Nesse contexto, a figura 34.8 ilustra o Sistema de Cabec

ao Estruturada
EIA/TIA 568:
Figura 34.8: Sistema de Cabeac

ao Estruturada
34.6 Desempenho do Hardware e Meios de Trans-

miss
ao
A norma EIA/TIA 568 classifica o sistema de cabeac ao em categorias levando
em considerac
ao aspectos de desempenho, largura de banda, comprimento,
atenuac
ao e outros fatores de influencia neste tipo de tecnologia. A seguir,
333
ser
ao apresentadas as categorias de cabeac
ao com tecnologia de par trancado
UTP e de fibra
optica.
34.6.1 Cabeamento UTP

Os cabos UTPs s ao compostos de pares de fios trancados n
ao blindados de 100
Ohms. Este tipo de cabo, nos dias de hoje, s
ao projetados para alto desempenho
na transmiss ao de dados ou voz. Segundo a norma, o cabo UTP pode ser
classificado em tres categorias como mostrado abaixo:
Categoria 3 - Utiliza cabos com pares de fios trancados solidos de bitola 24

AWG. Os fios AWG24 apresentam uma imped ancia tpica de 100 Ohms,
a 16 MHz. Estes cabos s ao utilizados para transmiss ao de sinais ate 16
MHz.
Categoria 4 - Utiliza cabos com pares de fios trancados s
olidos de bitola
22 ou 24 AWG, com imped ancia de 100 Ohms a 20 MHz. Este cabos s ao
utilizados para transmiss
ao ate uma largura de banda de 20 MHz;
Categoria 5 - Utiliza cabos com pares de fios trancados sem blindagem
de bitola 22 ou 24 AWG e imped ancia de 100 Ohms a 100 MHz. Este
tipo de categoria e recomend
avel para aplicac
oes com taxa de transmiss
ao
elevada, por exemplo, para transmiss ao de imagens e dados a 100 Mbps.
A atenuac ao e comumente derivada da medida do sinal de varredura da

freq
uencia na sada de um cabo de comprimento maior ou igual a 100 metros
(328 ft), ou seja, e a perda de potencia do sinal no meio, em func
ao da distancia a
uma determinada freq uencia. As perdas por diafonia ou NEXT s ao comumente
derivadas de medidas de varredura de freq uencia. Por exemplo, na comunicac ao
de voz, seus efeitos s ao sentidos por linhas cruzadas, isto e, vozes estranhas que
s
ao escutadas durante uma ligac ao telef
onica. A imped ancia caracterstica do
cabo UTP para Cabeac ao Horizontal e Backbone e de 100 Ohms + 15% de 1
MHz ate a maior freq uencia da categoria (16, 20 ou 100 MHz).
Em complemento, os Terminadores para cabo UTP devem utilizar contatos
por deslocamento por isolador (IDC). Os limites m aximos para jumper/cord oes
de ligac
ao s
ao:
20 m para cross-connect principal;

20 m para cross-connect intermedi
ario;
6 m no arm
ario de telecomunicac
oes;
3 m na estac
ao de trabalho.
A terminacao dos cabos horizontais dever

a ser feita com material de conex ao
da mesma categoria ou superior do cabo UTP utilizado na Cabeac ao Horizontal.
Por outro lado, os cabos utilizados para cordoes de ligac
ao e jumpers de cross-
connect devem pertencer ` a mesma categoria do cabo UTP usado na Cabeac ao
Horizontal. Assim, um sistema de cabeacao UTP s o podera ser classificado como
categoria 3, 4 ou 5 se todos os componentes do sistema de cabeac ao atenderem
aos requisitos da categoria.
334
34.6.2
Fibra Optica
A fibra optica pode ser utilizada tanto para a Cabeac ao Horizontal como para a
Vertical. A fibra para Cabeac ao Horizontal e do tipo multimodo de 62,5/125mm
com um mnimo de duas fibras. A Cabeac ao Vertical ou Backbone utiliza fibras
dos tipos multimodo de 62,5/125mm e monomodo formados em grupos de 6 ou
12 fibras.
As premissas para uma Cabeac ao Backbone com fibra opticas, tem sido
e continuam a ser baseadas em fibras multimodo de 62,5/125mm, devido ` a
possibilidade de uso de transmissores opticos com LED nessas fibras. Com
o rapido crescimento dos requisitos de largura de banda, atualmente, tem-se
instalado fibras
opticas monomodo em adic ao ` as fibras multimodo, para atender
os requisitos atuais e futuros. Sistemas de fibras monomodo atendem tanto
maiores bandas de freq uencias como tambem tem maior capacidade para longas
distancias do que as fibras
opticas multimodo. A Figura 34.9 ilustra os tipos de
fibras
opticas empregados.

Figura 34.9: Tipos de Fibras Opticas
Os conectores especificados para fibra optica sao os 568SC. Os conectores

pticos seguem um esquema de cores para sua identificac
o ao. A cor bege especi-
fica o conector/acoplamento multimodo de 62,5/125mm e a cor azul especifica
o conector/acoplamento monomodo de 8,3/125mm.
Para assegurar que os conectores 568SC manter ao uma correta polarizacao
atraves do sistema de cabeacao, deve-se ter uma correta orientac ao do adaptador
utilizado. A Cabeac ao Horizontal deve ser instalada de tal forma a casar um
numero mpar da fibra com o pr oximo n umero par da fibra, por exemplo: fibra
1 com fibra 2; fibra 3 com fibra 4 e assim sucessivamente. Cada segmento da
cabeacao deve ser instalado seguindo a orientacao invertida (cross-over) do par,
de tal modo que fibras de n umero mpar sao posic
ao A numa ponta e posic ao B
na outra ponta, enquanto que fibras de n umero par s ao posic

ao B numa ponta
e posic
ao A na outra ponta.
A orientacao invertida (cross-over) deve ser conseguida pelo uso consecutivo
da numerac ao das fibras (por exemplo 1, 2, 3, 4, ...) em ambos os lados da
fibra, mas os adaptadores 568SC devem ser instalados de maneira oposta em
cada ponta (por exemplo A-B, A-B, ... numa ponta e B-A, B-A, ... na outra
ponta).
O principal motivo para especificac ao dos conectores de fibra 568SC e a
padronizacao com a norma IEC Europeia. Hoje s ao muito utilizados conectores
ST. Entretanto, e recomendado a substituic ao gradativa dos conectores ST por
568SC.
335
A norma EIA/TIA 568A especifica, tambem, as sadas de telecomunicac

oes
para fibra
optica com as seguintes caractersticas:
A caixa de montagem em superfcie deve ser fixada diretamente sobre a

caixa eletrica, seguindo um padr
ao de 4x 4;
A capacidade de terminac
ao para um mnimo de duas fibras, por acopla-
mento 568SC;
Possibilidade de armazenar um mnimo de 1 metro de cabo de duas fibras.
34.7 C
odigo de Cores para Sistemas de Cabe
cao
UTP
A EIA/TIA 568A define um sistema de codificacao com quatro cores b asicas,
em combinac
ao com o branco, para os condutores UTP de 100 Ohms, assim
como a ordem dos pares no conector RJ-45, conforme ilustrado na figura 34.10.
Figura 34.10: C
odigo de cores EIA/TIA 568A
Um outro padr ao de cores da cabeac

ao UTP, derivado da EIA/TIA 568A, o
padr
ao EIA/TIA 568B, n ao muito utilizado nos dias atuais, define a seq
uencia
de cores da figura 34.11.
Figura 34.11: C
odigo de cores EIA/TIA 568B
336
Captulo 35
Redes sem fio
Os principais elementos de uma rede sem fio s

ao:
Hospedeiros sem fio: S

ao os sistemas finais que executam as aplicac
oes,
por exemplo, um celulare, um PDA, um notebook etc;
Enlace sem fio: Os hospedeiros se conectam ao restante da rede por meio
de um enlace de comunicac ao sem fio. Tecnologias de enlace sem fio tem
diferentes taxas de transmissao e podem transmitir ` a dist
ancias diferentes.
Outra caracterstica relevante dos enlaces sem fio e a grande taxa de erros
de bits, que obriga os protocolos de enlace sem fio a empregarem mecan-
ismos mais sofisticados de deteccao de erros e retransmis ao;
Estacao-base: E a responsavel pelo envio e recebimento dos dados de e
para os hospedeiros sem fio ` a ela associados. Exemplos de estacao-base
s
ao torres celulares, pontos de acesso de uma rede 802.11 etc. Em geral,
as estac
oes-base estao ligadas `
a uma infra-estrutura maior de rede (uma
LAN cabeada, a internet etc.) que e respons avel pelo fornecimentos dos
servicos mais comuns como atribuic ao de endereco e roteamento. Quando
isso acontece e dito que a rede est
a operando no modo de infra-estrutura.
Algumas tecnologias de rede sem fio permitem que os dispositivos m oveis se

comuniquem diretamente sem a necesidade de uma estac ao base. Esse modo de
operacao e chamado ad hoc. Nesse caso os prorprios hospedeiros sem fio devem
ser capazes de fornecer servicos b
asicos de atribuic
ao de endereco, roteamento,
resoluc
ao de nomes etc.
35.1 O padr
ao IEEE 802.11
O IEEE 802.11, tambem conhecido como Wi-Fi, e a tecnologia mais utilizada
atualmente para implementacao de redes locais sem fio. Entre os padr oes 802.11
que mais se destacam est ao o 802.11a, 802.11b e 802.11g. Esses tres padr oes
compartilham caractersticas como formato do quadro, protocolo de acesso ao
meio, capacidade de reduzir taxa de transmissao para alcancar dist
ancias maiores
e a possibilidade de operar tanto em modo de infra-estrutura como em modo ad
hoc. As diferencas entre os padroes a, b e g se concentra na camada fsica de
acordo com a tabela 35.1.
337
Padr
ao Faixa de Frequencia Taxa de Dados
802.11b 2.4-2.485 GHz ate 11 Mbps
802.11a 5.1-5.8 GHz ate 54 Mbps
802.11g 2.4-2.485 GHz ate 54 Mbps
Tabela 35.1: Resumo dos Padr

oes 802.11
O padrao 802.11b e atualmente o mais utilizado devido ` a sua boa relac

ao
custo-benefcio. Em seguida est a o padrao 802.11g, que vem se estabelecendo
por permitir operac
ao `
a taxas mais elevadas e dist
ancias equivalentes ao padrao
802.11b. Embora alcance taxas t ao elevadas quanto o o padr ao 802.11g, o
padr
ao 802.11a alcanca dist
ancias menores. Em contrapartida, o padr ao 802.11a
e menos suscetvel `
as intereferencias introduzidas por telefones celulares, mi-
croondas e bluetooth, que operam na faixa de 2.4 GHz assim como os padr oes
802.11b e 802.11g.
35.1.1 CSMA/CA
O protocolo de acesso ao meio utilizado pelas redes do padr ao 802.11 e o
CSMA/CA (Carrier Sense for Multiple Access with Colision Avoidance). Esse
protocolo se baseia no fato de que e extremamente difcil detectar colis
oes em
enlaces sem fio, e por isso, tenta evit
a-las sempre que possvel. O CSMA/CA
funciona da seguinte maneira:
1. Se a estac
ao perceber que o canal est
a ocioso, ela transmitir
a o quadro
ap
os um curto espaco de tempo conhecido como DIFS (Distributed Inter-
Frame Space);
2. Caso contr
ario, a estac
ao escolher
a um valor aleat
orio de backoff e iniciar
a
a contagem regressiva a partir desse valor assim que detectar o canal
ocioso;
3. Quando o contador chegar a zero, a estac ao transmitir

a o quadro inteiro
e ficar
a esperando por uma confirmacao. Caso o receptor receba o quadro
corretamente, ele esperara um tempo curto chamado SIFS (Short Inter-
Frame Space) e ent ao enviar
a a confirmac
ao;
4. Se a estac
ao receber a confirmac ao e tiver outro quadro para transmitir,
ent
ao ela ela ir
a iniciar o protocolo a partir da fase 2. Caso n
ao receba nen-
huma confirmac ao, voltara para fase 2 porem ir
a escolher por um backoff
dentro de um intervalo de tempo maior.
A caracterstica mais importante do protocolo CSMA/CA e que mesmo que

uma estac ao detecte que o canal est
a ocioso, ela adia a transmiss ao por um
curto perodo de tempo aleat orio. Se ao detectar o canal ocupado cada uma
das estac
oes escolher um valor de backoff diferente das demais, ent
ao uma delas
ir
a comecar a trasmitir primeiro. As demais, ao escutar o canal ocupado, inter-
romperam seus contadores e aguardarm pelo termino da transmiss ao.
338
O padr ao 802.11 conta ainda com um mecanismo de reserva de canal que

ajuda a evitar colis
oes. O mecanismo e baseado no envio de quadros especiais
chamados RTS (Request to Send ) e CTS (Clear to Send ). Quando um trans-
missor deseja enviar um quadro de dados DATA, ele pode solicitar a reserva do
canal enviando um quadro RTS para a estac ao-base. O RTS indica o tempo
total necess
ario para a transmissao de DATA. Ao receber o RTS, a estac ao-
base envia um quadro CTS em broadcast para toda a rede. O quadro CTS
tem como finalidade dar permiss ao para o envio do quadro DATA e instruir os
demais transmissores a nao enviarem nada durante o tempo reservado.
35.1.2 Formato do Quadro 802.11

A caracterstica mais marcante de um quadro 802.11 e que ele tem 4 campos
de endereco, cada um podendo conter um endereco MAC de 6 bytes. Em redes
802.11 operando no modo infra-estrutura 3 desses campos s ao necess
arios (o
outro s
o e utilizado no modo ad hoc). O campo endereco 1 contem o MAC
do dispositivo sem fio destinatario, enquanto o endereco 2 contem o MAC do
dispositivo sem fio remetente. O campo endereco 3 contem o endereco MAC do
dispositivo Ethernet com o qual a estac ao base est
a conectada, por exemplo,
um roteador. A estac ao-base e, portanto, o dispositivo de camada de enlace
responsavel por intermediar a comunicacao dos dispositivos sem fio com a rede
cabeada.
Alem dos campos de endereco, tambem merecem destaque os campo CRC

(Cyclic Redundancy Check ), que permite detecc
ao de erros de bits, e o campo
de n
umero de sequencia, que permite que o mecanismo de confirmac
ao funcione.
O formato completo do quadro 802.11 pode ser visto na figura 35.1.2.
Figura 35.1: Formato do quadro 802.11
339
Captulo 36
Elementos de Interconex
ao
de Redes de Computadores
36.1 Repetidores
S
ao elementos que interligam dois segmentos de um mesmo domnio de colis ao.
Os sinais eletricos que trafega em ambos sentidos s
ao amplificados analogica-
mente permitindo comunicacoes em maiores distancias. Portanto, estes elemen-
tos operam na CAMADA FISICA do modelo OSI.
Estes equipamentos deixaram de ser largamente utilizados devido ao fato dos

hubs ativos, switches, gateways e roteadores terem passado a exercer tambem a
func
ao de amplificac
ao.
36.2 Hubs
Este e um termo generico para CONCENTRADORES. Eles s ao elementos de
CAMADA FISICA do modelo OSI. Portanto, todos os n os conectados a um hub,
ou a um conjunto de hubs interconectados, fazem parte de um mesmo domnio
de colis
ao (topologia barramento). Desta forma, cada n o deve ser capaz de de-
tectar colis
oes e decidir o momento de realizar transmiss
oes e/ou retransmiss
oes.
Duas caractersticas importantes s

ao: como um hub define um unico domnio
de colis
ao comum a todas as portas, a princpio ele n
ao permite a interconexao
de segmentos que utilizam tecnologias distintas (taxas, protocolo de camada 2,

etc.); um hub nao implementa nenhum tipo de controle de acesso, e sim encam-
inha os bits de uma porta para as demais.
Estes concentradores podem ser classificados em quatro grupos:
Hubs Passivos: hubs que nao implementam a func

ao de repetic
ao, ou seja,
n
ao funcionam como repetidores. Estes equipamentos n ao necessitam de
nenhuma alimentac
ao eletrica. Eles n
ao possuem nenhum m odulo micro-
processado. Um exemplo s ao os patch painels;
340
Hubs Ativos: hubs que implementam a func ao de repetic

ao. Assim como
os passivos, eles n
ao possuem nenhum m
odulo microprocessado. A grande
maioria dos hubs utilizados ultimamente pertence a este grupo;
Hubs Inteligentes: hubs que possuem m odulos microprocessados que re-

alizam monitoramento e diagn ostico. As funcionalidades dependem do
projeto do fabricante, por exemplo, eles podem: detectar e se preciso
desconectar da rede estacoes com problemas, evitando que uma estac ao
faladora prejudique o trafego ou mesmo derrube a rede inteira; detectar
e impedir tentativas de invas ao ou acesso n ao autorizado à rede; moni-
torar/informar o nvel de utilizac
ao de cada porta; e possibilitar operac
ao
de taxas diferentes entre as portas (ex. 10Mbps e 100Mbps). Geralmente
estes hubs tambem sao classificados como ativos;
Hubs Empilh aveis: hubs que possuem portas denominadas Up-Links. Es-
tas portas permitem o empilhamento de hubs atraves de CABOS DIRE-
TOS. Na pr atica, qualquer hub pode ser empilhado a outro, a diferenca
e que no caso de hubs n ao-empilh
aveis (sem porta do tipo Up-Link) deve
ser utilizado um CABO CROSS-OVER.
36.3 Switches
Estes s
ao elementos de CAMADA DE ENLACE do modelo OSI tambem denom-
inados de COMUTADORES. Geralmente eles funcionam tambem como repeti-
dores. Diferentemente dos hubs, os switches dividem a rede em domnios de
colis
ao (um domnio por porta). Desta forma, o switch ao comutar um quadro
de um domnio para outro deve ser capaz de implementar algum tipo de cont-
role de acesso para ser possvel detectar colis
oes e decidir o momento de realizar
transmissoes e/ou retransmiss oes.
Uma outra caracterstica importante presente no switches e a possibilidade

deles interconectarem segmentos com tecnologias distintas. Ou seja, este tipo
de comutador pode ser multiprotoloco (exige convers ao de um tipo de quadro
em outro - ex. Ethernet em FDDI). Alguns switches tambem s ao capazes de
administrar m ultiplas taxas de transmissao. Quando ele e capaz de detectar
automaticamente a taxa de transmiss ao utilizada em uma determinada porta e
se auto configurar para esta taxa, diz-se que este switch e AUTO-SENSING.
As comutacoes s
ao realizadas por meio de consultas a tabelas din amicas que
armazenam enderecos fsicos, e seus respectivos, n umero da interface (porta)

e horario da u
ltima comutacao. Os switches s ao equipamentos plug-and-play
devido ao fato de sua tabela de comutac ao ser preenchida de forma automatica
ao longo do funcionamento da rede. Este preenchimento acontece da seguinte
forma. Inicialmente a tabela se encontra vazia. Quando um quadro chega para
ser comutado, e o switch ao perceber que n ao ha nenhuma entrada na tabela
para o endereco fsico de destino, ele replica este quadro em todas as outras
interfaces (portas). Todas as vezes que um n o envia um quadro a qualquer
outro no, seu endereco fsico e registrado na tabela juntamente com o n umero
da interface onde ele esta conectado ao switch.
341
Todo switch realiza no mnimo duas operac

oes b
asicas utilizando sua tabela
de comutacao. A FILTRAGEM que e a capacidade de determinar se um quadro
deve ser repassado para alguma interface ou se ele deve ser descartado. E o
REPASSE que e a capacidade de determinar para qual interface o quadro deve
ser dirigido.
Estes comutadores podem operar em duas formas distintas. S

ao elas:
Store-and-forword - a seq uencia de comutacao e a seguinte: o quadro e

recebido na porta de entrada; este quadro e armazenado em um buffer
interno; e realizada a filtragem/repasse; o quadro e copiado no buffer da
porta de sada. Este tipo de comutac ao e geralmente implementado por
elementos de hardware e software (principalmente) em conjunto;
Cut-Through (Acelerada ou De Corte) - a seq uencia de comutac
ao e a
seguinte: ` a medida que o quadro vai sendo recebido de forma seq uencial
na porta de entrada, assim que os primeiros bits que definem o endereco
fsico de sada acabam de chegar, a filtragem/repasse e realizada e ent ao
este quadro j a vai sendo copiado no buffer da porta de sada. E impor-
tante notar que o quadro j a comeca a ser copiado no buffer de sada antes
mesmo dele ter sido totalmente recebido na porta de entrada. Nos casos
onde os bufferes de sada estao geralmente vazios (sem fila de transmiss
ao),
esta forma de operac ao traz benefcios consider
aveis no desempenho da co-
mutac ao. Este tipo de comutacao e geralmente implementado por somente
elementos de hardware.
36.4 Bridges
As bridges (PONTES) s ao muito semelhantes aos switches. Na verdade, muitas
pessoas usam ambos os termos de forma intercambi avel. A principal diferenca
e que os switches sao usados com maior frequencia para conectarem computa-
dores individuais, enquanto as bridges s
ao mais usadas para conectarem redes.
Contudo, todas as caractersticas dos switches apresentadas na sec
ao anterior
tambem estao presentes nas bridges.
36.5 Roteadores
S
ao elementos da CAMADA DE REDE do modelo OSI. Eles tambem geral-
mente funcionam como repetidores, ou seja, regeneram os sinais recebidos antes

de realizarem a comutacao. Assim como os switches e bridges, os roteadores
tambem sao COMUTADORES, porem com uma complexidade muito maior. O
que reflete no tempo de comutac
ao e tambem nos recursos disponveis.
Seu papel fundamental e escolher, por meio de algum algoritmo de rotea-

mento, uma dentre as eventuais muitas rotas entre um n o de origem e um n o
de destino. Vale ressaltar que no caso dos switches e bridges a comutac ao e
mais f
acil, visto que a rota e u
nica, o que nem sempre acontece no caso das
roteadores. Uma caracterstica muito importante dos roteadores e a capacidade
342
de interconectar redes que utilizam tecnologias diferentes (arquiteturas difer-

entes). Isto s
o e possvel quando o roteador e capaz de entender e converter
um datagrama de uma tecnologia em outro datagrama de outra tecnologia (ex.
IP e ATM).
Outras caractersticas tambem importantes s ao: a comutac ao n

ao se limita a
uma SPANNING-TREE (grafo sem loopings - caminhos u nicos entre quaisquer
dois nos) como os comutadores de camada de enlace; possibilita protec ao contra
broadcast em excesso; possibilita protec
ao de firewall; e nao e um equipamento
plug-and-play tendo em vista que os enderecos de rede s ao l
ogicos (nao-fixos) e
n
ao fsicos (fixos) e devem ser programados de alguma forma; e a comutac ao
e necessariamente realizada no modo store-and-forword (nunca no modo cut-
through).
36.6 Gateways
Estes elementos podem ser divididos em duas grandes classes: Gateways Con-
versores de Meio e Gateways Tradutores de Protocolos.
Os Conversores de Meio sao exatamente os roteadores multiprotocolo. Ou

seja, s
ao elementos de CAMADA DE REDE do modelo OSI.
Ja os Tradutores de Protocolos podem ser elementos de CAMADA DE

TRANSPORTE ou CAMADA DE APLICAC Fundamentalmente os primeiros
AO.
realizam convers oes entre segmentos (unidade de camada de transporte) de pro-
tocolos distintos e os u
ltimos realizam convers oes entre mensagens (unidade de
camada de aplicacao) de protocolos distintos. Vale ressaltar que durante as con-
vers
oes o que se busca e manter a sem antica dos dados. Por isso, nem sempre e
possvel converter um protocolo em outro.
343
Captulo 37
Redes Multimdia
37.1 Qualidade de Servi

co
Um fluxo e uma sequencia de pacotes de uma origem ate um destino. Em uma
rede orientada a conex oes os pacotes de um determinado fluxo seguem uma
mesma rota, enquanto em uma rede n ao orientada a conexoes, eles podem seguir
rotas diferentes. Nesse contexto, Qualidade de Servico (QoS) pode ser definido
em termos do conjunto de requisitos de um determinado fluxo de pacotes. Os
requisitos mais comuns sao os seguintes:
Confiabilidade: Garantia da entrega dos pacotes e da integridade dos da-

dos transmitidos.
Retardo: Atraso total na transmiss
ao de um pacote da origem ate o des-
tino.
Flutuac
ao (Jitter ): E a variacao do atraso entre os pacotes. Em out-
ras palavras, e a variacao do intervalo de tempo entre os recebimento de
pacotes subsequentes de um determinado fluxo.
Largura de Banda: Taxa com a qual os dados s

ao transmitidos.
A rigidez dos requisitos das aplicac oes mais comuns e mostrada na tabela a
37.1:
No que diz respeito à confiabilidade, por exemplo, pode-se dizer que o servico
de correio eletr
onico e mais sensvel do que uma aplicac
ao de vdeo sob demanda,
j
a que o corrompimento dos dados pode invalidar por completo uma mensagem.
Em uma aplicac ao de vdeo sob demanda pode conviver com alguns pacotes
com erro sob pena da perda parcial da qualidade do vdeo. E por esse motivo
que em redes TCP/IP aplicac oes de multimdea, geralmente, utilizam servicos
da camada de transporte baseados em UDP e n ao em TCP, evitando os atrasos
gerados pelo estabelecimento de conex ao, confirmac
oes e retransmissoes.
No entanto, para alcancar qualidade de servico de forma eficiente e segura

e necess
ario combinar v
arias tecnicas que podem ir alem da escolha de um
protocolo. Exemplos de tecnicas para alcancar QoS s
ao:
344
Aplicac
ao Confiabilidade Retardo Jitter Largura de Banda
Correio Eletr
onico Alta Baixa Baixa Baixa
Transferencia de Arquivos Alta Baixa Baixa Media
Acesso `
a Web Alta Media Baixa Media
Login Remoto Alta Media Media Baixa

Audio por demanda Baixa Baixa Alta Media
Vdeo por demanda Baixa Baixa Alta Alta
Telefonia Baixa Alta Alta Baixa
Videoconferencia Baixa Alta Alta Alta
Tabela 37.1: Rigidez dos Requisitos das Alicac

oes de Rede
Superdimensionamento: Consiste em fornecer tanta capacidade de buffers

e largura de banda de forma que dificilmente os pacotes serao descartados
ou sofrer
ao atrasos. Logicamente essa e a soluc
ao tem um custo altamente
elevado;
Armazenamento em Buffers: Consiste em armazenar os fluxos em buffers
no lado do receptor e entreg a-los apenas no momento oportuno suavizando
o jitter. Essa tecnica n
ao inclui alteracoes na largura de banda, porem
aumenta o atraso e exige buffers maiores do lado do receptor. Muitos
reprodutores de audio e vdeo se utilizam dessa tecnica;
Moldagem de Tr afego: Muitas vezes uma m aquina pode transmitir pacotes

com espacamento n ao uniforme, o que pode gerar congestionamento na
rede. A moldagem de tr afego est
a relacionada `
a regulagem da taxa media
de transmissao dos dados. Para realizar tal tarefa sao utilizadas tecnicas
como o algoritmo do balde furado (leaky bucket) ou o algoritmo do balde
de smbolos (token bucket);
Reserva de Recursos: Se for possvel fazer com que todos os pacotes de um
fluxo sigam a mesma rota, torna-se possvel reservar recursos para garan-
tir que a capacidade necessaria estar
a disponvel. Portanto, As aplicac
oes
s
ao responsaveis por definir os seus requisitos quanto a utilizac
ao dos re-
cursos de CPU, espaco em buffers e largura de banda. O conjunto desses
parametros e chamado especificacao de fluxo, e e com base nele que os
roteadores ao longo da rota decidem se v ao ou nao aceitar o fluxo. Ao

longo do caminho da origem ao destino, os requisitos da especificac ao
de fluxo podem ser alterados para baixo (ex: diminuic ao da largura de
banda, diminuicao do pacote de tamanho m aximo etc.). Ao fim do cam-
inho origem destino os parametros est ao ajustados conforme a capacidade
dos roteadores intermedi arios, e a transmissao pode ser iniciada ou n ao.
Esse processo e conhecido como controle de admiss ao;
Enfileiramento Prioritario: Utilizac

ao de multiplas filas, cada uma com
uma prioridade asociada. Cada pacote que chega e direcionado ` a uma das
filas de acordo com sua classe. Os pacotes a serem transmitidos sao sempre
aqueles da fila de maior prioridade que ainda n ao esta vazia. Algumas
345
implementacoes permitem a interrupc

ao de uma transmiss
ao de um pacote
de prioridade mais baixa para transmiss ao de um pacote de prioridade
masi alta (preempcao).
Varredura Cclica e WQF: Na varredura cclica os pacotes s ao classifica-
dos e colocados em filas de sada da mesma forma que no enfileiramento
prioritario. No entanto, nessa disciplina o escalonador alterna o direito de
transmitir de forma cclica a cada perodo (Ex: fila 1, fila 2, fila 3, fila 1,
fila 2, fila 3 etc.). No WQF (Weighted Fair Queuing ou Enfileiramento
Justo Ponderado) o direito de transmitir e ponderado entre as filas. (Ex:
fila 1, fila 1, fila 1, fila 2, fila 3, fila 3, fila 1, fila 1, fila 1, fila 2, fila 3, fila
3 etc.).
37.2 Servicos Integrados - IntServ

A arquitetura de servicos integrados tem duas caractersticas fundamentais que
s
ao a reserva de recursos e o estabelecimento de chamada. O Intserv e fornecer
qualidade de sevico a fluxos individuais garantindo que, antes do estabeleci-
mento de uma sess ao, todos os roteadores entre a origem e o destino possuem
recursos suficientes para garantir o atendimento das exigencias de Qos. As eta-
pas envolvidas no processo de aceitacao da chamada sao as seguintes:
Caracterizac
ao do Trafego e Especificac
ao de Qos desejada: Para que um
roteador defina se pode ou n ao atender as exigencias de uma sess ao ele
precisa conhecer a exigencias de QoS (Rspec) e as caractersticas de tr
afego
(Tspec). Tspec e Rspec s ao chamados especificacoes de fluxo flowspecs;
Sinalizac
ao para o estabelecimento da chamada: A Tspec e o Rspec de-
vem ser transportados para todos os roteadores nos quais ser
ao reservados
recusos;
Aceitac
ao da chamada: Assim que recebe Tspec e Rspec o roteador pode
determinar se pode ou n
ao aceitar a chamada.
Na Internet, o protocolo RSVP (Resource Reservation Protocol ) e o proto-
colo de sinalizac
ao preferido Ele foi especialmente desenvolvido para servicos
integrados de Internet e permite que as pr oprias aplicac
oes requeiram da rede
reservas de recursos necess arios para seus diversos servicos. O RSVP e ex-
ecutado nos hosts, para definir as especificac oes de fluxo, e nos roteadores,
para propagacao das especificac
oes pela rota e para manutenc ao do estado da
conexao.
Outra caracterstica importante na arquitetura IntServ s ao as classes de

servico oferecidos. As classes s
ao os modelos de qualidade de servico ofereci-
dos. As duas grandes classes de servico do intServ s
ao: (i)Servico de Qualidade
Garantida e (ii) Servico de Rede de Carga Controlada.
A primeira grande desvantagem da arquitetura IntServ est ao relacionadas

com a escalabilidade, uma vez que os roteadores precisam manter o estado de
cada um dos fluxos transmitidos, o que pode ocasionar sobrecarga em roteadores
de backbone. A segunda desvantagem do IntServ e que ela atende apenas um
n
umero pequeno de classes de servico.
346
37.3 Servicos Diferenciados - DiffServ

A arquitetura de servicos diferenciados (Diffserv) tem por objetivo prover difer-
enciac
ao de servicos mais escal
avel e flexvel. Para isso o DiffServ prop
oe que
as operac
oes de controle mais complexas devem ser feitas pela borda da rede,
aliviando a sobrecarga no n ucleo da rede. Dessa forma, a arquitetura Intserv
consiste de dois elementos funcionais que s ao:
Func
oes de Borda: Entende-se por borda como o primeiro dispositivo
habilitado a DiffServ (host ou roteador) no caminho entre a origem e o
destino. A func
ao dos dispositivos de borda s ao a classific
ao dos pacotes
e o condicionamento do tr afego. A classificac
ao do trafego consiste na
marcacao do campo DS (Differentiated Service), que na verdade e o campo
ToS (Type of Service) do pacote IP. O condicionamento do tr afego est
a
relacionado com a limitac
ao de par
ametros pre-acordados como taxa media
de envio, taxa de pico etc.
Funcao Central: Quando um pacote marcado com DS chega a um roteador
habilitado a DiffServ ele e repassado de acordo com o seu comportamento
de salto (per-hop behavior - PHB) associado a sua classe. O PHB influencia
na maneira como os buffers e a largura de banda s ao compartilhados entre
as classes de tr
afego no roteador. Os dois tipos de PHB definidos ate agora
s
ao o PHB de repasse acelerado (expedited forwarding - EF), que garante
a taxa de partida de uma determinada classe ser a maior ou igual do que
uma taxa configurada, e o PHB de envio assegurado (assured forwarding -
AF), que permite criacao de regras de descarte preferencial entre as classes.
Um aspecto de fundamental import ancia na arquitetura DiffServ e que o
comportamento de salto dos pacotes depende u nica e exclusivamente de
sua classe de trafego.
347
Captulo 38
Redes X.25 e Frame Relay
38.1 X.25
O conjunto de protocolos X.25 foi projetado no final da decada de 70. Nessa
epoca, os PCs e as estacoes de trabalho n ao estavam amplamente disseminados
e nao dispunham de muito suporte para rede. Basicamente, eram usados os
chamados terminais burrospara acessarem os mainframes atraves das redes
de computadores. Dessa forma, para dar o suporte necess ario aos terminais
burrosos projetistas da X.25 decidiram injetar inteligencia na rede. Como
sabemos hoje, essa filosofia e oposta `
a filosofia da Internet, que coloca muito da
complexidade nos sistemas finais e espera o mnimo dos servicos de camada de
rede.
Outra parte importante do contexto tecnol ogico do final dos anos 70 e do
comeco dos anos 80 se refere aos enlaces fsicos. Naquela epoca, quase todos
os enlaces terrestres eram de cobre, apresentavam rudos e estavam propensos
a erros. Os enlaces de fibra optica ainda n ao tinham sado dos laborat orios de
pesquisa. As taxas de erros de bits sobre enlaces de longa dist ancia eram muitas
ordens de grandeza maiores do que s ao agora sobre o enlaces opticos. Devido às
altas taxas de erros, tinha sentido projetar o protocolo X.25 com recuperac ao de
erros em cada enlace. Em particular, sempre que um protocolo X.25 envia um
pacote, ele conserva uma c opia do pacote ate que o comutador seguinte (na rota
do pacote) devolva um reconhecimento, indicando que o pacote foi recebido livre
de erros. A recuperac ao de erros por enlace reduz significativamente a taxa de
transmissao, o que era consistente com o contexto tecnol ogico da epoca altas
taxas de erros de enlace e terminais n ao inteligentes. Alem disso, o projeto da
X.25 tambem pede controle de fluxo por enlace.
38.2 Frame Relay

Projetada no final da decada de 80 e amplamente disseminada na decada de 90, a
Frame Relay e, em v arios aspectos, uma X.25 de segunda gerac
ao. Como a X.25,
ela usa circuitos virtuais, opera na camada 2 do modelo OSI e usa multiplexacao
estatstica e compartilhamento de porta. Contudo, como se baseia em enlaces
de fibras opticas, ela naturalmente foi projetada para taxas de erros muito mais
baixas. A essencia da Frame Relay e um servico de comutac ao de pacotes de
348
circuitos virtuais sem recuperac ao de erros e sem controle de fluxo. Quando

um comutador Frame Relay detecta um erro em um pacote, seu u nico curso
de ac
ao possvel e descartar os dados. Isso resulta em uma rede com carga de
processamento mais baixas e taxas de transmiss ao mais altas que a X.25, mas
exige sistemas finais inteligentes para garantir a integridade dos dados.
Embora o protocolo Frame Relay tenha sido desenvolvido para ser o mais
simples possvel, e a sua premissa basica determinar que os eventuais problemas
de erros da rede deveriam ser resolvidos pelos protocolos dos equipamentos de
usuario, surgiram ao longo do tempo necessidades que levaram os org
ao de
padronizacao a definir mecanismos de sinalizacao para tres tipos de situac
oes:
Aviso de congestionamento
Aviso Explcito de Congestionamento

Aviso Implcito de Congestionamento
Elegibilidade para Descarte
Estado das conex
oes
Sinalizac
ao SVC
Entretanto, a implementacao desses mecanismos e opcional e, embora a rede

seja mais eficiente com a sua adoc
ao, os equipamentos que n ao os implementam
devem atender pelo menos as recomendac oes b
asicas do Frame Relay.
Atualmente, na maioria dos casos, as redes Frame Relay s ao de propriedade
de um provedor de servicos de rede p ublica (por exemplo AT&T, Sprint e etc)
e seu uso e contratado em base multianual por clientes empresariais. Hoje, a
Frame Relay e usada de maneira extensiva para permitir que LANs localizadas
em diferentes ambientes enviem dados ao mesmo tempo a velocidades razoavel-
mente altas.
As redes Frame Relay podem usar circuitos virtuais comutados (switched
virtual circuits SVCs) ou circuitos virtuais permanentes (permanent virtual
circuits PVCs).
38.2.1 Estrutura do Frame

O protocolo da Frame Relay utiliza um frame com estrutura comum e bastante
simplificada, conforme demonstram a figura e a descric
ao a seguir:
Figura 38.1: Estrutura do Frame
Figura 38.2: Estrutura do Cabecalho
349
Flags - indicam o incio e o fim de cada frame.

Cabecalho - carrega as informac composto
oes de controle do protocolo. E
por 2 bytes com as seguintes informacoes:
DLCI (Data Link Connection Identifier), com 10 bits, representa o
n
umero (endereco) designado para o destinat ario de um PVC dentro
de um canal de usu ario, e tem significado local apenas para a porta
de origem (vide figura 38.2);
C/R (Command / Response), com 1 bit, e usado pela aplicac
ao
usu
aria;
FECN (Foward Explicit Congestion Notification), com 1 bit, e usado
pela rede para informar um equipamento receptor de informac
oes que
procedimentos de prevencao de congestionamento devem ser inicia-
dos;
BECN (Backward Explicit Congestion Notification), com 1 bit, e
usado pela rede para informar um equipamento transmissor de in-
formac
oes que procedimentos de prevenc
ao de congestionamento de-
vem ser iniciados;
DE (Discard Eligibility Indicator), com 1 bit, indica se o frame pode
ser preferencialmente descartado em caso de congestionamento na
rede;
EA (Extension Bit), com 2 bits, e usado para indicar que o cabecalho
tem mais de 2 bytes, em caso especiais;
Informac
ao de usu
ario - contem as informac
oes da aplicac
ao usu
aria a
serem transportadas atraves da rede Frame Relay.
FCS - o FCS (Frame Check Sequence) representa o CRC padr ao de 16 bits
usado pelo protocolo Frame Relay para detectar erros existentes entre o
Flag de incio do frame e o pr
oprio FCS, e pode ser usado apenas para
frames com ate 4096 bytes.
38.2.2 Envio de um datagrama IP de Ethernet para Frame

Relay e Ethernet
Considere a transmiss ao de um datagrama IP entre dois sistemas finais que est
ao
em duas redes Ethernet interconectadas por uma rede Frame Relay. Quando um
quadro Ethernet chega ao roteador fonte, a placa Ethernet do roteador retira os
campos Ethernet e passa o datagrama IP ` a camada de rede. A camada de rede

passa o datagrama IP ` a placa de interface Frame Relay. Essa placa encapsula
o datagrama IP em um quadro Frame Relay. Ela tambem calcula o CRC (2
bytes) e insere o valor resultante no campo CRC. O campo de camada de enlace
(2 bytes) contem um campo de n umero de circuito virtual de 10 bits. A placa
de interface obtem o numero do CV de uma tabela que associa n umeros de rede
IP a numeros de CV. Ela ent ao transmite o pacote.
A placa de interface transmite o pacote Frame Relay a um comutador Frame
Relay pr oximo, de propriedade de um provedor de servicos Frame Realy. O
comutador examina o campo de CRC. Se o quadro tiver um erro, o comutador
o descartara. Se nao houver erro no quadro, o comutador usar a o numero de
350
CV do quadro para rote a-lo ate o pr

oximo comutador (ou ate o roteador de
destino). O roteador de destino remove os campos frame relay e, ent
ao, passa o
datagrama pela Ethernet para o hospedeiro de destino. Se os segmentos TCP
forem perdidos ou chegarem fora de ordem, o TCP dos hospedeiros comunicantes
corrigir
a o problema.
38.3 Interligac
ao de Redes LAN
A interligac
ao das redes LAN de v arios escritorios compondo uma rede WAN,
e uma aplicacao tpica para o uso da tecnologia Frame Relay. O tr afego usual
das redes de dados e normalmente de 2 tipos: interativo (comando - resposta),
ou seja, solicitac
ao de usu arios e aplicac
oes clientes e respostas de aplicac
oes
servidoras, e por rajadas (bursty), quando grandes quantidades de dados s ao
transferidas de forma n ao contnua.
O Frame Relay, atraves de roteadores ou equipamentos de acesso (FRAD)
instalados nos escrit orios, permite utilizar uma porta u nica em cada escritorio
para compor redes do tipo malha (meshed) onde a comunicac ao de um escrit
orio
com todos os outros e possvel sem a complexidade do uso de m ultiplas portas
e multiplos circuitos dedicados.
Figura 38.3: Interligac

ao de lans com Frame Relay
Alem disso, o uso dos circuitos virtuais do Frame Relay para compor a rede
permite tempos de provisionamento muito menores e reconfigurac ao de rede ou
aumento de banda com maior facilidade.
38.3.1 Voz sobre Frame Relay (VoFR)

A tecnologia Frame Relay tambem possui facilidades para o transporte de Voz,
fax e sinais de modens anal ogicos atendendo os requisitos de atraso (delay)
especficos para esse tipo de aplicac

ao.
Para a maioria dos administradores de rede de Voz e dados, a possibilidade
de transportar a Voz proveniente de PABXs, sinais de fax e de modens, e
dados atraves da mesma porta Frame Relay e usando procedimentos comuns
de gerenciamento e manutenc ao atende os requisitos de reduc
ao de custos e de
complexidade das grandes redes corporativas.
Deve-se entretanto levar em considerac ao a qualidade do servico prestado
pela rede multisservicos de terceiros para que o resultado nas aplicac oes de
Voz, fax e modem possam ainda atender os requisitos aplic aveis aos servicos
convencionais.
351
Figura 38.4: Voz sobre Frame Relay
38.3.2 Intera
c
ao entre Frame Relay e ATM
Para buscar aumentar a interoperabilidade do Frame Relay com outros pro-
tocolos de dados, o FR F orum e o ATM F orum, os org
aos responsaveis pelo
desenvolvimento de Acordos de Implementac ao (IAs), desenvolveram padr oes
para interligar equipamentos dessas tecnologias atraves de PVCs.
Foram padronizadas duas formas de interoperabilidade. A primeira, chamada
de Frame Relay/ATM Network Interworking for PVCs, padroniza uma fun-
cionalidade respons avel pelo encapsulamento dos PVCs para que os mesmos
possam ser transportados indistintamente nas redes da 2 tecnologias. Seu uso
tpico ocorre quando a rede Frame Relay tem com n ucleo uma rede ATM, para
otimizar ainda mais o uso de banda e a seguranca. A figura a seguir apresenta
esta soluc
ao.
A segunda forma de interoperabilidade, chamada de Frame Relay/ATM Ser-
vice Interworking for PVCs, padroniza uma funcionalidade respons avel pela
convers ao dos protocolos (FR ATM), que pode ser incorporada tantos aos
equipamentos de acesso como aos equipamentos da rede. Seu uso tpico ocorre
quando o usu ario possui redes Frame Relay em alguns escrit
orios que devem se
interligar com a rede ATM da matriz. A figura a seguir apresenta esta solucao.
38.3.3 CIR (Taxa de Informac

ao Comprometida)
A Frame Relay faz uso de um mecanismo inovador chamado de taxa de in-
formac
ao comprometida (committed information rate - CIR), de forma que cada
CV possui um CIR. Em termos gerais, a CIR representa um compromisso que
a rede Frame Relay assume de dedicar ao CV uma taxa de transmiss ao deter-
minada pela CIR. Pode-se dizer que, em muitos aspectos, o servico CIR e um
predecessor do servico diferenciado da Internet.

Nas redes Frame Relay, os pacotes podem pertencer a um de dois nveis de
prioridade: alta ou baixa. Atribui-se prioridade aos pacotes marcado um bit
especial no cabecalho do pacote o denominado bit de descarte preferencial
(discard eligibility- DE) -, com 0 para alta prioridade e 1 para baixa prioridade.
Se um quadro for de alta prioridade, a rede dever a entregar o pacote no destino
sob todas e quaisquer condicoes de rede, incluindo perodos de congestionamento
e falha de enlaces de backbone. Contudo, para pacotes de baixa prioridade,
permite-se que a rede descarte o quadro quando ela estiver congestionada. Na
verdade, sob condic oes extremas, a rede pode ate descartar pacotes de alta
prioridade.
352
A CIR, nesse contexto, est a envolvida no processo de marcac ao dos pacotes

com valores 1 ou 0. Entretanto alguns conceitos devem ser discutidos para se
entender exatamente como a CIR funciona. A taxa de acesso e a taxa de acesso
ao enlace, isto e, a taxa do enlace do roteador fonte ate o comutador de borda
Frame Relay. Essa taxa e freq uentemente 64Kbps, mas m ultiplos inteiros de
64 Kbps ate 1544 Mbps tambem s ao comuns. Chamemos essa taxa de R. O
comutador de borda e respons avel pela marcacao dos pacotes que chegam do
roteador fonte. Para fazer a marcac ao, o roteador de borda examina os hor arios
de chegada dos pacotes vindos do roteador fonte em intervalos fixos de tempo,
chamados de intervalos de medic ao e designados por Tc.
Dessa forma, a cada CV que provem do roteador fonte e atribuda uma CIR,
que e expressa em unidades de bits/seg. A CIR nunca e maior que R, a taxa de
acesso. Os clientes pagam por uma CIR especfica; quanto maior a CIR, maior
e o valor pago ao provedor. Se o CV gerar pacotes a uma taxa menor do que a
CIR, ent ao todos os pacotes sao marcados como de alta prioridade. Contudo,
se a taxa na qual a CV gerar pacotes exceder a CIR, ent ao a frac
ao de pacotes
do CV que excederem a taxa ser a marcada como pacotes de baixa prioridade.
Mais especificamente, a cada intervalo d medic ao Tc, para os primeiros CIR.Tc
bits que o CV enviar, o comutador de borda marca os pacotes correspondentes
como sendo de baixa prioridade.
Por exemplo, suponha que o provedor de servico Frame Relay use um inter-
valo de medic
ao Tc=500 ms. Suponha que a taxa de enlace de acesso seja R=64
Kbps e que a CIR atribuda ` aquele CV em particular seja 32 Kbps. Suponha
tambem, para facilitar, que cada pacote Frame Relay consista em exatamente
L=4000 bits. Isso significa que a cada 500 ms o CV pode enviar CIRxTc/L=4
pacotes como pacotes de alta prioridade. Todos os pacotes adicionais dentro do
intervalo de 500 ms s ao marcados como pacotes de baixa prioridade.
Devemos ter em mente que muitos CVs podem provir do roteador fonte e
transitar pelo enlace de acesso. E interessante notar que se permite que a soma
das CIRs para todos esses CVs exceda a taxa de acesso R. Isso e chamado de
excesso de reserva. Como o excesso de reserva e permitido, um enlace de acesso
pode transmitir pacotes de alta prioridade a uma taxa de bits correspondente
que esceda a CIR (mesmo que cada CV individual envie pacotes priorit arios a
uma taxa que n ao exceda a CIR).
353
Captulo 39
Redes Virtuais Locais
39.1 VLANs
39.1.1 Defini
cao
Uma Virtual Lan, ou simplesmente vlan, e um metodo para se criar redes l
ogicas
independentes dentro de uma rede fsica. As vlans facilitam a administrac
ao da
rede separando logicamente segmentos l ogicos de uma lan, por exemplo, depar-
tamentos distintos. As vlans reduzem o domnio de broadcast, diminuindo o
tr
afego na rede. Ou seja, os pacotes ARP broadcast enviados por um host A
que deseja descobrir o endereco MAC de um host B, ambos de uma mesma vlan
V, nao ser ao escutados por um host C que n ao pertenca a vlan V. Uma vlan
e uma subrede na qual os computadores n ao necessariamente precisam estar
conectados no mesmo segmento fsico. O que torna as vlans extremamente flex-
iveis e o fato de os administradores da rede podem configurar as vlans atraves
de software.
39.1.2 Protocolo 802.1q

As vlans operam na camada de enlace do modelo de referencia OSI, no entanto,
os administradores de rede geralmente configuram uma vlan para mapear di-
retamente uma rede ou subrede IP, o que d a a impressao de que esta e uma
tecnolgia que envolve a camada de rede. Atualmente, o protocolo IEEE 802.1q
e o mais popular para implementac
ao de vlans.
Para desenvolver a tecnologia de vlans, a tarefa mais dficil enfrentada pelo

comite 802 do IEEE foi definir como armazenar o identificador da vlan dentro
de um quadro Ethernet. Depois de muita discurs ao o comite fez o impens avel
e mudou o cabecalho do quadro Ethernet, adicionando uma tag VLAN. Uma
mudanca do cabecalho Ethernet s o foi possvel pois o comite 802 mostrou que
o campo VLAN s o e realmente utilizado pelos switches e pontes e n ao pelas
maquinas dos usu arios. Assim, a sada para o problema foi a seguinte: se a
origem n ao gerar a tag VLAN, o primeiro switch ou bridge que for capaz de
identificar a VLAN para o quadro acrescentar a o quadro, enquanto o u ltimo
dispositivo do percurso remover a a tag para entregar o quadro ` a maquina de
354
destino. Embora muitas das novas placas Ethernet ja sejam compatveis com o
padrao 802.1q, geralmente o quadro e marcado com a tag vlan por um switch.
Dessa forma, apenas os switches precisam ser configurados.
Na verdade, o padr ao 802.1q adicionou ao cabecalho Ethernet um campo

chamado Tag Protocol ID (TPID) e um campo Tag Control Information (TCI),
que por sua vez e subdividido em tres partes que sao CFI, Pri, e VID. Um
quadro 802.1q e reconhecido quando o campo TPID possui o valor 0x8100. O
campo CFI e utilizado para compatibilizac
ao com redes Token Ring, enquanto
o campo VID e o identificador de vlan de fato. O campo Pri possui 3 bits e
e utilizado para implementar mecanismos de prioridade no nvel de enlace. O
modo como deve ser utilizado o campo Pri e definido no padr ao IEEE 802.1p.
O novo cabecalho do Ethernet pode ser visto na figura 39.1.2.
Figura 39.1: Frame 802.1q

355
Captulo 40
Redes de Circuito Virtuais
40.1 Redes ATM

Uma rede ATM (Asyncronous Transfer Mode) tem como principal caracterstica
o fato de ser orientada a conex ao, Portanto, antes do incio da transmissao de
dados e necessario que todos os roteadores entre a origem e o destino registrem a
existencia da conexao e reservem recursos para ela. Essas conexoes s
ao chamadas
de circuitos virtuais, que podem ser dinamicos (Switched Virtual Circuit - SVC)
ou permanentes (Permanent Virtual Circuit - PVC). O protocolo de sinalizac ao
utilizado para estabelecimento das conex oes e o Q.2931.
A ideia b
asica do ATM e transmitir as informac oes em pequenos pacotes
chamdos celulas. As celulas ATM possuem o tamanho fixo de 53 bytes, sendo 5
para o cabecalho e 48 para a carga u
til. O fato das celulas terem tamanho fixo
permite que todo o roteamento das celulas seja feito via hardware. A estrutura
de uma celula ATM pode ser vista na figura (est a faltando) ??.
VPI (Virtual Path Identifier ): representa o n

umero da rota virtual ate o
destinat
ario da informac
ao u
til;
VCI (Virtual Channel Identifier ):representa o n

umero do canal virtual
dentro de uma rota virtual especfica;
PT (Payload Type): identifica o tipo de informac

ao que a celula contem:
de usu
ario, de sinalizacao ou de manutenc
ao;
CLP (Cell Loss Priority): indica prioridade da celula caso sejam necess
arios
descartes por motivos de congestionmento;
HEC (Header Error Correction): Permite correc

ao de erros de um bit e
detecc
ao de erros de mais de um bit.
Os campos VPI e VCI s ao utilizados no processo de comutac ao das celulas.

importante destacar que os valores de VPI e VCI s
E ao alterados a medida que
a celula trafega pela rede. Por ser baseada em circuitos virtuais, a rede ATM
garante a ordenacao na entrega das celulas. No entanto, n
ao e capaz de garantir
a entrega. Quando um detecta um erro de mais de um bit a partir do campo
356
HEC, a celula e descartada.
As redes ATM tem seu pr

oprio modelo de referencia, diferente do modelo
OSI e do modelo TCP/IP. O ATM e um modelo tridimensional, sendo composto
n
ao s
o por camadas, mas tambem por planos, como mostrado na figura 40.1.
Figura 40.1: Modelo de Referencia ATM
O plano de usu ario e responsavel pelo transporte de dados, pelo fluxo de

controle e pela correc
ao de erros, enquanto o plano de controle trata do gerencia-
mento de conex oes. No modelo ATM todas as camadas possuem funcionalidades
de usu ario e de controle. A descricao de cada uma das camadas e mostrada a
seguir:
Camada Fsica: prove os meios para transmitir as celulas ATM. A sub-
camada TC (Transmission Convergence) mapeia as celulas ATM no for-
mato dos frames da rede de transmiss ao (SDH, SONET, PDH, etc.). A
sub-camada PM (Physical Medium) temporiza os bits do frame de acordo
com o rel
ogio de transmiss
ao;
Camada ATM: e respons avel pela construc
ao, processamento e trans-
missao das celulas, e pelo processamento das conex oes virtuais. Esta ca-
mada tambem processa os diferentes tipos e classes de servicos e controla
o tr
afego da rede;
Camada de Adaptac ao ATM ou AAL (ATM Adaptation Layer ): e re-
sponsavel pelo fornecimento de servicos para a camada de aplicac ao su-
perior. A sub-camada CS (Convergence Sublayer ) converte e prepara a

informacao de usu
ario para o ATM, de acordo com o tipo de servico, alem
de controlar as conexoes virtuais. A sub-camada SAR (Segmentation and
Reassembly) fragmenta a informac ao para ser encapsulada na celula ATM.
A camada AAL implementa ainda os mecanismos de qualidade de servico
e sinalizac
ao.
Os tipos de servico oferecidos pelas redes ATM s
ao os seguintes:
CBR (Constant Bit Rate): Garantida uma taxa de transmiss ao constante.
Aplicac
oes tpicas que necessitam desse tipo de servico s ao telefonia e
distribuic
ao de
audio e vdeo (televis
ao, pay-per-view etc.);
357
VBR (Variable Bit Rate): Garantida uma taxa media de transmiss ao e

um valor m aximo de pico. Aplicac oes tpicas deste servico s
ao voz com
taxa vari
avel de bits e vdeo comprimido (MPEG, por exemplo);
ABR (Available Bit Rate): Garantida uma taxa mnima de transmiss ao.
Aplicado a conex oes que transportam trafego em rajadas que podem pre-
scindir da garantia de banda, variando a taxa de bits de acordo com a
disponibilidade da rede ATM. Aplicac oes tpicas deste servico tambem
s
ao as interligac
oes entre redes e a emulac
ao de LANs;
UBR (Unspecified Bit Rate): A capacidade de transmiss ao restante e alo-

cada ao trafego. Utilizada para tr
afego que n
ao possui requisitos de atraso
ou jitter, como transferencia de arquivos e email.
40.2 MPLS - Multiprotocol Label Switching

A medida em que a Internet foi crescendo e os servicos nela oferecidos foram se
tornando mais sofisticados foi se tornando necess ario desenvolver novas tecnicas
para garantir nveis de qualidade de servico altos. Enquanto o IETF se concen-
trou na concepc ao das arquiteturas de servicos integrados e servicos diferencia-
dos, v arios fabricates se concentravam desenvolvimento de metodos de encam-
inhamento melhores. Esse trabalho se concentrou na inclus ao de um r
otulo no
incio de cada pacote, de forma que o roteamento pudesse ser feito com base nos
r
otulos e n ao mais a partir do endereco de destino. Dessa forma, os engenheiros
pretendiam tornar o processo de encaminhamento muito mais eficiente. Uma
das motivac oes da epoca era o fato de que pacotes IP n ao podiam ser encam-
inhados completamente via hardware (hoje j a e possvel), e com o MPLS, isso
poderia ser feito.
O MPLS e um protocolo que permite emular algumas propriedades de redes

de comutac ao de circuitos utilizando para isso a tecnica de circuitos virtuais.
O MPLS opera entre as camadas de enlace e de rede de forma independente,
e por isso muitas vezes e dito ser um protocolo de camada 2.5. Poe esse mo-
tivo e possvel contruir switches MPLS capazes de encaminhar tanto pacotes IP,
celulas ATM ou outros. Da o nome Multiprotocol Label Switching.
O MPLS funciona adicionado aos pacotes um cabecalho adicional contendo

um ou mais r otulos (labels), formando uma pilha de r
otulos. Cada um dos
r
otulos e composto por quatro campos que s
ao:
Label: 20 bits utilizados para indicar o valor do r

otulo propriamente dito.
com base no valor desse campo que os pacotes s
E ao encaminhados;
CoS: 3 bits utilizados para indicar a classe de servico;

S: 1 bit que quando setado para 1 indica que o r
otulo e o u
ltimo da pilha;
TTL: 8 bits para indicar o maximo n

umero de hops que um pacote pode
dar antes de ser descartado.
358
Figura 40.2: Formato do r

otulo MPLS
Figura 40.3: Empilhamento de r

otulos MPLS entre as camadas 2 e 3
O processo de encaminhamento ocorre da seguinte maneira. Quando um

pacote rotulado com MPLS chega a um rotedor, o r otulo o campo label e anal-
isado a fim de determinar por qual linha de sada o pacote deve sair. O roteador
tambem e responsavel por determinar com qual r otulo o pacote dever
a sair. A
essa operac
ao de troca de r
otulos d
a-se o nome de swap.
Quando um pacote ainda n ao rotulado chega a um rotedor e precisa passar

por um t
unel MPLS, o rotedor deve primeiro determinar a classe de equivalencia
do pacote (forwarding Equivalence Class - FEC) para ent ao adicionar um ou
mais r
otulos ao pacote. O FEC e um mecanismo de agregac ao que permite usar
um unico r
otulo para pacotes de conexoes diferentes mas tem o mesmo destino
ou pertencem a mesma classe de servico. Isso pemite diminuir o n umero da
tabela de encaminhamento e aumentar a velocidade de encaminhamento.
Alem da operacao de troca de r otulos (swap), o MPLS possui ainda mais

duas operacoes que sao a adic
ao de um novo r otulo (push) e a remoc
ao de
um rotulo (pop). A adicao de um novo r otulo serve para encapsular o pacote
em outra camada de MPLS, permitindo por exemplo, a criac ao de VPNs. A
operac
ao de remocao do rotulo e dita desencapsulamento. Quando o u ltimo
r
otulo e removido diz-que que o pacote deixou o t unel MPLS.
Assim como em outras tecnologias de circuito virtual, o MPLS utiliza proto-

colos auxiliares para criar e desfazer suas conexoes. Atualmente s
ao utilizados
o CR-LDP (Contraint-based Routing - Label Distribution Protocol ) e o RSVP-
TE (Resource Reservation Protocol - Traffic Engineering). Ambos realizam a
distribuic
ao de r
otulos com base em restricoes de qualidade de servico, rotas
obrigat
orias etc.
Outra considerac
ao importante sobre a tecnologia MPLS e que, diferente-
mente de outras tecnologias de circuito virtual como ATM, uma conex ao MPLS
e unidirecional. Uma conex ao MPLS e tambem chamada LSP (Label Switched
Path). Para estabelecimento de uma comunicac ao bidirecional e necess
ario es-
tabelecer dois LSPs. Isso e feito de forma independente entre origem e destino,
de forma que os dados em um sentido podem seguir por uma rota diferente dos
dados no sentido oposto.
359
Captulo 41
Arquitetura TCP/IP
41.1 Vis
ao geral
A arquitetura TCP/IP surgiu com a criac ao de uma rede chamada ARPANET,
que foi uma rede criada para manter comunicac ao entre os
org
aos do governo
dos EUA e as universidades. A ARPANET cresceu e tornou-se a rede mundial
de computadores, a Internet.
A arquitetura TCP/IP trata de um conjunto de protocolos divididos em qua-
tro camadas: Fsica (host/Rede), Rede (Inter-Rede ou Internet), Transporte e
Aplicac
ao; onde cada uma executa um conjunto bem definido de func oes de co-
municacao. Nesta arquitetura n
ao existe uma estruturac
ao formal para cada ca-
mada conforme ocorre no modelo OSI. Ela procura definir um protocolo pr oprio
para cada camada, assim como a interface de comunicac ao entre duas camadas
adjacentes. A figura ?? 1 mostra a arquitetura TCP/IP.
41.2 Comparac
ao entre a arquitetura OSI e TCP/IP
Os modelos de referencia OSI e TCP/IP tem muito em comum. Os dois se ba-
seiam no conceito de pilha de protocolos independentes. Alem disso, as camadas
tem praticamente as mesmas func oes. Apesar dessas semelhancas, os modelos
tem muitas diferencas.
O modelo OSI torna explcita a diferenca do conceito de servico, de interface
e de protocolo. Enquanto que o modelo TCP/IP n ao diferencia com clareza
esses conceitos. Por esse motivo, o modelo OSI os protocolos s ao bem mais en-
capsulados que os do TCP/IP e podem ser substitudos com relativa facilidade.

O modelo TCP/IP n ao e nem um pouco abrangente e n ao consegue descrever
outras pilhas de protocolo que n ao a pilha TCP/IP.
Uma diferenca explcita est
a no numero de camadas. O modelo OSI possui
sete e o TCP/IP possui quatro. Outra diferenca est a na area de comunicac ao
sem conex ao e orientada a conex oes. Na camada de rede, o modelo OSI e
compatvel com a comunicac ao sem conex ao e orientada a conexoes. No entanto,
na camada de transporte, o modelo aceita apenas comunicac ao orientada a
conexoes. O modelo TCP/IP s o tem um modo de operac ao na camada de rede
(sem conex ao), mas aceita ambos os modos na camada de transporte.
360
No modelo TCP/IP, a camada fsica n ao e realmente uma camada no sentido

em que o termo e usado no contexto dos protocolos hierarquizados. Trata-se,
na verdade, de uma interface entre a camada de redes e de enlace de dados. E
ainda, o modelo n
ao faz distinc
ao entre as camadas fsicas e de enlace de dados.
41.3 Camada Fsica (host/rede)

A arquitetura TCP/IP n ao defini muito bem o que acontece nesta camada, ape-
nas especifica que o host tem que se conectar ` a rede utilizando algum protocolo
para que seja possvel enviar pacotes IP. Esse protocolo n ao e definido e varia
de host para host e de rede para rede.
Esta camada tambem e chamada de camada de abstrac ao de hardware, pois
sua func
ao principal ser uma interface do modelo TCP/IP com os diversos tipos
de rede (X25, ATM, FDDI, Ethernet, Token Ring, Frame-Relay, etc.). Como
h
a uma grande variedade de tecnologias de rede, que utilizam diferentes veloci-
dades, protocolos, meios de transmiss ao, etc., esta camada n ao e normatizada
pelo modelo TCP/IP, o que prove uma das grandes vantagens do modelo: a
possibilidade de interconexao e interoperac
ao de redes heterogeneas.
Os protocolos desta camada s ao:
PPP (Point-to-Point Protocol): e um protocolo ponto a ponto utilizado

para transportar datagramas atraves de uma conex ao serial entre dois dis-
positivos de rede, por exemplo, entre modems (do usu ario e do provedor
de Internet). Ele aceita a detecc
ao de erros, negociac
ao de opc
oes, com-
pactac
ao de cabecalhos e, opcionalmente, a transmiss ao confiavel com o
uso de um formato de quadro do tipo HDLC.
ARP (Address Resolution Protocol): e um protocolo utilizado para de-

scobrir o endereco fsico (MAC) de uma m
aquina a partir de seu endereco
IP;
RARP (Reverse ARP): e um protocolo utilizado descobrir o endereco IP

de uma m
aquina a partir de um endereco fsico.
Pode-se dizer que os protocolos ARP e RARP pertencem tambem `

a camada
Inter-Rede.
41.4 Camada de Inter-Rede

A camada de Inter-Rede e a primeira normatizada pelo modelo TCP/IP. Con-

hecida tambem como camada Internet (Rede), esta camada define o protocolo
IP (Internet Protocol) responsavel pelo enderecamento dos hosts e roteadores.
A tarefa desta camada e entregar pacotes IP onde eles s
ao necess
arios. O rotea-
mento de pacotes e uma quest ao de grande import ancia nesta camada, assim
como a necessidade de evitar o congestionamento.
Alem do protocolo IP, a camada de Inter-Rede define alguns outros proto-
colos:
ICMP (Internet Control Message Protocol): e um protocolo utilizado para

transmiss
ao de mensagens de controle ou ocorrencia de problemas;
361
OSPF (Interior Gateway Routing Protocol): e um protocolo de rotea-

mento em um Sistema Aut
onomo;
IP (Routing Information Protocol): e um protocolo que permite a troca de

informac
oes de roteamento entre gateways utilizando o algoritmo Vector-
Distance;
BGP (Boder Gateway Protocol): e um protocolo de roteamento entre

Sistemas Aut
onomos.
41.5 Camada de Transporte

A camada de transporte e o n ucleo de toda a hierarquia de protocolos. E uma
camada fim a fim, isto e, uma entidade desta camada da m aquina de origem s o
se comunica com uma entidade par da m aquina de destino. Sua func
ao e prover
uma transferencia de dados confi avel e econ omica entre a maquina de origem e
a maquina de destino, independente das redes fsicas em uso no momento.
Dois protocolos fim a fim s ao definidos nesta camada. O primeiro deles,
o TCP (Transmission Control Protocol) e um protocolo orientado a conex ao
confiavel que permite a entrega sem erros de um fluxo de bytes, verificando se a
ordem e a seq uencia dos dados recebidos e enviados est ao corretas. O segundo
protocolo, O UDP (User Datagram Protocol) e um protocolo sem conex ao e
nao-confiavel, ou seja, n
ao oferece nenhuma garantia em relac ao `
a entrega dos
dados ao destino.
Para distinguir entre v arias aplicac
oes, a camada de Transporte associa um
identificador a cada processo de aplicac ao. Esse identificador e chamado de
porta. Para uma aplicac ao falarcom outra numa m aquina remota, e preciso
conhecer n ao apenas o endereco IP da m aquina destino, mas tambem a porta
associada a cada aplicac ao. O UDP e o TCP fornecem um conjunto de portas
que permite a m ultiplos processos dentro de uma u nica m aquina usarem os
servicos providos pelo UDP e TCP simultaneamente. O protocolo TCP utiliza
o conceito de sockets para caracterizar uma conex ao entre a origem e o destino.
O socket consiste no endereco IP da m aquina e a porta.
41.6 Camada de Aplica

cao
formada pelos protocolos utilizados pelas diversas aplicac
E oes do modelo TCP/IP.
Esta camada n ao possui um padr ao comum, cada aplicac ao define o seu pr
oprio
esta camada que trata a compatibilidade entre os diversos formatos

protocolo. E
representados pelos variados tipos de estac
oes da rede.
Os principais protocolos desta camada s ao:
TELNET (TeleType Network): e um protocolo utilizado para acessar sis-

temas remotos por meio de um terminal. Utiliza a porta 23 do protocolo
TCP;
FTP (File Transfer Protocol): e um protocolo utilizado para servicos de

transferencia, renomeacao e eliminac
ao de arquivos, alem da criac
ao, mod-
ificac
ao e exclus
ao de diretorios. Utiliza duas conex oes TCP: uma para
362
controle, porta 21, e outra para dado, porta 20. As transferencias de

arquivos podem ser no modo texto ou binario;
SNMP (Simple Network Management Protocol): e um protocolo utilizado

trafegar informac
oes sobre dispositivos da rede, ou seja, gerenciamento da
rede. Utiliza duas conexoes UDP: uma para requisic oes, porta 161, e uma
para as mensagens de trap, porta 162;
DNS (Domain Name Server): e um protocolo utilizado para realizar o ma-

peamento entre nomes e endereco IP. Utiliza a porta 43 do protocolo UDP
para resoluc
ao de nomes e a porta 53 do protocolo TCP para transferencia
de zonas;
DHCP (Dynamic Host Configuration Protocol): e um protocolo que per-

mite realizar a configurac
ao autom
atica de enderecos de hosts em uma
rede ou na Internet;
SMTP (Simple Mail Transfer Protocol): e um protocolo utilizado para

enviar mensagens de correio eletr
onico. Usualmente, utiliza a porta 25 do
protocolo TCP;
HTTP (HyperText Transfer Protocol): e um protocolo de transferencia

de mensagens utilizado na WWW. Usualmente, utiliza a porta 80 ou 8080
do protocolo TCP;
NFS (Network File System): e um protocolo que permite montardiscos
ou parte deles de dispositivos remotamente e oper a-los como se fossem
locais. Inicialmente este protocolo utiliza a porta 2049 do protocolo UDP,
mas a vers ao NFS4 utiliza a porta 2049 do protocolo TCP;
363
Captulo 42
Camada de Aplica
c
ao
42.1 Proxy Cache

Um proxy cache, ou simplesmente proxy, e uma entidade de rede que atende
requisic
oes HTTP em nome de um servidor Web de origem. Um proxy tem seu
pr
oprio disco de armazenagem onde mantem c opias dos objetos recentemente
requisitados. Alguns dos objetivos da utilizacao de um proxy e a reducao na
utilizac
ao dos links de a acesso a internet e a diminuic
ao do atraso percebido
pelo usu ario no atendimento de uma requisicao. Os dois principais tipos de
proxy s ao:
Interceptac
ao: Trabalha interceptando o trafego da rede de forma trans-
parentemente, n ao sendo necessaria nenhuma configurac
ao adicional nos
browsers. Sao utilizados especialmente pelos ISPs.
Intermediario: Geralmente utilizados em ambientes que constituem um

domnio administrativo (empresas, universidades etc.), uma vez que e
necess
aria a configuracao dos browsers. Esse tipo de proxy pode ainda
implementar outras func oes como autenticac
ao e filtros de conte
udo.
Para que um proxy possa atender as requisic oes dos usu

arios de forma cor-
reta e necess
ario que ele determine se um documento que est a em cache e v
alido
ou nao. Para isso, os servidores proxy utilizam alguns campos do cabecalho das
respostas HTTP. O campo Max-Age, por exemplo, informa por quanto tempo
em segundos a resposta ser a valida. Quando o documento em cache n ao possui
a informacao max-age, o proxy pode utilizar o metodo GET em conjunto com o

campo If-Modified-Since (GET condicional) para solicitar ao servidor uma nova
c
opia do mesmo caso ele tenha sido modificado desde a data definida.
Os proxies podem ainda serem organizados de forma hier arquica, de modo

que um proxy possa consultar outros sobre seu conte udo e, baseado nos tem-
pos de respostas, decide qual cache entregara um dado objeto. Para essa co-
municac
ao sao utilizados protocolos como o ICP (Internet Cache Protocol ) e
HTCP (Hyper Text Caching Protocol ). Outro mecanismo de implementar a co-
municac
ao entre proxies e utilizando o chamado Cache-Digest, que consiste de
um sum ario do conteudo do cache de um servidor que e trocado periodicamente
364
com outros servidores pertencentes `

a hierarquia.
365
Parte VII
Ger
encia de Redes
366
Captulo 43
O protocolo SNMP
O SNMP (Simple Network Management Protocol ) e um protocolo da camada de

aplicac
ao que facilita a troca de informac
oes de gerenciamento entre dispositivos
de rede. O SNMP e o padr ao de fato para gerenciamento de redes.
Uma rede gerenciada por SNMP e composta basicamente por tres elementos
que sao: (i) os dispositivos gerenciados; (ii) os agentes de monitoramento e (iii)
os sistemas de gerenciamento de rede (Network Management Systems - NMSs).
Um dispositivo gerenciado e qualquer elemento da rede (hub, switch, roteador,

servidor etc.) que contenha um agente SNMP. Os disposivos gerenciados cole-
tam e armazenam informac oes e as tornam disponveis para os NMSs atraves
do protocolo SNMP. Essa informac oes s
ao armazenadas nas chamadas MIBs
(Management Information Base).
Um agente e um software que reside em um dispositivo gerenciado e tem con-

hecimento sobre as informac
oes de gerenciamento e e repons
avel pela traduc
ao
dessas para um formato compatvel com o SNMP.
Um NMS executa uma aplicac ao que monitora e controla os dispositivos

gerenciados. Existem duas formas b
asicas de comunicac
ao entre os agentes e os
NMSs.
Na primeira, o NMS envia uma mensagem GET para o agente solicitando

o envio de alguma informac ao. Geralmente os NMSs s ao configurados para
coletar informac
oes dos agentes periodicamente para armazena-las em bases de
dados para serem an alisados posteriormente. Um NMS pode ainda solicitar a
alterac
ao de alguma informacao enviando uma mensagem SET ao agente. As
mensagens enviadas do NMS para o agente utilizam a porta UDP 161. Para
recuperar todos os objetos de uma determinada sub arvore da MIB pode ser
utilizada a operac
ao GETNEXT.
Na segunda forma, o agente envia uma mensagem para o NMS quando de-
tecta alguma situac
ao pre definida. As mensagens enviadas do agente para
o NMS s ao cahamadas traps. O protocolo SNMP conta com algumas traps
nativas, porem os agentes podem ser contrudos para enviar traps em outras
367
situac
oes n
ao previstas pelo protocolo SNMP. As traps s
ao enviadas utilizando
a porta UDP 162.
Um conjunto de dispositivos SNMP (disposiotivos gerenciados e NMSs) po-

dem ser agrupados em comunidades. Uma mensagem SNMP originada por um
dispositivo SNMP que de fato pertence a comunidade SNMP referenciada e con-
siderada uma mensagem SNMP autentica.
Atualmente existem duas vers oes do protocolo SNMP que s ao SNMPv1 e

SNMPv2. O SNMPv2 introduziu duas novas operac oes que s
ao GETBULK e
INFORM. A GETBULK permite o NMS recuperar grandes blocos de dados
aumentando a eficiencia do protocolo, enquanto a operac
ao INFORM permite
a comunicac
ao entre dois NMSs na mesma rede.
Figura 43.1: Arquitetura SNMP
43.1 Management Information Base

A Management Information Base (MIB) e uma colec ao de informac
oes orga-
nizada de forma hier arquica como uma
arvore de raiz n
ao nomeada. A MIB
e composta por objetos gerenciados, cada um deles identificado por um OID
(object identifiers) u
nico.
Os IDs de nvel mais alto pertencem a diferentes organizac

oes de padronizac
ao
(ISO, ITU etc.), enquanto os IDs de nvel imediatamente inferior s ao alocados
para organizacoes associadas. Fabricantes podem definir ramos na arvore para
incluir objetos gerenciados para seus produtos. A estrutura de uma MIB e
mostrada na figura 43.2.
Os ramos mais comuns na estrutura de uma MIB s

ao os seguintes:
.1.3.6.1.2.0 ou (iso.org.dod.internet.mgmt.mib): Caminho para MIB vers

ao
I;
368
Figura 43.2: Estrutura da MIB
.1.3.6.1.2.1 ou (iso.org.dod.internet.mgmt.mib-2): Caminho para MIB II,

definida pela RFC 1213 para ser utilizada no gerenciamento de redes
baseadas na pilha TCP/IP. A MIB-II e subdividida nos 11 grupos de
informacao mostrados na figura 43.2;
.1.3.6.1.4.1 ou (iso.org.dod.internet.private.enterprises): Caminho para MIBs

proprietarias. A MIB dos equipamentos da Cisco, por exemplo, ficam
abaixo de .1.3.6.1.4.1.9 ou (iso.org.dod.internet.private.enterprises.cisco).
369
Parte VIII
Seguranca da Informa
c
ao
370
Captulo 44
Polticas de Seguran
ca de
Informac ao
44.1 Polticas de Seguran

ca
A poltica de seguranca tem por objetivo prover ` a administrac
ao uma direc ao
e apoio para a seguranca da informac ao. A administrac ao deve estabelecer
uma poltica clara e demonstrar apoio e comprometimento com a seguranca da
informacao atraves da emiss ao e manutenc ao de uma poltica de seguranca da
informacao para toda a organizac ao (ISO/IEC 17799:2000).
Uma poltica de seguranca e a express ao formal das regras pelas quais e
fornecido acesso aos recursos tecnol ogicos da empresa. O principal prop osito de
uma poltica de seguranca e informar aos usu arios, equipe e gerentes, as suas
obrigacoes para a protec ao da tecnologia e do acesso ` a informacao. A poltica
deve especificar os mecanismos atraves dos quais estes requisitos podem ser
alcancados.
Outro prop osito e oferecer um ponto de referencia a partir do qual se possa
adquirir, configurar e auditar sistemas computacionais e redes, para que sejam
adequados aos requisitos propostos. Portanto, uma tentativa de utilizar um
conjunto de ferramentas de seguranca na ausencia de pelo menos uma poltica
de seguranca implcita n ao faz sentido (RFC 2196).
A poltica deve especificar as metas de seguranca da organizac ao, onde as
responsabilidades recaem, e qual o comprometimento da organizac ao com a
seguranca.
Uma vez que a poltica e um estatuto, e necess ario que a sua elaborac ao,
aprovacao e aplicacao sigam os ritos internos da instituicao na qual sera aplicada.
O carater estrategico de uma poltica de seguranca deve garantir que a mesma
aborde quest oes que s ao essenciais para a corporac ao como um todo. Cada
regra da poltica serve como referencia b asica para a elaborac
ao do conjunto de
regras particulares e detalhadas que comp oem as normas e os procedimentos de
seguranca.
Com o intuito de tornar a poltica de seguranca um instrumento que viabilize
a aplicacao pr atica e a manutenc ao de uma infra-estrutura de seguranca para a
instituic
ao, e necessario que a poltica seja desdobrada em estatutos mais detal-
hados. Estes estatutos podem ser referidos como polticas especficas, normas,
371
regras complementares, ou controles. Outros nveis podem existir, tal qual numa
hierarquia, sendo que o limite ser a ditado pelas necessidades e conveniencias da
instituic
ao para a qual s ao elaborados as regras de seguranca. Cabe ressaltar
que, quanto mais baixo o nvel hier arquico de um documento de seguranca em
relac
ao à poltica, mais detalhado e de car ater operacional sera.
importante lembrar que toda regra aplicada a uma instituic
E ao deve estar
em conson ancia com os objetivos fins da mesma. A seguranca n ao e um fim em
si mesma, mas um meio para se chegar a um objetivo maior.
A poltica de seguranca como um elemento institucional da organizac ao pos-
sui um ciclo de vida indefinido e deve prever todos os mecanismos de defesa
contra qualquer ameaca conforme estabelecido no estudo de custos x benefcios.
Considerando a mutabilidade de tais elementos e dos pr oprios objetivos e metas
da organizac ao, uma poltica s
o apresentar a efetividade ao longo do tempo se
sofrer constantes reavaliac oes e atualizac
oes.
ISMS - Information Security Management System, ou Sistema de Gerencia-
mento da Seguranca da Informac ao (SGSI) - e o resultado da aplicac
ao planejada
de objetivos, diretrizes, polticas, procedimentos, modelos e outras medidas ad-
ministrativas que, de forma conjunta, definem como s ao reduzidos os riscos para
seguranca da informac ao.
44.2 Projeto de Seguran

ca
A estrategia de seguranca da informac
ao de uma empresa exige a elaborac
ao de
um projeto de seguranca (nvel mais alto de abstracao) que descreva todos os
aspectos da seguranca da informac ao na empresa. Um desses aspectos consiste
na elaboracao de um plano de seguranca. O projeto de seguranca, segundo
Oppenheimer (1999), envolve v arias etapas de trabalho:
Identificac
ao dos ativos da empresa em termos de informac
oes;
An
alise dos riscos de seguranca;
An
alise dos requisitos de seguranca e compromissos;
Desenvolvimento de um plano de seguranca;
Definic
ao de uma norma de seguranca;
Desenvolvimento de procedimentos para implantar a norma e uma es-
trategia de implementac
ao;
Implementac
ao, gerenciamento e auditoria dos procedimentos de segu-
ranca.
44.3 Plano de Seguran

ca
Plano de Seguranca e um documento de alto nvel que prop oe o que uma or-
ganizac
ao deve fazer para satisfazer os requisitos de seguranca, contendo a
relac
ao dos servicos de TI disponibilizados, quais areas da empresa disponi-
bilizam os servicos, quem tera acesso aos servicos, a descric
ao detalhada de
sua implementac ao, dos procedimentos de controle dos ambientes, incidentes e
372
contingencias. O plano especifica o tempo, as pessoas e outros recursos que

ser
ao necess arios para desenvolver uma norma de seguranca e alcancar a imple-
mentacao tecnica da norma.
O plano deve estar baseado na an alise de ativos de redes e riscos. Deve fazer
referencia `
a topologia de rede e incluir uma lista de servicos de rede que ser ao
fornecidos, como por exemplo, FTP, Web, correio eletr onico e outros. Esta lista
deve especificar quem fornecer a os servicos, quem ter a acesso aos servicos, o
modo como o acesso ser a fornecido e quem ira administrar os servicos.
Um dos aspectos mais importantes do plano de seguranca e uma especificac ao
das pessoas que devem estar envolvidas na implementac ao da seguranca de rede:
Ser
ao contratados administradores de seguranca especializados?
Como os usu
arios finais e seus gerentes estar
ao envolvidos?
Como os usuarios finais, gerentes e pessoal tecnico ser
ao treinados sobre
normas e procedimentos de seguranca?
Para ser u
til, um plano de seguranca precisa ter o apoio de todos os nveis de
funcionarios dentro da organizac
ao. E muito importante que a administrac ao
corporativa apoie plenamente o plano de seguranca. O pessoal tecnico da rede
e de locais remotos deve se envolver no plano, da mesma forma que os usu arios
finais (Oppenheimer, 1999).
44.4 Normas de Seguran

ca
Norma de seguranca e uma declarac ao formal das regras ` as quais as pessoas que
tem um determinado acesso a` tecnologia e aos ativos de informac oes de uma
organizacao devem obedecer. (RFC 2196, The Site Security Handbook).
Pode-se definir ainda, norma de seguranca como sendo um estatuto no qual
est
ao transcritas regras de nvel intermedi ario, ou seja, entre o nvel estrategico
e o de descric
ao de procedimentos, cujo cumprimento visa garantir a seguranca
das informacoes e recursos de uma instituic
ao, dentro de um segmento particular
do ambiente desta corporac ao.
A norma de seguranca informa aos usu arios, gerentes e ao pessoal tecnico de
suas obrigacoes para proteger os ativos de tecnologia e informac oes. A norma
deve especificar os mecanismos pelos quais estas obrigac oes podem ser cumpri-
das. Da mesma forma que o plano, a norma de seguranca deve ter o compro-
metimento de funcion arios, gerentes, executivos e pessoal tecnico.
Uma vez desenvolvida, a norma de seguranca deve ser explicada a todos pela
gerencia superior. Muitas empresas exigem que o pessoal assine uma declarac ao
indicando que leu, compreendeu e concorda em cumprir as normas. A norma
de seguranca e um documento vivo. Pelo fato de as organizac oes mudarem
continuamente, as normas de seguranca devem ser atualizadas com regulari-
dade a fim de refletirem novas orientac oes comerciais e mudancas tecnol ogicas
(Oppenheimer, 1999).
44.4.1 ISO/IEC 17799

A ISO/IEC 17799 e a versao internacional da BS7799, homologada pela Inter-
national Standartization Organization em dezembro de 2000. A NBR ISO/IEC
373
17799 e a vers ao brasileira da norma ISO, homologada pela ABNT em setembro

de 2001. A norma ISO e rigorosamente identica a norma BS7799. A norma
brasileira e a traducao literal da norma ISO.
BS7799 - Brithish Standart 7799 - e uma norma de seguranca da informac ao
destinada a empresas. Criada na Inglaterra, teve seu desenvolvimento iniciado
em 1995, dividindo-se em duas partes: A BS7799-1 e a BS7799-2. A BS7799-1
e a primeira parte da norma que contem uma introduc ao, definic
ao de extens ao
e condicoes principais de uso da norma. Disponibiliza 148 controles divididos
em dez partes distintas. E planejada como um documento de referencia para
implementar boas pr aticasde seguranca na empresa.
A BS7799-2 e a segunda parte da norma e tem por objetivo proporcionar
uma base para gerenciar a seguranca da informac ao dos sistemas das empresas.
Uma empresa que implante a norma BS/ISO acaba por constituir um ISMS. A
forma de como implementar um ISMS e descrita na norma BS7799-2.
As normas publicadas pela Organizac ao Internacional de Normalizac ao, a
ISO, tem uma grande aceitac ao no mercado. Um exemplo disso e a norma
ISO 9001:2000, que trata da Gest ao da Qualidade, considerada como a mais
difundida norma da ISO que existe no mundo. No caso da NBR ISO IEC
17799, que e um C odigo de Boas Pr aticas para a Seguranca da Informac ao, a
sua aplicacao e um pouco mais restrita que a ISO 9001:2000, pois ela n ao e uma
norma voltada para fins de certificac ao.
Entretanto, a NBR ISO IEC 17799 pode ser usada pela maioria dos setores
da economia, pois todas as Organizac oes, independentemente do seu porte ou
do ramo de atuac ao, do setor p ublico ou privado, precisam proteger suas in-
formac oes sensveis e crticas.
As principais recomendac oes da NBR ISO IEC 17799 s ao organizadas em 11
sec
oes:
Poltica de Seguranca de Informac

ao;
Organizando a Seguranca da Informac
ao;
Gest
ao de Ativos;
Seguranca em Recursos Humanos;
Seguranca Fsica e do Ambiente;
Gerenciamento das Operac

oes e Comunicac
oes;
Controle de Acesso;
Aquisic
ao, Desenvolvimento e Manutenc
ao de Sistemas de Informac
ao;
Gest
ao de Incidentes de Seguranca da Informac
ao;
Gest
ao da Continuidade de Neg
ocios;
Conformidade.
Ela permite que uma empresa construa de forma muito r apida uma poltica
de seguranca baseada em controles de seguranca eficientes. Os outros caminhos
para se fazer o mesmo, sem a norma, s ao constituir uma equipe para pesquisar
374
o assunto ou contratar uma consultoria para realizar essas tarefas. Ambas as

opc
oes s
ao caras e demoradas.
A ISO/IEC 17799:2000 tem como objetivo permitir que companhias que
cumprem a norma demonstrem publicamente que podem resguardar a confi-
dencialidade, integridade a disponibilidade das informac oes de seus clientes.
A ISO/IEC 17799:2000 fornece mais de 127 orientac oes de seguranca estru-
turadas em 10 ttulos principais para possibilitar aos leitores identificarem os
controles de seguranca apropriados para sua organizac ao ou areas de respons-
abilidade. Alem de fornecer controles detalhados de seguranca para computa-
dores e redes, a ISO/IEC 17799:2000 d a orientac
oes sobre polticas de seguranca,
conscientizac
ao sobre seguranca para os funcionarios, plano de continuidade dos
negocios e requisitos legais.
44.4.2 Famlia ISO 27000

A serie de normas ISO 27000, encabecadas pela ISO 27001 est ao sendo elabo-
radas para substituir e completar os padr oes definidos pela BS7799.
Como forma de dar suporte ` a implantac
ao da ISO IEC 27001:2005, o Comite
da ISO que trata da seguranca de informa decidiu pela criac ao de uma famlia
de normas sobre Gest ao da Seguranca da Informac ao. Esta famlia foi batizada
pela serie ISO IEC 27000, a exemplo da serie ISO 9000 das normas de qualidade
e da serie ISO 14000 das normas sobre meio ambiente.
Esta nova famlia est
a relacionada com os requisitos mandat orios da ISO IEC
27001:2005, como, por exemplo, a definic ao do escopo do Sistema de Gest ao de
Seguranca da Informac ao, a avaliac
ao de riscos, a identificac
ao de ativos e a
efic
acia dos controles implementados.
As normas da famlia ISO IEC 27000 s ao:
27000 O seu objetivo e apresentar os principais conceitos e modelos de SI.
Ainda est
a em processo de desenvolvimento (previsao 2008-2009).
27001 Define requisitos para estabelecer, implementar, operar, monitorar, re-

visar, manter e melhorar um Sistema de Gest ao de Seguranca de In-
formac a norma usada para fins de certificac
ao. E ao e substitui a norma
brit
ancia BS7799-2:2002. E a base para as Organizac
oes que desejam im-
plementar um SGSI.
27002 Guia pratico de diretrizes e princpios gerais para iniciar, implementar,

manter e melhorar a gest ao de SI em uma Organizac ao. Os objetivos de
controle e os controles atendem aos requisitos identificados na an alise de
riscos.
27003 Guia pr
atico para a implementac
ao de um SGSI, baseado na ISO IEC
27001. Ainda est
a em processo de desenvolvimento (previs
ao 2008-2009).
27004 Fornece diretrizes com relac

ao a tecnicas e procedimentos de medic
ao
para avaliar a efic
acia dos controles de SI implementados, dos processos
de SI e do SGSI. Ainda est a em processo de desenvolvimento (previs ao
2008-2009).
27005 Fornece diretrizes para o gerenciamanto de riscos de SI. Esta norma ser
a
constituda por indicac
oes para implementac
ao, monitoramento e melhoria
375
contnua do sistema de controles. O seu conteudo devera ser identico ao

da norma BS 7799-3:2005 - Information Security Management Systems
- Guidelines for Information Security Risk Management, a publicar em
finais de 2005. A publicac
ao da norma como ISO est
a prevista para meados
de 2007.
27006 Esta norma ser a referente `
a recuperacao e continuidade de neg ocio.
Este documento tem o ttulo provis
orio de Guidelines for information and
communications technology disaster recovery services, nao estando calen-
darizado a sua edic
ao.
44.4.3 Diferen
cas entre a ISO/IEC 17799 e a ISO 27001
A norma ISO/IEC 27001 (Information Technology - Information Security Man-
agement Systems - Requirements) trata da implantac ao de um processo de
gestao de seguranca da informacao (ISMS - Information Security Management
Systems). Esta norma em conjunto com a ISO/IEC 17799 (C odigo de Boas
Praticas da Gest ao de Seguranca da Informacao) sao as principais referencias,
atualmente, para a quem procura tratar a quest ao da seguranca da informac ao
de maneira eficiente e com efic acia.
A ISO 27001 e uma norma que gere seguranca na corporac ao, ou seja, cria
um sistema de seguranca (SGSI) dentro de uma Organizac ao. Isso em nenhum
momento garante seguranca, s o torna o ambiente mais control avel. Nesta norma
ela contem controles de seguranca, apenas cita, por exemplo, o controle A.9.1.1 e
Permetro de Seguranca Fsica, uma definic
ao muito abragente,e pode ter v arias
interpretac
oes.
Ja a ISO/IEC 17799 possui todos os controles que tem na ISO 27001, s o
que com explicac oes e exemplos de implementac ao. Isso ajuda muito na imple-
mentacao numa corporac ao. Um fato importante e que s o ha certificac
ao ISO
27001, e n ao a NBR 17799. Alem disso, a certificac ao ISO 27001, contem um
descritivo do escopo, ou seja, quando uma empresa declara que e certificada ISO
27001, ela pode ser certificada apenas no CPD, por exemplo.
Como e uma norma de sistema de seguranca, a ISO 27001 tambem contem
controles de outras ISO, por exemplo a ISO 15408 (seguranca no desenvolvi-
mento), mas n ao quer dizer que ao atender completamente a ISO 27001, ser a
atendida a ISO 15408 ou o ITIL, que tambem possui alguns de seus controles
nessa norma.
44.5 Procedimentos de Seguran

ca
Os procedimentos de seguranca implementam normas de seguranca, definem

processos de configuracao, login, auditoria e configurac
ao.
Podem-se definir procedimentos de seguranca como sendo um estatuto no
qual estao transcritas regras de nvel operacional, ou seja, em nvel de de-
scric
ao de execuc
ao de ac
oes, cujo cumprimento visa garantir a seguranca das
informacoes de uma instituicao, dentro de um segmento particular do ambiente
da corporacao.
Devem ser escritos procedimentos de seguranca para usu arios finais, admin-
istradores de redes e administradores de seguranca. A divulgac ao deve ser re-
strita aos funcionarios diretamente envolvidos. Os procedimentos de seguranca
376
devem especificar como controlar incidentes (quer dizer, o que fazer e quem con-
tatar se uma intromissao for detectada), fazer auditoria e desenvolver o plano
de contingencia com objetivo de manter o negocio sempre ativo.
Os procedimentos de seguranca podem ser comunicados aos usu arios e ad-
ministradores em turmas de treinamento lideradas por instrutores qualificados.
44.6 Arquitetura de Seguran

ca
Com base na norma de seguranca, e criado um documento denominado poltica
de seguranca para ser divulgado em toda empresa. Para implementar a poltica
de seguranca deve ser criada uma arquitetura de seguranca que consiste na
aplicac
ao de todos os mecanismos de controles fsicos, l
ogicos, tecnicos e admin-
istrativos necessarios para a garantia da seguranca da informac ao (ROBERTI,
2001). Com base nessa arquitetura, s ao criados o plano de contingencia e o
processo de auditoria.
Uma arquitetura de seguranca representa um elenco de recomendac oes que
define os princpios e fundamentos que devem ser observados na implementac ao
de um ambiente considerado seguro em relac ao aos riscos, impactos e custos ao
qual ele est
a submetido.
A arquitetura de seguranca recomendada deve fornecer as bases para os
aspectos de seguranca dos seguintes elementos: aplicac oes, dados, comunicac ao
de dados e gerencia de sistemas e rede.
Uma arquitetura de seguranca deve levar em considerac ao tres elementos
basicos: pessoas, o modelo de seguranca e a junc
ao de padr oes e tecnologias.
E importante salientar que a arquitetura de seguranca proposta deve con-
duzir a implementac oes que sejam financeiramente possveis para a organizacao.
Para tanto, a arquitetura deve possuir as seguintes qualidades:
Ser independente de plataforma operacional, aplicac

ao de rede;
Ser alavancada por tecnologias de seguranca amadurecidas, por exemplo:
criptografias e cart
ao inteligente;
Estar em conformidade com padr

oes infacto, como por exemplo a norma
ISO/IEC 17799:2000 e CobiT;
Definir relacionamentos entre os componentes de seguranca: autenticac

ao
e permissao de acesso, por exemplo;
Ter performance e disponibilidade dos mecanismos de seguranca;

Possuir um modo consistente de gerenciamento;
Obter a conscientizac
ao de usu
arios finais.
44.7 Classificac
ao de Informa
coes
Segundo Claudia Dias (Dias, 2000), diferentes tipos de informac ao devem ser
protegidos de diferentes maneiras. Por isso a classificac ao das informacoes e
um dos primeiros passos para o estabelecimento de uma poltica de seguranca
de informac
oes. Um vez classificada a informac
ao, a poltica pode definir como
377
trata-la de acordo com sua classe, escolhendo mecanismos de seguranca mais

adequados.
A classificac
ao mais comum de informacoes e aquela que as divide em 04
nveis:
P
ublicas ou de uso irrestrito As informac oes e os sistemas assim classifica-
dos podem ser divulgados a qualquer pessoa sem que haja implicac oes
para a instituic
ao. Exemplo: servicos de informacao ao p
ublico em geral,
informac
oes divulgadas a` imprensa ou pela internet.
Internas ou de uso interno Podem ser chamadas tambem de corporativas.

As informac oes e os sistemas assim classificados nao devem sair do ambito
da instituic
ao. Porem, se isto ocorrer, as consequencias n
ao ser
ao crticas.
Exemplo: Servicos de informac ao interna ou documentos de trabalho cor-
riqueiros que so interessam aos funcion arios.
Confidenciais Informac oes e sistemas tratados como confidenciais dentro da

instituic
ao e protegidos contra o acesso externo. O acesso a estes sis-
temas e informac oes e feito de acordo com sua estrita necessidade, isto
e, os usu arios s
o podem acess a-los se estes forem fundamentais para o
desempenho satisfat orio de suas func oes na instituic
ao. O acesso n
ao
autorizado a esses dados e sistemas pode comprometer o funcionamento
da instituicao, causar danos financeiros ou perdas de fatias do mercado
para o concorrente. Exemplo: Dados pessoais de clientes e funcion arios,
senhas, informac oes sobre vulnerabilidades de seguranca dos sistemas in-
stitucionais, contratos, balancos entre outros.
Secretas O acesso interno ou externo de pessoas n ao autorizadas a este tipo

de informac
ao e extremamente crtico para a instituic imprescindvel
ao. E
que o numero de pessoas autorizadas seja muito restrito e o controle so-
bre o uso dessas informac oes seja total. Exemplo: Informac oes dos con-
tribuintes, declarac
oes de imposto de renda.
378
Captulo 45
Seguranca Fsica e L
ogica
45.1 Seguranca Fsica

A seguranca fsica consiste em proteger informacoes atraves do uso de controles
de acesso n
ao permitindo que elas sejam prejudicadas atraves da presenca in-
devida de pessoas e de cat astrofes naturais. Os controles de acesso podem ser
divididos em controles fsicos, tecnicos e administrativos.
Controle fsico Envolve os controles de acessos convencionais como guardas,
iluminacao, detectores de movimento etc.
Controle t
ecnico Envolve crach
as de acesso e dispositivos biometricos.
Controle administrativo Envolve procedimentos de emergencia, controle de
pessoal (tanto na contratac
ao quanto na demiss
ao), planejamento e im-
plementac
ao de polticas.
Em relac
ao ao ambiente, devem ser considerados os aspectos relacionados ao
fornecimento de energia eletrica, umidade e supress
ao de incendio. Nesse caso,
todos os tipos de controles de acesso acima s
ao possveis.
45.2 Seguranca L
ogica
Envolve os mecanismos de controle de acesso. Os controles de acessos s ao pro-
jetos para mitigar vulnerabilidades associadas ao acesso.
Define-se sujeito (subject) como sendo a representac ao do usuario dentro do
sistema. O objeto (object) representa o recurso computacional cujo acesso e

controlado. Operac oes s
ao realizadas pelos sujeitos do sistema sob seus objetos.
Uma permiss ao e a manifestac
ao de que uma determinada operac ao e permitida
para um determinado objeto; por exemplo: permiss ao de leitura do arquivo da
fila de impress
ao.
45.2.1 Matrizes de acesso, listas de controle de acesso e

capabilities
A matriz de acesso e organizada com colunas representando os objetos, e
os usu
arios em linhas. Em cada celula da tabela representam-se as permiss
oes
379
que o respectivo usu ario possui sobre o objeto. Um exemplo e a convenc ao do

UNIX, em que a letra R representa permiss ao de leitura, a letra W representa
permiss ao de escrita e a letra X representa permiss ao de execuc
ao.
Matrizes de acesso podem ser utilizadas para modelar mecanismos de au-
torizac
ao simples. Mas n ao sao recomendados para implementac ao, j
a que n ao
escalam bem: um sistema com 50.000 usu arios e 300 arquivos precisaria de
uma matriz com 15 milh oes de celulas, gerando problemas de espaco e maior
possibilidade de erros na administrac ao.
Lista de controle de acesso e uma maneira de simplificar o gerencia-
mento das permiss oes de acesso, pois indexam a matriz de controle de acesso
pela coluna, indicando que usu arios possuem que permiss ao para cada objeto.
Esta lista de controle de acesso e armazenada junto com cada objeto e rela-
ciona quais permiss oes cada usu ario possui naquele objeto. Listas de controle
de acesso (ACLs) s ao extensamente utilizadas em praticamente todos os sis-
temas operacionais modernos (UNIX, Windows), alem de estarem presentes em
dispositivos de rede como roteadores e firewalls.
A outra maneira de gerenciar a matriz de acesso e indexando-a pelos usu arios,
apontando para cada um suas permiss oes no sistema, sendo conhecida como ca-
pabilities.
ACLs s ao simples de implementar, mas difceis de manter em ambientes de
alta rotatividade de usu arios ou arquivos, ja que e necess
ario configura-los para
cada objeto. O agrupamento de usu arios ajuda, mas n ao resolve a quest ao.
Como as ACLs s ao indexadas pelo objeto a ser protegido, e mais custoso saber
exatamente que usu arios tem acesso a que arquivos do sistema. As vantagens
e desvantagens do uso de capabilities s ao basicamente o contr ario das mesmas
de listas de controle de acesso. A implementac ao de capabilities tende a ser um
pouco mais eficiente em sistemas operacionais, enquanto e mais difcil saber que
usuarios tem acesso a um arquivo, j a que a informac ao est
a espalhada.
Listas de controle de acesso tem gozado de uma popularidade muito maior
no mundo comercial de sistemas operacionais que capabilities. Isso se deve ao
fato de que o modelo DAC (Discretionary Access Control) e o mais popular nos
sistemas operacionais modernos, e ACLs adequam-se bem a este modelo, por
facilitar que cada usu ario gerencie as permiss oes de seus objetos no sistema.
45.2.2 Modelos de Controle de Acesso

Modelos de controle de acesso (ou, rigorosamente, modelos de autorizac ao de
acesso) definem caractersticas primitivas de um determinado conjunto de regras
de autorizac
ao a serem utilizadas. Essas caractersticas influenciam os limites da
semantica de autorizac
ao que pode ser expressa no modelo e conseq uentemente a
sua implementac ao. Os principais modelos de controle de acesso hoje s ao DAC
(Discretionary Access Control), MAC (Mandatory Access Control) e RBAC
(Role-Based Access Control).
DAC: Discretionary Access Control

Controle de acesso discrecion
ario tem sua origem no contexto de pesquisa academica
em sistemas de tempo compartilhado que surgiram no comeco dos anos setenta.
DAC e baseado na noc ao de que usu arios individuais s
ao donos de objetos e
380
portanto tem controle (discrec ao) total em quem deve ter permiss oes para aces-
sar o objeto. Um usu ario transforma-se em dono do objeto ao cri a-lo. No
modelo discrecion ario, se Joao e dono de um objeto (um arquivo, por exem-
plo), ela pode conceder a Jose a permiss ao de acess
a-lo em um modo qualquer
de operacao. Posteriormente, ele pode revogar essa permiss ao a qualquer mo-
mento. O princpio b asico de DAC e possess ao do objeto pelo usuario que o
criou.
Atualmente, o DAC e o modelo mais popular de controle de acesso, pela
sua utilizac
ao em grande escala em sistemas operacionais comerciais. Todas
as variantes do UNIX, o Netware e a serie Windows NT, 2000 e XP utilizam
o modelo DAC como seu modelo b asico de controle de acesso. Estes sistemas
operacionais utilizam extensamente a tecnica de listas de controle de acesso para
conceber a implementar as suas checagens de autorizac ao, dispondo tambem do
conceito de grupos de usu arios para facilitar na administrac
ao e concessao de
permissoes.
MAC: Mandatory Access Control

Enquanto o ponto-chave do DAC e o fato de que os usu arios s
ao considerados
donos do objeto e portanto respons aveis pelas suas permiss oes de acesso, o
modelo mandat orio preve que usuarios individuais n ao tem escolha em relac
ao
a que permiss oes de acesso eles possuem ou a que objetos podem acessar.
Neste modelo, os usu arios individuais nao sao considerados donos dos obje-
tos, e nao podem definir suas permiss oes, isso e realizado pelos administradores
do sistema.
O modelo MAC e conhecido, a tal ponto de ser as vezes confundido, pela sua
utilizac
ao em polticas de acesso multinvel, em que se deseja controlar o fluxo
de informacoes em um sistema. Em geral, se quer garantir que a informac ao
s
o flua em um determinado sentido: por exemplo, de nveis mais baixos de
confidencialidade para nveis maiores de confidencialidade, nunca de nveis mais
altos para nveis mais baixos.
DAC e MAC na atualidade

Tanto os modelos DAC e MAC s ao utilizados atualmente, o DAC em maior
escala, estando presente em diversos sistemas operacionais comerciais como o
UNIX, Windows e Netware. Implementac oes de sistemas MAC s ao comuns em
ambientes militares e de mainframe.
Apesar da sua popularidade, eles apresentam problemas pr oprios que est
ao
possibilitando o crescimento de outro modelo de acesso, o RBAC a crescer,

visando resolver estas questoes.
O MAC, apesar de ser reconhecido genericamente como mais control avel e
potencialmente mais seguro que DAC n ao tem obtido grande uso fora dos cir-
cuitos militares. Isso se deve principalmente pela dificuldade em adaptar fluxos
de negocio e hierarquia comerciais ao modelo formal. E impratico implanta-lo
em sistemas que n ao sejam militares, pelo custo de administrac
ao e de overhead
que seria gerado.
O DAC, por sua vez, goza de grande popularidade no mundo comercial,
mas tem em seu maior problema a quest ao da dificuldade no gerenciamento
das permissoes. Sistemas operacionais modernos de rede possuem milhares de
381
usuarios e potencialmente milh oes de arquivos espalhados pelos seus sistemas.

O gerenciamento das permiss oes de cada um destes objetos em uma escala como
esta nao e um problema simples de se resolver, j a que cada objeto possui sua
pr
opria informac
ao de acesso individual.
Por exemplo, quando um usu ario e removido do sistema, costuma ser necess ario
remover suas informac oes de acesso a todos os objetos em que possua o acesso.
Da mesma forma, quando um objeto novo e criado, e necess ario definir as suas
permissoes. Em grandes sistemas computacionais multi-usu ario, essas questoes
pesam bastante.
Uma outra desvantagem tanto do MAC quanto do DAC e que e complicado
estender suas regras de acesso para incluir mecanismos de protec ao e excec
oes
que acontecem normalmente em sistemas. Como exemplo, toma-se o caso de
um sistema hospitalar. Expressar a seguinte regra em sistemas com MAC ou
DAC tradicionais e difcil: Na maior parte do tempo, cada medico s o tem acesso
aos dados dos seus pacientes. Quando estiver no seu turno na UTI, ele ter a
tambem acesso aos pacientes que est ao internados na UTI. Ao acabar seu turno,
perde este acesso adicional. A complexidade de se expressar esse tipo de com-
portamento faz com que acabe-se configurando os sistemas com protec oes mais
relaxadas do que o estritamente necess ario.
RBAC: Role-Based Access Control

RBAC foi projetado para gerenciar centralmente privilegios ao prover uma ca-
mada de abstrac ao, conhecida como role (papel), mais alinhado ` a estrutura
da organizac ao. A nocao central de RBAC e que permiss oes s
ao associadas ` a
papeis, e usuarios s
ao associados aos seus papeis corretos na organizac ao. Isso
simplifica bastante a administrac ao e gerenciamento de permiss oes de acesso
em grandes organizac oes. Papeis sao criados para as v arias func
oes de neg ocio
da organizacao, e os usu arios s
ao associados a esses papeis de acordo com suas
responsabilidades e qualificacoes. Usu arios podem ser facilmente reassociados
de um papel para outro. Papeis podem receber novas permiss oes de acesso ` a
medida que novas aplicac oes ou funcionalidades s ao adicionadas ao sistema, e
permiss oes podem ser revogadas sempre que necess ario.
Um papel e apropriadamente entendido como uma construc ao sem antica `
a
volta do qual a poltica de controle de acesso e formulada. A colec ao particular
de usu arios e permiss oes associadas a um papel e transit oria. O papel e mais
est
avel porque as atividades e func oes da organizac
ao em geral mudam menos
do que o conjunto de usu arios ou de permissoes.
Isso torna a administrac ao de um sistema RBAC muito mais f acil e escal
avel
do que a de um sistema DAC, por exemplo, que precisa associar usu arios a
objetos diretamente, sem a construc ao do papel entre os dois, atuando como
componente estabilizador.
Alem do forte motivo de facilitar o gerenciamento das permiss oes de acesso,
um outro ponto motivador de RBAC e a sua flexibilidade de adaptac ao a regras
de acesso particulares de cada sistema, atraves do recurso de constraints. Con-
straints sao predicados que, aplicados a relacoes e func
oes do modelo, retornam
um valor aceito ou n ao aceito. Isso permite expressar, na poltica de acesso
do sistema, restricoes como a separac ao de deveres, em que um mesmo usu ario
nao pode subverter a seguranca do sistema ao exercer dois papeis conflitantes
ao mesmo tempo. Por exemplo, um mesmo usu ario nao poderia ser ao mesmo
382
tempo o gerente de compras (que toma a decis ao de realizar uma compra), e

o gerente financeiro (que passa o cheque da compra), j a que isso poderia abrir
espaco para fraudes em que ele indicaria uma compra fraudulenta e autorizaria
a sua fatura por conta pr opria. A separac
ao de deveres e um princpio cl assico
de seguranca, utilizado extensamente no mundo dos neg ocios, e e possvel de ser
expressado como regra de acesso em sistemas RBAC.
383
Captulo 46
Backup de Dados
Existem v
arias formas de se garantir a disponibilidade da informac ao, a mais
importante e a c
opia destes dados em local seguro, ou seja, o backup de dados.
Os backups podem ser classificados em tres tipos:
Backup total Realiza uma c opia de todos os dados para a mdia, n

ao impor-
tando o conteudo do ultimo backup. seja, o atributo de arquivamento
e desmarcado ou redefinido. Uma fita atualizada de backup total pode
ser usada para restaurar um servidor completamente em um determinado
momento.
Backup incremental Salva os arquivos que foram alterados desde o u ltimo

backup. Neste processo o novo arquivo e armazenado na mdia e o arquivo
original n
ao e removido da mdia. No processo de restaurac
ao devemos
ter o u
ltimo backup completo e dos os backups incrementais desde ent ao.
Backup diferencial Copia todos os arquivos que foram alterados desde o
u
ltimo backup completo, por este motivo ocupa mais espaco nas mdias de
backup e e mais lento de ser gerado, contudo e mais f
acil de recuper
a-lo.
Para restaurar os dados a partir deste tipo de backup deve-se ter em maos
apenas o u
ltimo backup completo e o u ltimo backup diferencial.
Backup delta S o faz a c

opia dos dados reais que foram modificados nos ar-
quivos, e um processo de backup mais rapido e que ocupa menos espaco
nas mdias de backup, contudo o processo de restaurac
ao e mais lento e
complexo.
46.1 Meios de Armazenamento

Definida as necessidades b asicas a serem atendidas devemos selecionar um do
tipos de armazenamento, que podem ser: on-line, Pr oximos e off-line.
As mdias de armazenamento on-line consistem em discos rgidos ou ar-
rays de discos. Estas mdias fornecem uma disponibilidade em tempo real e s ao
normalmente utilizados para fornecer uma forma altrnativa de armazenamento.
Estas mdias n
ao substituem os backups offline.
O armazenamento pr oximo e formado por Jukeboxes oticos e copias lo-
cais, que est
ao rapidamente acessveis, normalmente fazem uso de rob os para
384
gerenciarem as mdias fornecendo um acesso r apido aos dados quando o servico

on-line n ao est
a disponvel.
J
a o armazenamento off-line consiste no arquivamento de mdias fora da
rede de dados em um local seguro e protegido contra roubo, cat astrofes naturais
e outros amecas. Sempre que possvel as mdias devem ser armazenadas em local
geogr aficamente diferente e fora das instalac oes comerciais da empresa.
Para a realizac
ao deste tipos de backup podem ser utilizadas tres tipos de
mdias diferentes: fitas/discos magneticos, armazenamento otico e arrays de
disco.
As fitas magn eticas s ao as mdias mais comuns, mais baratas utilizadas
nos backups off-line, mas por outro lado s ao as mais lentas e que ocupam um
grande espaco. Seus principais tipos s ao: 8mm, Travan, DLT, DAT e Magstar.
O armazenamento otico e muito popular em ambientes onde a velocidade
e a confiabilidade s ao as maiores preocupac oes, estes ambientes fazem uso de
servidores com jukeboxes oticos de alta disponibilidade que s ao soluc
oes caras
porem muito eficientes.
Os arrays de discos ou simplesmente RAIDs (Redundant Array of Inde-
pendet Disks) s ao um subsistema de discos rgidos que melhoram o desempenho
e a toler ancia a falhas, uma vez que os dados s ao gravados em mais de um
disco ao mesmo tempo. Estas soluc oes podem ser tanto implementadas em
software quanto em hardware. Neste caso quando uma unidade de disco falha
o administrador do sistema pode substitu-la, em alguns casos, sem parar o
funcionamento do servidor.
A soluc
ao de RAID fornece um melhor desempenho e toler ancia a falhas,
mas de forma alguma substitui o processo de backup off-line. Vale lembrar que
dois ou mais discos podem falhar ao mesmo tempo, perdendo o acesso total aos
dados armazenados no array.
Outra soluc
ao de protecao aos dados e o HSM (Hierarchical Storage Manage-
ment), que e um sistema automatizado para o gerenciamento de dados e espaco
em disco, muito utilizado em mainframes. Esta soluc ao monitora a capacidade
das unidades e move os dados para as mdias de armazenamento pr oximo ou
offline, mais lentas.
O HSM pode mover os dados segundo sua idade, freq uencia de uso ou
baseado em outros criterios, permitindo deste modo uma migrac ao de dados
autom atica. Esta soluc
ao e relativamente cara e difcil de ser implementada.
385
Captulo 47
Vrus e Ataques
Conceito b
asicos:
Cracker Termo usado para designar quem quebra um sistema de seguranca,
de forma ilegal ou sem etica. Este termo foi criado em 1985 pelos hackers
em defesa contra o uso jornalstico do termo hacker.
Hacker Habitualmente (e erradamente) confundido com cracker, um hacker e
um expert ou Problem Solver, aquele que apresenta soluc
oes para proble-
mas tecnicos relativos `
a Internet.
White Hat (aka hacker etico) Hacker em seguranca, utiliza os seus conheci-
mentos na explorac
ao e detecc
ao de erros de concepc
ao, dentro da lei.
Black Hat (aka cracker ou dark-side hacker) criminoso ou malicioso hacker,
um cracker.
Gray hat Tem as habilidades e intencoes de um hacker de chapeu branco na
maioria dos casos, mas por vezes utiliza seu conhecimento para prop
ositos
menos nobres.
Script Kiddie Antigamente chamado de Lammer, e um indivduo que n ao
tem domnio dos conhecimentos de programac ao. E pouco experiente,
com poucas nocoes de informatica, porem tenta fazer-se passar por um
cracker a fim de obter fama, o que acaba gerando antipatia por parte dos
hackers verdadeiros.
Newbie Newbie, Noob ou a sigla NB, e aquele jovem aprendiz de hacker que
possui uma sede de conhecimento incrivel, pergunta muito e e ignorado e

ridicularizado na maioria das vezes, ao contrario dos lammers nao tenta
se por acima dos outros.
Phreaker Hacker especialista em telefonia m
ovel ou fixa.
um programa capaz de infectar outros programas e arquivos de um
Vrus E
computador. Para realizar a infeccao, o vrus embute uma c opia de si
mesmo em um programa ou arquivo, que quando executado tambem ex-
ecuta o vrus, dando continuidade ao processo de infecc
ao. Para que um
computador seja infectado por um vrus, e preciso que de alguma maneira
um programa previamente infectado seja executado.
386
Worms E um programa completo capaz de se propagar automaticamente atraves

de redes, enviando c
opias de si mesmo de computador para computador.
Sua propagac
ao se d
a atraves da explorac
ao de vulnerabilidades existentes
ou falhas na configurac
ao de softwares instalados em computadores. O
worm pode trazer embutido programas que geram algum tipo de prob-
lema ou que tornam o computador infectado vulner avel a outros ataques.
Um worm pode provocar danos apenas com o tr afego de rede gerado pela
sua reproduc
ao.
Cavalos de Tr oia (Trojan) E um programa que alem de executar func oes

para as quais foi aparentemente projetado, executa tambem outras func oes
normalmente maliciosas e sem o conhecimento do usu ario como: alteracao
ou destruic
ao de arquivos; furto de senhas e n
umeros de cartoes de credito;
inclus
ao de backdoors. N ao se replica, n
ao infecta outros arquivos, ou
propaga c opias de si mesmo automaticamente. Necessita ser explicita-
mente executado. Exemplos comuns de cavalos de tr oia s
ao programas
que voce recebe ou obtem de um site e que dizem ser jogos ou protetores
de tela.
Traps S
ao como backdoors. Garantir uma forma de retornar a um computador
comprometido, sem precisar recorrer aos metodos utilizados na realizac
ao
da invas
ao. A forma usual de inclusao de um backdoor consiste na adicao
de um novo servico ou substituic
ao de um determinado servico por uma
vers
ao alterada, normalmente incluindo recursos que permitam acesso re-
moto (atraves da Internet).
Spyware/Adware Spyware (Software Espi ao) e Adware (Publicidade n ao de-
sejada). Spyware s ao arquivos ou aplicativos que s ao instalados em seu
computador, algumas vezes sem seu consentimento ou autorizac ao, ou
mesmo depois que voce aceita as Condic oes de Uso. Os Spyware moni-
toram e capturam informac oes das atividades dos usu arios, as enviando
para servidores onde sao armazenadas para fins em geral comerciais. Tais
informacoes ser
ao posteriormente vendidas a provedores de produtos e
servicos como maillings. Estes provedores utilizam-se destas informac oes
para difundir informacoes na forma de spam. Podem ser maliciosos, in-
cluindo programas que capturam as informac oes de tudo o que e digitado
no teclado. Adware, semelhante aos spyware, s ao aplicativos instalados da
mesma forma que no caso anterior, fazendo com que banners publicit arios
de servicos e produtos aparecem na sua telinha.
DoS/DDoS O objetivo de tais ataques e indisponibilizar o uso de um ou mais

computadores, e n ao invadi-los. Nos ataques de negac
ao de servico (DoS -
Denial of Service) o atacante utiliza um computador para tirar de operac ao
um servico ou computador conectado ` a Internet. No DDoS (Distributed
Denial of Service) constitui um ataque de negacao de servico distribudo,
ou seja, um conjunto de computadores e utilizado para tirar de operac ao
um ou mais servicos ou computadores conectados ` a Internet. Normal-
mente estes ataques procuram ocupar toda a banda disponvel para o
acesso a um computador ou rede, causando grande lentid ao ou ate mesmo
indisponibilizando qualquer comunicac ao com este computador ou rede.
387
IP Spoofing O IP spoofing consiste na troca do IP original por um outro,

podendo assim se passar por um outro host. A pessoa que ir a realizar o
spoofing tem ent ao dois problemas na verdade: o de alterar o ip origem,
mais simples de resolver, e o de manter a seq uencia de n
umeros, que
por serem geradas arbitrariamente, complica em muito esta tarefa. As
seq
uencias de n
umeros s ao geradas no TCP para a comunicacao entre os
hosts.
Flooding O TCP Flood SYN attack tira vantagem do comportamento do 3 way

handshake efetuado pelo protocolo TCP no processo de uma conex ao. O
attacker faz um pedido de conex ao para o servidor da vitima com pacotes
que carregam o endereco falsificado de IP da fonte (metodo IP spoofing).
Como resultado o servidor da vitima perde tempo e recursos de mequina
que poderiam estar sendo usados para outros processos. O UDP Flood
attack simplesmente envia pacotes de UDP randomicamente para todas as
portas do servidor da vitima. Ping Flood attack e uma tecnica de attack
que tenta saturar uma conex ao de Internet atraves do envio continuo de
uma serie de pings originados tipicamente em redes de alta velocidade
para redes de baixa velocidade.
Alem dos mecanismo mais tradicionais de infecc ao tais como setor de boot,
macros e mem oria, tres vetores tambem se destacam: correio eletr
onico, compar-
tilhamento de arquivos e falhas no sistema operacional. Curiosamente enquanto
os vrus antigos faziam uso de mecanismos extremamente complexos para se
infectar, hoje em dia v arios dos vermes e vrus fazem uso dos proprios recursos
do sistema operacional.
47.1 Estrat
egias de combate `
a pragas eletr
onicas
A estrategia de mais longo prazo e a prevenc ao. Usu arios, suporte e admin-
istradores devem ser alertados para os riscos de vrus de computador e mecanis-
mos eficazes, em acordo com a poltica de seguranca, que deve ser colocada em
pratica.
As tarefas mais comuns que devem ser realizadas s ao a an alise e remoc
ao de
compartilhamento de redes Microsoft, an alise e atualizac
ao do sistema opera-
cional e analise e atualizac
ao do sistema de antivrus do usu ario.
Campanhas de conscientizac ao tambem sao importantes, os usu arios devem
ser alertados sobre os perigos existentes em determinadas ac oes, como baixar
arquivos execut aveis por e-mail.
No caso em que uma reac ao e necess

aria, n
ao basta somente remover a praga
eletronica. E importante registrar o incidente e analisar qual fato levou ` a in-
fecc
ao e tomar as medidas cabveis para a remoc ao da vulnerabilidade. Tambem
e importante que esquipes de resposta ` a emergencia sejam criadas dentro da es-
trutura do org
ao.
47.1.1 Antivrus
Todos os antivrus agem de forma semelhante. Existem dois metodos b asicos
usados para combater vrus. O primeiro consiste em manter nos antivrus um
grande banco de dados onde ficam registradas todas as assinaturas (parte do
388
vrus que o caracteriza) de vrus conhecidos. Da a importancia de manter seu

antivrus atualizado, pois a cada dia surgem centenas de novos vrus. Assim,
quando procuramos vrus no sistema, na verdade, o que estamos fazendo e
comparar cada arquivo nosso com a assinatura dos vrus registrados.
A segunda forma de protec ao e conhecida como inoculacao, que nada mais
e que a criacao de um banco de dados contendo as principais informac oes
(tamanho, data de criac ao e data da ultima alterac ao) sobre os arquivos in-
oculados. Assim, cada vez que procuramos por vrus no sistema, o programa
antivrus compara as informac oes do banco de dados criado com as que est ao
no disco. Se houver alguma diferenca e emitido um alerta. Mas note que n ao e
qualquer arquivo que deve ser inoculado, uma vez que arquivos de dados sempre
s
ao alterados. Os arquivos execut aveis, DLLs e arquivos de sistema s ao exemp-
los de arquivos que devem ser inoculados, pois s ao as principais vtimas de vrus
e nao mudam seu conte udo com freq uencia.
389
Captulo 48
Princpios de Criptografia
Em um processo de comunicac ao, uma mensagem pode ser definida como um

conjunto de informac
oes que um remetente deseja enviar para um ou mais des-
tinatarios. O processo de modificar uma mensagem de forma esconder seu
conteudo e chamado encriptacao. A ciencia que estuda a encriptacao e de-
criptac
ao de mensagens e chamada Criptografia. No incio, a criptografia era
utilizada com o u
nico intuito de garantir confidencialidade. Somente as pessoas
que conhecessem o processo de criptografia utilizada poderiam ler a mensagem.
Atualmente, a criptografia e utilizada para prover tambem as seguintes garan-
tias:
Autenticac
ao: Provar a identidade dos participantes em um processo de
comunicacao;
Integridade: Permitir que o receptor verifique se a mensagem n
ao foi al-
terada ou corrompida ao longo do caminho;
Incontestabilidade: Impedir que um remetente negue o envio de uma men-
sagem. A incontestabilidade tambem e chamada n ao-rep
udio. Em outras
palavras, e possvel provar para um terceiro que uma mensagem so pode
ter sido gerada por um remetente especfico.
Um algoritmo de criptografia e uma func ao matem atica utilizada para en-
criptar e decriptar uma mensagem. Inicialmente, o segredo da comunicac ao era
baseado no segredo do algoritmo de criptografia, de forma que para que duas se
comunicassem de forma segura, ambas precisavam conhecer o algoritmo. Nos
sistemas criptograficos atuais o segredo de comunicac
ao e baseado no segredo de
uma chave de criptografia. A chave de criptografia e passada como par ametro

para o algoritmo pra que esse possa criptografar ou descriptografar uma men-
sagem. Neste modelo, o algoritmo de criptografia e p ublico, e somente aqueles
que conhecem a chave de criptografia utilizada para encriptar uma mensagem
s
ao capazes de decript a-la.
O conjunto de valores que uma chave pode assumir e chamado espaco de

chaves (keyspace). Na Internet, por exemplo, atualmente s
ao utilizadas chaves
com comprimento de ate 4096 bits, o que permite escolher uma chave em um
conjunto de 24096 elementos. Portanto, utilizando uma chave com esse com-
primento seria possvel criptografar uma mensagem de 24096 formas diferentes
390
utilizando o mesmo algoritmo.
48.1 Tipos de Criptografia

As tecnicas de criptografia sao divididas em tres tipos principais que sao: (i)
Func
oes Hash; (ii) Criptografia Simetrica e (iii) Criptografia Assimetrica. O
tipo de garantia (autenticac
ao, integridade, nao-rep
udio e confiabilidade) que se
deseja no processo de comunicac ao e o que determina qual o tipo de criptografia
que se deve utilizar. Os tipos de criptografia sao descritos a seguir:
Funcoes Hash: Func

oes matem aticas que transformam um texto em uma
sequencia de caracteres de tamanho fixo (128, 160, 512 bits, por exemplo)
independente do tamanho do texto. A sequencia de caracteres geradas e
conhecida como resumo da mensagem (message digest). A seguranca das
func
oes hash se baseiam no fato delas serem func oes s
o de ida. A sada
do processo de uma func ao hash n ao e dependente da entrada de uma
forma clara, o que na pr atica torna impossvel alterar uma mensagem de
modo que o mesmo hash seja gerado e mensagem continue fazendo sentido.
Boas funcoes hash tambem devem garantir que seja computacionalmente
impossvel gerar a mensagem original a partir de seu hash;
Criptografia Simetrica: E composto por uma chave e um algoritmo que
pode ser executado no modo de encriptac ao, para cifrar uma mensagem,
ou decriptacao, para decifr a-la. A chave utilizada nos processos de en-
criptac
ao e decriptac
ao e a mesma e deve ser mantida em segredo entre as
partes comunicantes. Os algoritmos de criptografia simetrica geralmente
s
ao baseados em operac oes de shift e XOR, o que permite que sejam ex-
tremamente eficientes e de f acil implementac
ao em hardware;
Criptografia Assimetrica: E composto por um algoritmo e um par de

chaves p ublica e privada geralmente denotadas por K + e K respecti-
vamente. Uma mensagem cifrada com a chave K + s o pode ser decifrada
com a chave K e vice-versa. Dessa forma, se Bob deseja garantir que sua
mensagem s o podera ser lida por Alice, ent
ao ele deve cifrar a mensagem
com a chave p ublica de dela. Como Alice e, em tese, a unica detentora de
sua chave privada, ela ser aau nica capaz de decifrar a mensagem enviada
por Bob. Dessa maneira pode-se garantir a confidencialidade da men-
sagem. Repare que nem mesmo Bob ser a capaz de decifrar a mensagem.
Bob pode ainda cifrar uma mensagem com sua pr opria chave privada e
enviar para Alice. Nesse caso, para decifrar a mensagem Alice dever a uti-
lizar a chave p ublica de Bob. Dessa forma, Alice poderia garantir que foi
realmente Bob quem enviou a mensagem e n ao um impostor. Algoritmos
de criptografia assimetrica geralmente s ao baseados em operac oes de fa-
torac
ao, exponenciac ao e logaritmos de grandes n umeros, o que os torna
muito mais lentos do que os algoritmos simetricos. A criptografia de chave
assimetrica e a base do sistema de criptografia de chave p ublica, que ser
a
discutido mais adiante;
391
48.2 Algoritmos de Criptografia Sim

etricos
Tres exemplos de cifras (metodo de criptografia) do tipo chave simetrica s
ao:
Cifra de C
esar cada letra do texto cifrado recebe a letra do texto aberto mais
uma constante, com rotac
ao no alfabeto.
Cifra Monoalfab etica Cada letra do texto aberto e substituda por uma outra
u
nica letra.
Cifra Polialfabetica Usa-se v arias cifras de Cesar para se levar em consid-

erac
ao a posic
ao da letra no texto. Ou seja, a constante de Cesar se
modifica em funcao da posic
ao da letra no texto aberto.
Os algoritmos simetricos utilizados na pr
atica s
ao:
DES (Data Encryption Standard) O DES utiliza uma chave de 56 bits e

opera em blocos de 64 bits de mensagem. Foi projetado inicialmente para
ser utilizado em componentes de hardware, nos dias atuais, ele e usado na
Internet em conex oes Web segura, pois o SSL se utiliza do DES. Ele e um
algoritmo seguro para a maioria das aplicacoes, entretanto, em aplicac oes
altamente secretas, ele n
ao deve ser usado, pois existe o perigo de violac
ao.
3DES Sao usados 3 estagios e duas chaves. No primeiro estagio, o texto sim-
ples e criptografado com chave K1 da maneira usual do DES. No segundo
estagio, o DES e executado no modo de descriptografia, com o uso de
uma chave K2. Por fim, outra criptografia e feita com a chave K1. S ao
utilizadas 2 chaves porque os criptografos concordam que 112 bits ser
ao su-
ficientes para aplicac
oes comerciais durante um tempo. O uso de 168 bits
s
o criaria overhead desnecess ario de gerenciar e transportar outra chave,
com pouco ganho real. Ao utilizar dessa maneira (criptografia, descrip-
tografia, criptografia), um computador que utiliza a criptografia tripla
pode se comunicar com outro que utiliza a criptografia simples apenas
definindo k1=k2.
RC2 e RC4 Mais r apidos do que o DES, esses codigos podem se tornar mais
seguros com o simples aumento do tamanho das chaves, O RC2 pode
substituir perfeitamente o DES com a vantagem de ser 2 vezes mais rapido,
j
a o RC4 fica 10 vezes mais r
apido. Algumas chaves s
ao fracas. Suas chaves
s
ao de 1 a 2048 bits.
IDEA (International Data Encryption Algorithm) Criado em 1991. Ele

foi projetado para ser facilmente programado, e forte e resistente a muitas
formas de criptoanalise. Possui chave de 128 bits, porem e patenteado.
AES (Advanced Encryption Standard) Foi promovido em um concurso
um novo padr ao cujas propostas eram: 1 - O algoritmo teria de ser uma
cifra de bloco simetrica; 2 - Todo o projeto teria de ser publico; 3 - Dev-
eriam ser admitidos tamanhos de chaves iguais a 128, 192 e 256 bits; 4 -
Teriam de ser possveis implementacoes de software e de hardware; 5 - O al-
goritmo teria de ser publico ou licenciado em termos n ao-discriminatorios.
Os finalistas: 1 - Rijndael; 2 - Serpent; 3 - Twofish; 4 - RC6; 5 - MARS.
392
Cifra Autor Comprimento Coment

arios
da chave
Blowfish Bruce Schneier 1 a 448 bits Velho e lento
DES IBM 56 bits Muito fraco para usar agora
IDEA Massey e Xuejia 128 bits Bom, mas patenteado
RC4 Ronald Rivest 1 a 2048 bits Algumas chaves sao fracas
RC5 Ronald Rivest 128 a 256 bits Bom, mas patenteado
Rijndael Daemen e Rijmen 128 a 256 bits Melhor escolha
Serpent Anderson, Biham, 128 a 256 bits Muito forte
Knudsen
3DES IBM 168 bits Segunda melhor escolha
Twofish Bruce Schneier 128 a 256 bits Muito forte; amplamente utilizado
Tabela 48.1: Alguns algoritmos criptogr

aficos de chave simetrica
48.3 Algoritmos de Criptografia Assim

etricos
A criptografia de chave p
ublica ou criptografia assimetrica, foi criada em 1970.
Esse metodo funciona com uma chave para criptografar, e outra para descrip-
tografar a mesma mensagem.No sistema de chave p ublica, cada pessoa tem que
ter duas chaves, uma que fica publicamente disponvel, e outra, que deve ser
mantida em segredo. O algoritmo que se mantem ate hoje e o RSA, que e paten-
teado pela RSADSI (RSA Data Security Incorporated) nos Estados Unidos.
Para entender como funciona, observe abaixo:
As pessoas (A) e (C), escrevem mensagens, utilizando a chave p

ublica da
pessoa (B), note que, a partir desse momento somente ela, podera ler as
mensagens;
As mensagens s
ao enviadas a pessoa (B) atraves da Internet;
A pessoa (B), recebe as mensagens de (A) e (C), na qual ela usa a chave
privada para descriptografar;
A pessoa (B), le as mensagens, e se, tiver que responde-las, dever
a usar
as chaves p
ublicas de criptografia de (A) e ou (C).
Nesse momento, e importante enfatizar que o sigilo da chave privada e muito

importante, pois, a criptografia assimetrica, se baseia no fato de que a chave
privada, e realmente privada, por isso, somente seu detentor deve ter acesso. A
descric
ao do algoritmo mais utilizado segue abaixo:
RSA (Rivest, Shamir, Adleman) O metodo se baseia em alguns princpios

da teoria dos n
umeros. De forma resumida:
Escolha dois n
umeros primos extensos, p e q (geralmente, de 1024
bits)
Calcule n = p x q e z = (p-1) x (q-1)
Escolha um n
umero d tal que z e d sejam primos entre si
Encontre e de forma que e x d = 1 mod z
393
Com esses par ametros calculados com antecedencia, estamos prontos para
comecar a criptografia. Divida o texto simples (considerado um string de bits)
em blocos, de modo que cada mensagem de texto simples P fique no intervalo
0 <= P < n. Isso pode ser feito agrupando-se o texto simples em blocos de k
bits, onde k e o maior inteiro para o qual a desigualdade 2k < n e verdadeira.
Para criptografar a mensagem P, calcule C = P e(modn). Para descrip-
tografar C, calcule P = Cd(modn). E possvel provar que, para todo P na faixa
especificada, as func
oes de criptografia e descriptografia sao inversas entre si.
Portanto, a chave p ublica consiste no par (e,n) e a chave privada consiste em
(d,n).
Lento demais para codificar grande volume de dados, mas amplamente uti-
lizado para a distribuic
ao de chaves. A seguranca do sistema est a baseado na
dificuldade de fatorar numeros grandes.
48.4 T
ecnicas de Quebra de Criptografia
Basicamente, os tres tipos de ataque destinado `
a quebra de criptografia s
ao:
Ataque Exclusivo a Texto Cifrado N ao se conhece o texto aberto. An alise
estatstica geralmente e utilizada para se extrair algo do texto cifrado.
Ataque com Texto Aberto Conhecido Se conhece o texto cifrado e pelo

menos parte do texto aberto. A descoberta da chave fica menos complexa
em relac
ao ao caso anterior.
Ataque com Texto Aberto Escolhido E possvel escolher o texto aberto a
ser encriptografado. Desta forma, a descoberta da chave fica mais facili-
tada.
394
Captulo 49
Autenticac
ao
49.1 Autenticac
ao de Mensagens
Autenticac ao de mensagens e um mecanismo ou servico utilizado para verificar
a integridade de uma mensagem. Os metodos mais comuns s ao MAC (message
autentication code) e funcoes hashes seguras. O MAC requer o uso de chave
secreta e e produzido atraves do uso dessa chave em uma mensagem de tamanho
vari
avel. Uma func ao hash mapeia uma mensagem de tamanho vari avel em um
hash de tamanho fixo e para garantir o n ao-rep
udio e utilizado em conjunto com
uma chave privada.
Quando o metodo de autenticac ao garante o nao rep udio, ent
ao trata-se de
uma assinatura digital. O MAC n ao prove assinatura digital, uma vez que o
remetente e o receptor compartilham a mesma chave.
As funcoes hash sao utilizadas para a geracao de sum arios de mensagens
message digests. Com os sumarios de mensagens e possvel fornecer autenticac ao
sem que haja sigilo e tem quatro propriedades:
1. Se a mensagem e fornecida, o c
alculo de seu sum
ario e f
acil.
2. Se o sum
ario e fornecido, ser
a impossvel encontrar a mensagem original.
3. Dada uma mensagem, ninguem pode encontrar uma mensagem diferente

com o mesmo sum
ario que ela.
4. Uma mudanca de um bit na mensagem produz dr

asticas mudancas no
sum
ario.
As func
oes de hash mais utilizadas s
ao o MD5 e o SHA-1. O sum
ario gerado
pelo MD5 possui 128 bits e e um melhoramento do MD4. J a o SHA-1 trabalha
com hash de 160 bits. O SHA-1 foi considerado o sucessor do MD5. Ambos
tem vulnerabilidades comprovadas. Em algumas correntes, e sugerido que o
SHA-256 ou superior seja usado para tecnologia crtica.
O MAC mais utilizado e o HMAC, que e utilizado no IPSec. O HMAC se
baseia em algoritmos de hash como o SHA-1 e o MD5.
395
49.2 Protocolos de Autentica

cao
A autenticac
ao e a tecnica atraves de qual um processo confirma que seu parceiro
na comunicacao e quem deve ser e n ao um impostor.
49.2.1 M
etodos de Autenticac
ao
A autenticac
ao pode ser feita com a combinac
ao de um ou mais dos itens abaixo:
Algo que voce saiba, um n

umero de identificac
ao pessoal ou uma senha
(autenticac
ao tipo 1).
Algo que voce tenha, um cart ao de banco ou um cart ao com chip (aut-
enticac
ao tipo 2). Em alguns casos, esses dispositivos geram senhas auto-
maticamente e s ao conhecidos como tokens.
Algo que voce e, impress
ao digital ou escaneamento de retina (autenticac
ao
tipo 3). Os par ametros de desempenho mais importantes em um sistema
de biometria s ao: FRR (False Rejection Rate), FAR(False Acceptance
Rate), tempo de registro, tempo de atendimento e aceitabilidade (n ao
invasivo).
49.2.2 Autenticac
ao baseada em uma chave secreta com-
partilhada
Para efetuar uma autenticac ao baseada em uma chave secreta compartilhada, e
necess
ario que Alice e Bob estabelecam essa chave (Kab ).
Os protocolos de autenticac ao baseada em uma chave secreta e baseada
no princpio do desafio-resposta (challenge-response), onde o emissor envia um
n
umero aleat orio para o receptor (nonce); quando este recebe a mensagem,
transforma o n umero recebido em uma forma especial e o retorna ao emissor.
Uma brecha que n ao deve existir no protocolo e a possibilidade de ataque
por reflex
ao, em que uma pessoa no meio da comunicac ao recebe um desafio. A
pessoa indesejada cria outra conex ao para obter a resposta para aquele desafio,
assim, utiliza a resposta para o sucesso da autenticacao anterior.
Outras propriedades importantes para os protocolos dessa classe s ao:
O transmissor deve provar sua identidade antes que o receptor responda;

As pessoas envolvidas no processo devem utilizar chaves especficas provando
suas identidades, mesmo que haja necessidade de existir duas chaves com-

partilhadas Kab e Kab ;
Condicionar para que tanto transmissor quanto receptor extraiam seus

desafios de conjuntos distintos.
Na atualidade ha protocolos baseados no uso de HMACs e na codificac
ao de
itens atraves do encadeamento de blocos de cifras.
396
49.3 Certificado Digital

Um certificado digital, ou identidade digital, pode ser visto como uma carteira
de identidade para uso na internet. Tecnicamente, um certificado digital e um
conjunto de dados (um arquivo), assinado digitalmente pela autoridade certifi-
cadora e contento tipicamente informac oes como: Chave p ublica do certificado;
Nome e endereco de e-mail do dono do certificado; Nome e assinatura digital da
autoridade certificadora; Privilegios de acesso a sites seguros; Outras.
Uma Autoridade Certificadora e uma entidade de confianca que administra
a gestao de certificados digitais atraves da emiss ao, revogac
ao e renovacao dos
mesmos por aprovac ao individual. Uma Autoridade Certificadora pode emitir
diferentes tipos de certificados, atribuindo diferentes nveis de confianca a cada
tipo. Para cada tipo de certificado e utilizado um processo diferente para realizar
a verificac
ao da identidade do solicitante.
O padr ao para descrever certificados e o X.509 (pela ITU). Um modo difer-
ente de certificar chaves p ublicas e o PKI (Public Key Infrastructure). Uma
PKI tem v arios componentes, incluindo usu arios, CAs, entidades de registro,
certificados e diretorios. A func
ao e fornecer um modo de estruturar esses com-
ponentes e definir padr oes para os v arios documentos e protocolos. Uma forma
particularmente simples de PKI e uma hierarquia de CAs.
Um certificado digital e um arquivo de computador que contem um conjunto
de informac oes referentes a entidade para o qual o certificado foi emitido (seja
uma empresa, pessoa fsica ou computador) mais a chave p ublica referente a
chave privada que acredita-se ser de posse unicamente da entidade especificada
no certificado. Um certificado padr ao X.509 contem os seguintes campos:
Vers
ao Contem a vers
ao do certificado X.509, atualmente vers
ao 3
N
umero serial Todo certificado possui um, n
ao e globalmente u
nico, mas
u
nico no ambito de uma AC, ac LCRs usam o serial para apontar quais
certificados se encontram revogados
Tipo de algoritmo Contem um identificador do algoritmo criptogr
afico usado
pela AC para assinar o certificado juntamente com o tipo de func
ao de
hash criptogr
afica usada no certificado
Nome do titular Nome da entidade para o qual o certificado foi emitido
Nome do emitente Autoridade Certificadora que emitiu/assinou o certificado
Perodo de validade Mostra o perodo de validade do certificado no formato
Nao antes e N
ao depois (Ex. Nao antes de 05/03/2006 - 14:35:02, Nao
depois de 05/03/2007 - 14:03:2006 )
Informa
cos de chave p
ublica da entidade Algoritmo de chave p
ublica e
Chave p
ublica.
Assinatura da AC A garantia que a AC prove sobre a veracidade das in-
formac
oes contidas neste certificado de acordo com as polticas da AC
Identificador da chave do titular E uma extensao do X.509 que possui um
identificador numerico para a chave p
ublica contida neste certificado, es-
pecialmente util para que programas de computador possam se referir a
ela
397
Identificador da chave do emitente A mesma ideia mencionada anterior-

mente, s
o que se referindo a chave p
ublica da AC que emitiu o certificado
Atributos ou extens oes A vasta maioria dos certificados X.509 possui cam-
pos chamados extens oes (OID) que proveem algumas informacoes ex-
tras, como cadastros adicionais do titular e do emitente, especificac
oes
de proposito do certificado e etc.
398
Captulo 50
Seguranca em diversas
camadas
50.1 Secure Sockets Layer

Em 1995, a ent ao dominante do mercado de browsers, Netscape, resolveu in-
troduzir um pacote de seguranca chamado Secure Sockets Layer (SSL), para
atender demandas por conex oes mais seguras na internet. O SSL se tornou um
padrao e ate hoje e utilizado para prover conex
oes seguras. O SSL est a posi-
cionado entre a camada de transporte e a camada de aplicac ao da pilha TCP/IP
e funciona provendo servicos de autenticacao do servidor, comunicac
ao secreta
e integridade dos dados.
O SSL pode ser utilizado para prover seguranca na comunicac

ao de qualquer
aplicac
ao baseada em TCP. O uso do SSL com HTTP, geralmente e referenciado
como HTTPS (Secure HTTP ). O HTTPS geralmente utiliza a porta TCP 443,
ao inves da porta 80.
Antes que o cliente e o servidor iniciem a troca de mensagens de forma segura

e necess
ario que se estabeleca uma conex ao SSL seguindo as seguintes epatas:
1. O cliente e o servidor negociam par ametros de conex

ao como vers ao do
protocolo, n
umero da sessao, algoritmos de cifragem, algoritmo de com-
pactac
ao. Eles trocam ainda valores rand omicos (nonce) que ser
ao uti-
lizados no processo de gerac

ao da chave de sess
ao;
2. O cliente solicita o certificado do servidor. Caso o certificado do servidor

esteja assinado por uma CA confi avel, o cliente extrai a chave publica
do servidor e a utiliza para criptografar uma chave pre-mestra antes de
envi
a-la ao servidor. A chave pre-mestra e utilizada em combinac ao com
os valores randomicos trocados na etapa 1 pra gerar a chave simetrica de
sess
ao que sera utilizada na comunicacao;
3. O cliente e o servidor trocam mensagens de controle para sinalizar que

todas as pr
oximas mensagens ser
ao cifradas utilizando a chave de sess
ao
gerada.
399
A partir da etapa 3, todos os dados gerados pela camada de aplicac ao ser

ao
cifrados pelo SSL antes de serem repassados para a camada de transporte. E
importante ressaltar que o SSL nao cifra as informac
oes do cabecalho TCP, mas
somente os dados gerados pela camada de aplicac ao.
50.2 IPSec
A IETF sabia h a muitos anos da carencia de seguranca na Internet. Para au-
menta-la, havia uma disputa para definir onde coloc a-la. Para especialistas, a
seguranca deveria ser colocada no nvel de aplicac ao. A dificuldade com essa
abordagem e que ela exigiria que todas as aplicac oes fossem modificadas afim
de torna-las seguras. Outra abordagem seria colocar a seguranca em um nvel
intermedi ario entre aplicac
ao e transporte, como e feito no SSL. Dessa forma,
as aplicac
oes nao precisariam ser alteradas completamente.
Uma outra vis ao e que os usu arios n

ao conhecem seguranca, e portanto
n
ao seriam capazes de implement a-la corretamente nos nveis de transporte ou
aplicac
ao. A partir desse princpio, IETF introduziu o IPSec.
O IPSec e uma sute de protocolos que foi desenvolvida para proporcionar

autenticacao, confidencialidade e integridade dos dados no nvel de rede. Todos
os servicos oferecidos pelo IPSec s
ao baseados em criptografia de chave simetrica
porque o alto desempenho e importante. E importante ressaltar que o projeto
do IPSec e independente do algoritmo de criptografia utilizado, de modo que a
quebra de um algoritmo n ao represente o fim da utilidade do projeto.
Embora trabalhe na camada IP, o IPSec e orientado a conex oes. Isso se deve
` necessidade do estabelecimento de uma chave de criptografia que ser
a a utilizada
por um determinado perodo. No contexto do IPSec, uma conex ao e chamada
SA (Security Association). Uma SA e uma conex ao unidirecional, de forma
que caso se deseje conex
ao segura em ambos os sentidos, serao necessarias duas
SAs. Para o estabelecimento de chaves, o IPSec utiliza um procolo chamado
IKE (Internet Key Exchange).
O IPSec e baseado na adic

ao de cabecalhos adicionais que podem ser de dois
tipos. O primeiro delese e o AH (Authentication Header ), enquanto o segundo
e o ESP (Encapsulation Security Payload ).
O cabecalho AH e capaz de prover autenticac

ao e checagem de integridade
dos dados por meio do campo HMAC (Hashed Message Authentication Code).
Esse campo contem um hash da mensagem criptografado com a chave estabele-
cida na criac
ao da conex
ao. Nesse modo de operac ao, o IPSec nao e capaz de
oferecer confidencialidade, j
a que os dados em si n
ao sao criptografados.
No modo ESP os dados s ao cifrados garantindo-se tambem a confidencial-

idade na comunicacao. A integridade e a autenticacao dos dados sao obtidos
com o campo HMAC, que tambem est a presente no cabecalho ESP. Com o ESP
e possvel operar de duas formas que s ao conhecidas como modo transporte
e modo tunel. No modo transporte, o cabecalho original do pacote IP n ao e
400
criptografado, e e utilizado para rotea-lo ao longo do caminho. J a no modo

tunel, o pacote IP inteiro e criptografado e inserido dentro de um novo pacote
IP juntamente com o cabecalho ESP. O modo t unel e utilizado, por exemplo,
para implementar VPNs seguras usando IPSec.
Os modos de operacao do IPSec de acordo com o protocolo de extens

ao
utilizado podem ser vistos na figura 50.1.
Figura 50.1: Modos de operac

ao do IPSec
50.3 Virtual Private Network (VPN)

A ideia de utilizar uma rede p ublica como a Internet em vez de linhas pri-
vativas para implementar redes corporativas e denominada de Virtual Private
Network (VPN) ou Rede Privada Virtual. As VPNs s ao t
uneis de criptografia
entre pontos autorizados, criados atraves da Internet ou outras redes p ublicas
e/ou privadas para transferencia de informac oes, de modo seguro, entre redes
corporativas ou usu arios remotos.
A seguranca e a primeira e mais importante func ao da VPN. Uma vez que
dados privados ser ao transmitidos pela Internet, que e um meio de transmiss ao
inseguro, eles devem ser protegidos de forma a n ao permitir que sejam modifi-
cados ou interceptados.
Outro servico oferecido pelas VPNs e a conex ao entre corporacoes (Ex-
tranets) atraves da Internet, alem de possibilitar conex
oes dial-up criptografadas
que podem ser muito u teis para usu arios m
oveis ou remotos, bem como filiais
distantes de uma empresa.

Uma das grandes vantagens decorrentes do uso das VPNs e a reduc ao de
custos com comunicac oes corporativas, pois elimina a necessidade de links ded-
icados de longa dist ancia que podem ser substitudos pela Internet. As LANs
podem, atraves de links dedicados ou discados, conectar-se a algum provedor
de acesso local e interligar-se a outras LANs, possibilitando o fluxo de dados
atraves da Internet. Esta soluc ao pode ser bastante interessante sob o ponto de
vista economico, sobretudo nos casos em que enlaces internacionais ou nacionais
de longa distancia est ao envolvidos. Outro fator que simplifica a operacional-
izac
ao da WAN e que a conex ao LAN-Internet-LAN fica parcialmente a cargo
dos provedores de acesso.
401
Abaixo, s
ao apresentadas as tres aplicac
oes ditas mais importantes para as
VPNs.
ACESSO REMOTO VIA INTERNET
DE LANS VIA INTERNET
CONEXAO
DE COMPUTADORES NUMA INTRANET
CONEXAO
No desenvolvimento de soluc oes de rede, e bastante desej avel que sejam
implementadas facilidades de controle de acesso a informac oes e a recursos cor-
porativos. A VPN deve dispor de recursos para permitir o acesso de clientes
remotos autorizados aos recursos da LAN corporativa, viabilizar a interconex ao
de LANs de forma a possibilitar o acesso de filiais, compartilhando recursos e
informacoes e, finalmente, assegurar privacidade e integridade de dados ao atrav-
essar a Internet bem como a pr opria rede corporativa. A seguir s ao enumeradas
caractersticas mnimas desej aveis numa VPN:
Autenticac ao de Usu arios: Verificac
ao da identidade do usu ario, restringindo
o acesso ` as pessoas autorizadas. Deve dispor de mecanismos de auditoria,
provendo informac oes referentes aos acessos efetuados - quem acessou, o que
e quando foi acessado.
Gerenciamento de Endereco: O endereco do cliente na sua rede privada n ao
deve ser divulgado, devendo-se adotar enderecos fictcios para o tr afego externo.
Criptografia de Dados: Os dados devem trafegar na rede p ublica ou privada
num formato cifrado e, caso sejam interceptados por usu arios nao autoriza-
dos, n ao dever ao ser decodificados, garantindo a privacidade da informac ao.
O reconhecimento do conte udo das mensagens deve ser exclusivo dos usu arios
autorizados.
Gerenciamento de Chaves: O uso de chaves que garantem a seguranca das
mensagens criptografadas deve funcionar como um segredo compartilhado exclu-
sivamente entre as partes envolvidas. O gerenciamento de chaves deve garantir
a troca peri odica das mesmas, visando manter a comunicac ao de forma segura.
Suporte a M ultiplos Protocolos: Com a diversidade de protocolos existentes,
torna-se bastante desej avel que uma VPN suporte protocolos padr ao de fato
usadas nas redes p ublicas, tais como IP (Internet Protocol), IPX (Internetwork
Packet Exchange), etc.
As redes virtuais privadas baseiam-se na tecnologia de tunelamento cuja
existencia e anterior `
as VPNs. Ele pode ser definido como processo de encapsular
um protocolo dentro de outro. O uso do tunelamento nas VPNs incorpora
um novo componente a esta tecnica: antes de encapsular o pacote que ser a
transportado, este e criptografado de forma a ficar ilegvel caso seja interceptado
durante o seu transporte. O pacote criptografado e encapsulado viaja atraves

da Internet ate alcancar seu destino onde e desencapsulado e decriptografado,
retornando ao seu formato original. Uma caracterstica importante e que pacotes
de um determinado protocolo podem ser encapsulados em pacotes de protocolos
diferentes. Por exemplo, pacotes de protocolo IPX podem ser encapsulados e
transportados dentro de pacotes TCP/IP.
O protocolo de tunelamento encapsula o pacote com um cabecalho adicional
que contem informac oes de roteamento que permitem a travessia dos pacotes
ao longo da rede intermedi aria. Os pacotes encapsulados s ao roteados entre as
extremidades do t unel na rede intermedi aria. Tunel e a denominac ao do cam-
inho logico percorrido pelo pacote ao longo da rede intermedi aria Apos alcancar
402
o seu destino na rede intermedi aria, o pacote e desencapsulado e encaminhado

ao seu destino final. A rede intermedi aria por onde o pacote trafegar
a pode ser
qualquer rede p ublica ou privada.
Note que o processo de tunelamento envolve encapsulamento, transmiss ao
ao longo da rede intermedi aria e desencapsulamento do pacote.
Para se estabelecer um t unel e necess
ario que as suas extremidades utilizem
o mesmo protocolo de tunelamento.
O tunelamento pode ocorrer na camada 2 ou 3 (respectivamente enlace e
rede) do modelo de referencia OSI (Open Systems Interconnection).
Tunelamento em Nvel 2 - Enlace - (PPP sobre IP): O objetivo e transportar
protocolos de nvel 3, tais como o IP e IPX na Internet. Os protocolos utilizam
quadros como unidade de troca, encapsulando os pacotes da camada 3 (como
IP/IPX) em quadros PPP (Point-to-Point Protocol). Como exemplos, podemos
citar:
PPTP (Point-to-Point Tunneling Protocol) da Microsoft permite que o

tr
afego IP, IPX e NetBEUI sejam criptografados e encapsulados para
serem enviados atraves de redes IP privadas ou p
ublicas como a Inter-
net.
L2TP (Layer 2 Tunneling Protocol) da IETF (Internet Engineering Task

Force) permite que o trafego IP, IPX e NetBEUI sejam criptografados e
enviados atraves de canais de comunicac
ao de datagrama ponto a ponto
tais como IP, X25, Frame Relay ou ATM.
L2F (Layer 2 Forwarding) da Cisco e utilizada para VPNs discadas.
Tunelamento em Nvel 3 - Rede - (IP sobre IP): Encapsulam pacotes IP com

um cabecalho adicional deste mesmo protocolo antes de envi a-los atraves da
rede.
O IP Security Tunnel Mode (IPSec) da IETF permite que pacotes IP sejam
criptografados e encapsulados com cabecalho adicional deste mesmo protocolo
para serem transportados numa rede IP p ublica ou privada. O IPSec e um
protocolo desenvolvido para IPv6, devendo, no futuro, se constituir como padr ao
para todas as formas de VPN caso o IPv6 venha de fato substituir o IPv4. O
IPSec sofreu adaptac
oes possibilitando, tambem, a sua utilizac
ao com o IPv4.
50.4 Filtragem de Pacotes e Firewalls

Filtragem de pacotes e o bloqueio ou liberac

ao da passagem de pacotes de dados
de maneira seletiva, conforme eles atravessam a interface de rede. Em sistemas
Linux, por exemplo, a filtragem de pacotes e implementada diretamente no ker-
nel. Esses filtros inspecionam os pacotes com base nos cabecalhos de transporte,
rede ou ate mesmo enlace. Os criterios mais utilizados s ao os enderecos IP e
portas TCP/UDP de origem e destino.
Alguns filtros de pacotes tambem s ao capazes de transformar o conte udo dos

pacotes, como e o caso do netfilter do Linux. Normalmente ` as pessoas se referem
ao filtro de pacotes do Linux pelo nome de iptables. Na verdade, o iptables e
uma utilitario de linha de comando a partir do qual podem ser configuradas as
403
regras de filtragem do netfilter.
O netfilter e formado por um conjunto de cadeias. Cada cadeia e um ponto

no caminho que um pacote IP percorre ao entrar ou sair de uma m aquina. A
figura 50.2 mostra as cadeias do netfilter.
Figura 50.2: Estrutura do netfilter
A cadeia PREROUTING est a ligada à entrada de pacotes na m aquina.

Ap os a decis
ao de roteamento, os pacotes que n ao s
ao destinados `
a maquina
local atravessam a cadeia FORWARD e finalmente saem da m aquina passando
pela cadeia POSTROUTING. A cadeia INPUT e atravessada pelos pacotes que
chegam com destino ` a maquina local, enquanto que a cadeia OUTPUT e uti-
lizada pelos pacotes originados localmente.
Para filtrar ou transformar pacotes IP, o netfilter possui estruturas chamadas

tabelas. Cada tabela possui regras, que por sua vez se fazem referencia a uma
cadeia. As tabelas padr ao do netfilter mais utilizadas sao a filter, para imple-
mentac
ao de um firewall, e a tabela nat, utilizada para fazer NAT.
As regras podem ser criadas pelo administrador de acordo com o que de-
seja implementar, por exemplo, um firewall ou NAT. Cada regra especifica um
padr ao ou criterio a ser comparado com os pacotes e um alvo. Um alvo e uma
ac
ao pre-definida a ser tomada quando um pacote casa com a regra. Os alvos
mais comuns s ao:
ACCEPT: deixa o pacote passar;

DROP: impede que o pacote siga adiante;
REJECT: impede que o pacote siga adiante e envia uma mensagem ICMP
ao sistema de origem;
MASQUERADE: mascara os pacotes como se eles tivessem sido originados
pela m
aquina local. Utilizado para implementac
ao de NAT.
Um firewall pode ser configurado seguindo uma postura permissiva ou restri-

tiva. Uma configurac
ao permissiva permite tudo o que n ao for exeplicitamente
negado, enquanto uma configurac ao restritiva nega tudo o que n ao for exmplici-
tamente permitido. A postura padr ao de um firewall e conhecida como policy. A
seguir s
ao mostrados alguns exemplos de regras de firewall utilizando a sintaxe
404
do iptables.
50.4.1 Regras iptables - Exemplo 1

1. Pela interface ppp0, e permitido o tr
afego de entrada com origem 172.16.100.200
e destino 192.168.130.0/24.
iptables -i ppp0 -A FORWARD -s 172.16.100.200

-d 192.168.130.0/24 -j ACCEPT
2. Pela interface ppp0, e permitido o tr

afego de sada com origem 192.168.130.0/24
e destino 172.16.100.200.
iptables -o ppp0 -A FORWARD -s 192.168.130.0/24

-d 172.16.100.200 -j ACCEPT
3. Pela interface ppp0, tr

afego de entrada, e negada toda e qualquer outra
origem e outro destino. Loga este bloqueio.
iptables -i ppp0 -A FORWARD -j DROP --log
4. Pela interface ppp0, trafego de sada, e negada toda e qualquer outra

iptables -o ppp0 -A FORWARD -j DROP --log
50.4.2 Regras iptables - Exemplo 2

1. Pela interface ppp0, permite a sada de pacotes com destino a porta
TCP 23 de qualquer sistema remoto desde que a porta TCP de origem
seja maior ou igual a 1024.
iptables -o ppp0 -A FORWARD -p tcp -s 192.168.10.0/24 -d 0/0
--sport 1024:65535 --dport 23 -j ACCEPT
2. Pela interface ppp0, permite respostas aos pacotes aceitos na re-

gra anterior, desde que os pacotes n ao tenham o flag SYN setado.
Isso significa dizer que n
ao e possvel iniciar que um host externo
inicie o processos de abertura de conex ao TCP com hosts da rede
192.168.10.0/24 nas portas acima de 1023.
iptables -i ppp0 -A FORWARD -p tcp -s 0/0 -d 192.168.10.0/24
--sport 23 --dport 1024:65535 ! -syn -j ACCEPT
405

afego de entrada, e negada toda e qualquer
outra origem e outro destino. Loga este bloqueio.
iptables -i ppp0 -A FORWARD -j DROP --log

afego de sada, e negada toda e qualquer outra
iptables -o ppp0 -A FORWARD -j DROP --log
50.4.3 Firewall Stateful

Um firewall de filtro de pacotes e dito um firewall sem estado. Isso porque ele
trata cada um dos pacotes que atravessam a interface de forma independente.
Na segunda sequencia de regras, por exemplo, foram necess arias duas regras
para garantir que os hosts da rede 192.168.10.0/24 pudessem acessar a porta
TCP 23 de um outro host qualquer. Cada uma das regras tratava os pacotes em
um determinado sentido. Em uma conex ao TCP, sempre existe fluxo de dados
em ambos os sentidos entre origem e destino.
As conex oes TCP sao caracterizadas por uma serie de atributos como IPs
de origem e destino, portas de origem de destino, n
umeros de sequencia etc. Em
conjunto, esses atributos determinam o estado de uma conex ao TCP.
Ao contrario dos firewalls de filtro de pacotes, um firewal stateful n

ao filtra
pacotes de forma isolada, mas sim com base em informac oes sobre o estado
de conex oes pre-estabelecidas. Para um firewall stateful, a comunicac ao bidi-
recional e implcita, de forma que n ao h
a necessidade de se escrever regras de
filtragem para cada um dos sentidos. A seguir s ao mostrados alguns exemplos
de ragras para um firewall stateful utilizando a sintaxe do iptables.
1. Permite abertura de conex oes TCP com origem na rede 10.0.0.0/24 e porta
acima de 1023 para qualquer outro host na porta TCP 80. O detalhe e
que, alem de controlar quem tem o direito de abertura da conex
ao, a regra
tambem cuida de todos os pacotes trocados em ambos os sentidos ate o
fim conexao.
iptables -A FORWARD -s 10.0.0.0/24 -d 0/0 -p tcp --sport

1024:65535 --dport 80:80 -m state --state NEW -j ACCEPT
Na verdade, seria necess

ario uma outra regra para permitir o controle do
fluxo de pacotes em ambos os sentidos. A regra e a seguinte:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Essa regra aceita os pacotes que atravessam a cadeia FORWARD desde

que eles pertencam a alguma conex
ao TCP que esteja no estado ESTAB-
LISHED ou RELATED. No entanto, essa regra e v alida para todos os
406
pacotes que atravessam a cadeia FORWARD, e n

ao somente para os pa-
cotes definidos na regra 1.
Alguns firewalls s
ao capazes de implementar o conceito de estados para co-
municacoes baseadas em UDP. Geralmente, isso e alcancado utilizando-se
um temporizador. Dessa forma, os pacotes UDP trasmitidos em ambos os
sentidos entre uma origem e um destino s ao tratados como uma conex ao
pelo perodo de tempo definido pelo timeout.
50.4.4 Application Gateway

Embora os firewalls de filtro de pacotes e statefull apresentem uma diferencas
em como pacotes de uma determinada conex ao s
ao tratados, ambos se baseiam
fundamentalmente nas informac oes do cabecalho dos protocolos da camada de
transporte.
Um application gateway e um firewall stateful capaz de inspecionar os dados

da camada de aplicac ao para tomar decisoes mais inteligentes sobre a conexao.
Exemplos de controles realizados por um application gateway s ao autenticac
ao,
filtros de URL e filtros de conte
udo.
Um application gateway pode ser utilizado para bloquear, por exemplo,

aplicac
oes peer to peer (eMule, Kaaza etc.), ou mensageiros instant
aneos (IRC,
MSN etc.) que tentam se esconder debaixo do protocolo HTTP. No entanto,
os application gateway n ao s
ao capazes de inspecionar dados criptografados via
SSL, por exemplo.
50.4.5 Arquitetura de firewall e DMZ

A arquitetura de implementac ao do firewall tambem e um fator de an alise im-
portante. Por arquitetura de implementac ao entende-se a posic ao relativa que
o firewall possui em relacao a`s redes protegidas, aos recursos de conex ao e às
redes externas.
A analise da arquitetura de implementac ao de firewalls traz os conceito de
Bastion Host e DMZ, que precisam ser explicados: Bastion Hosts s ao servidores
cuidadosamente implementados e de alta seguranca que mantem contato com a
rede externa, conseq uentemente estando expostos aos riscos de ataques. DMZs
s
ao areas intermediarias entre a rede interna e externa onde os servidores que
recebem tr afego externo estao hospedados de maneira separada da rede interna
de uma corporac ao.
a) Dual Homed Host - s ao Bastion hosts nos quais o firewall e implementado,
expondo sua interface externa e desativando o roteamento entre as interfaces
externas e as interfaces internas. Assim, conex oes externas chegariam ate o
Bastion host apenas, e conex oes internas teriam que obrigatoriamente passar
pelo Bastion Host. Como mostra a figura abaixo, entre a internet e um Dual
Homed host, poderia ser implementado um conjunto de filtros de pacotes, no
roteador mais pr oximo, por exemplo, para diminuir as possibilidades de ataques,
407
diminuindo a necessidade de filtros de pacotes no proprio bastion host. Esta ar-

quitetura gera um ponto focal na rede, com vantagens e desvantagens: O tr afego
centralizado permite uma administrac ao focalizada em um u nico host, porem o
excesso de tr
afego em um u nico host pode causar condic oes de concorrencia e
caso o bastion host seja tomado por um invasor, toda a rede estar a vulner avel
a ataques.
`
Figura 50.3: Arquitetura Dual Homed Host
b) Screened Host - conforme a figura abaixo, essa arquitetura apresenta uma

conex ao externa com ligacao apenas a um host interno, que e um bastion host.
Este host estaria conectado ` a rede interna, e n
ao entre as redes, e o firewall teria
que ser implementado no roteador, poremhaveria pacotes externos entrando na
rede local. Apesar de ser aparentemente menos segurodo que os dual homed
hosts, este tipo de arquitetura permite o acesso aos servicos do bastion host
sem causar condic oes de concorrencia na rede, uma vez que todo o trabalho de
filtragem e analise de tr
afego ocorre no roteador.
Figura 50.4: Arquitetura Screened Host
c) Screened Subnet - adicionam mais uma camada ` a seguranca de redes

atraves da utilizac
ao de DMZ para hospedagem dos bastion hosts e de um
firewall adicional que separa a rede interna da DMZ. Em uma screened subnet
408
um firewall separa a rede externa da DMZ que hospeda os servicos que podem
ser acessados pela rede externa, como por exemplo, um servidor de correio
corporativo. Dentro da DMZ est a tambem o bastion host que contem o firewall
que da acesso da rede interna ` a DMZ e roteia as requisicoes da rede interna
para o roteador da DMZ. Esta arquitetura de screened subnets permite maior
seguranca a uma rede, uma vez que as tentativas de invas ao ser
ao efetuadas
contra bastion hosts que n ao possuem acesso ` a rede interna, e que o bastion
host de sada da rede e protegido por filtros de entrada no roteador externo.
50.5 Sistemas de Detec

c
ao de Intrus
ao (IDS)
Deteccao de intrus ao e uma tentativa de monitorar estac oes ou fluxos de rede
com o intuito de descobrir ac oes de intrusos. Mais especificamente, um SDI
tenta detectar ataques ou usos impr oprios e alerta o respons avel pela rede do
acontecimento. O funcionamento e an alogo ao de um sistema de detecc ao de
ladr
oes, usado em casas para se proteger de eventuais incidentes. O sistema
domiciliar inicialmente precisa ser configurado e ter especificado o que monitorar
(janelas, portas, movimento) e para quem alertar ou chamar em caso de uma
invasao (polcia, donos da casa). No sistema computacional, tambem precisamos
determinar se queremos monitorar fluxos de rede, processos internos de uma
estac
ao ou servidor, ou ainda um sistema de arquivos, por exemplo. E devemos
deixar claro para quem enviar os alarmes ou relat orios e como estes devem ser
enviados, tendo como alternativas o e-mail, pager, ou ainda um pacote SNMP.
Teoricamente, esse tipo de sistema seria somente passivo, observando pacotes
na rede ou processos em uma estac ao de trabalho e alertando os respons aveis.
Porem, alguns sistemas possuem a habilidade de reagir ` as invasoes, deixando
de ser um sistema exclusivamente de detecc ao e pode ser definido como um
Sistema de Prevenc ao de Intrus ao (IPS). Exemplos de reac oes podem ser um
fechamento de conex ao, um bloqueio no firewall, execucao de algum arquivo, ou
ainda a desabilitac ao de uma conta.
Os sistemas de detecc ao de intrus
ao servem, como j a foi dito, para indicar
que alguma tentativa de intrus ao foi feita no sistema. Para isso, existem dois
tipos diferentes de detecc ao que podem ser empregados, os baseados na rede
e os baseados na estac ao. Cada um tem uma maneira distinta de abordar
o problema e o modo como isso e feito traz vantagens e desvantagens para
cada tipo. Resumidamente, podemos dizer que os sistemas baseados na estac ao
monitoram dados em uma determinada m aquina, sejam eles processos, sistemas
de arquivos e o uso de CPU, por exemplo; enquanto que os sistemas baseados
na rede observam todos os dados trocados entre estac oes.
50.6 Seguranca em Redes Wireless 802.11

50.6.1 WEP
Desde sua primeira vers ao, o padr
ao IEEE 802.11 tentou oferecer um mecanismo
de seguranca Esse mecanismo e chamado WEP (Wired Equivalent Privacy) e
se baseia em criptografia de chave simetrica. O proceso de autenticacao entre
um host sem fio e um ponto de acesso (AP) funciona da seguinte maneira. O
host solicita autenticac
ao ao AP, que por sua vez envia um nonce de 128 bits ao
409
host. O host cifra o nonce com uma chave simetrica pre-compartilhada e envia
de volta ao AP, que decifra o nonce e autentica o host. A partir da, o host
pode iniciar a transmiss
ao dos dados de fato.
No entanto, o WEP n ao preve nenhum mecanismo de distribuic ao de chaves

e nao possui autenticac
ao individual. Isso significa dizer que todos os hosts sem
fio utilizam a mesma chave simetrica para se autenticar no AP. Alem disso, o
processo de cifragem WEP 802.11 ainda apresenta outras falhas graves.
No WEP, cada um dos frames tansmitidos e criptografado com o algortimo

RC4, que utiliza uma chave de 64 bits para gerar um fluxo de chaves de tamanho
1 byte (KiIV ). Cada chave do fluxo gerado e utilizada para cifrar um byte de um
frame enviado fazendo um XOR. A gerac ao do fluxo de chaves e determinstica,
ou seja, uma chave de 64 bits sempre gera a mesma sequencia de chaves de um
byte.
Como foi dito, os hosts sem fio e o AP possuem uma chave pre-compartilhada.
Essa chave possui comprimento de 40 bits. Os outros 24 bits necess arios para
formar a chave de 64 bits do RC4 s ao gerados dinamicamente a cada frame
trasmitido. Esses 24 bits s ao chamados vetor de inicializac ao (IV). O IV e
transmitido em texto aberto no mesmo frame que carrega os dados cifrados.
Alem disse, os IVs eventualmente precisam ser reutilizados, j a que seu range e
de apenas 224 . Dessa forma, ao detectar a reutilizacao um IV, o atacante pode
fazer com que um transmissor cifre os dados conhecidos. Ao receber os dados
cifrados, o atacante poder a calcular a sequencia KiIV . Da proxima vez que IV
for reutilizado, o atacante poder a decifrar os dados utilizando a sequencia.
50.7 802.11i
O padr ao 802.11i, tambem conhecido como WAP, prop oe mecanismos de segu-
ranca para redes 802.11 mais avancados que o WEP. O WAP preve formas de
cifragem mais fortes, autenticac
ao individual, e a utilizac
ao de um servidor de
autenticac
ao (AS) separado do AP. O processo de asociac ao entre uma estac
ao
cliente (STA) e um AP no padr ao 802.11i segue as seguintes etapas:
1. Descoberta das capacitac

oes de seguranca entre o STA e AP;
2. STA e AS se autenticam mutuamente. Juntos geram chave mestra (MK).

O AP serve como passagem, permitindo a passagem de pacotes especficos;
3. STA e AS derivam uma chave PMK (Pairwise Master Key). O AS envia

a chave PMK para o AP. A partit da, o STA e o AS j
a conhecem a mesma
chave PMK;
4. STA e AP derivam uma nova chave tempor aria TK (Temporal Key) a
partir de PMK. A chave TK ser
a utilizada para cifragem e integridade
das mensagens.
Por ser formado por 4 etapas principais, o processo de autenticac

ao definido
no padr
ao 802.11i e conhecido como four-way handshake.
410
Parte IX
Alta Disponibilidade
411
Captulo 51
Soluc
oes de
Armazenamento RAID,
SAN e NAS
51.1 RAID
Tal como em diversas outras areas, quando n ao e possvel aumentar o desem-
penho de um componente, uma soluc ao possvel passa pelo uso de m ultiplos
componentes em paralelo. No caso do armazenamento, isto leva ao desenvolvi-
mento de conjuntos de discos que operam independentemente e em paralelo.
Com v arios discos, pedidos de I/O podem ser tratados em paralelo, desde que
os dados residam em discos separados. Do mesmo modo, um u nico pedido de
I/O pode ser tratado de igual modo em paralelo caso os dados se encontrem
distribudos ao longo de diversos discos.
Com o uso de v arios discos, torna-se claro que existem muitos modos de
organizar os dados e nos quais a redund ancia pode ser adicionada para aumentar
a confiabilidade. O esquema RAID (Redundant Array of Independent Disks)
puro consiste em 7 nveis (de zero a seis). N ao ha qualquer relac
ao hier
arquica
entre eles, mas cada um deles designa arquiteturas distintas que partilham 3
caractersticas diferentes.
O conjunto dos discos fsicos em RAID e visto pelo sistema operacional

como sendo um unico drive logica
Os dados s
ao distribudos pelos drives fsicos de um array.
Redundancia de capacidade e usada para armazenar informac
ao de pari-
dade, que garante a recuperacao dos dados no caso de uma falha num
disco.
51.1.1 RAID 0
Este nvel RAID refere-se a um array de discos onde os dados est
ao divididos em
faixas, mas nao existe nenhuma redund ancia para toler
ancia a falhas. Sempre
que a performance e a capacidade forem a preocupac ao principal e o baixo
412
custo for mais importante que a confiabilidade adicional, esta e uma opc ao a
considerar. A figura 51.1 exemplifica o tipo de estrutura existente num sistema
deste tipo.
Figura 51.1: RAID 0
Os dados sao subdivididos em segmentos consecutivos (stripes) que s

ao es-
critos seq
uencialmente atraves de cada um dos discos de um array. Cada seg-
mento tem um tamanho definido em blocos. O striping oferece um melhor
desempenho, quando comparado a um disco individual, se o tamanho de cada
segmento for ajustado de acordo com a aplicac
ao que utilizar
a o array.
Em um ambiente com uso intensivo de E/S ou em um ambiente de banco

de dados onde m ultiplas requisic
oes concorrentes s
ao feitas para pequenos
registros de dados, um segmento de tamanho grande e preferencial. Se o
tamanho de segmento para um disco e grande o suficiente para conter um
registro inteiro, os discos do arranjo podem responder independentemente
para as requisicoes simultaneas de dados.
Em um ambiente onde grandes registros de dados s ao armazenados, seg-
mentos de pequeno tamanho s ao mais apropriados. Se um determinado
registro de dados extende-se atraves de v
arios discos do arranjo, o conte
udo
do registro pode ser lido em paralelo, aumentando o desempenho total do
sistema.
Na verdade, a distribuic
ao dos dados nos drives n ao e completamente uni-
forme. Os arquivos s ao divididos em fragmentos de tamanho configur avel (chunk
size, ou stripe size). Assim, se est
a sendo usado 3 HDs em RAID 0, utilizando
fragmentos de 32 KB, por exemplo, ao gravar um arquivo de 80 KB teramos
fragmentos de 32 KB gravados nos dois primeiros HDs e os 16 KB finais se-
riam gravados no terceiro, sendo que os 16 KB que sobraramno terceiro HD
ficariam como espaco desperdicado.
Arranjos RAID-0 podem oferecer alta performance de escrita se comparados
a verdadeiros nveis de RAID por n ao apresentarem sobrecarga associada com
calculos de paridade ou com tecnicas de recuperac ao de dados. Esta mesma

falta de previsao para reconstrucao de dados perdidos indica que esse tipo de
arranjo deve ser restrito ao armazenamento de dados n ao crticos e combinado
com eficientes programas de backup.
Entretanto, cabe ressaltar alguns pontos negativos desta implementac ao no
que tange confiabilidade e desempenho. RAID 0 n ao ter
a o desempenho desejado
com sistemas operacionais que n ao oferecem suporte de busca combinada de
setores. Os resultados ser ao corretos, porem nao havera paralelismo e nenhum
ganho de desempenho. Outra desvantagem desta organizac ao e que a confianca
se torna potencialmente pior. Um disco SLED com um tempo medio de vida de
20.000 horas ser a 4 vezes mais seguro do que 4 discos funcionando em paralelo
413
com RAID 0 (Admitindo-se que a capacidade de armazenamento somada dos

quatro discos for igual ao do disco SLED). Como n ao existe redundancia, n
ao
h
a muita confiabilidade neste tipo de organizac
ao. Por fim, RAID 0 e um nome
ate certo ponto equivocado, pois nao h
a redund ancia, ele n
ao se encontra na
taxonomia original de nveis de RAID, e a aplicac ao de faixas e anterior ao
RAID.
51.1.2 RAID 1
Esse esquema tradicional para toler ancia a falhas de disco, chamado espel-
hamento (mirroring) ou sombreamento, utiliza o dobro da quantidade de discos
do RAID 0. Formalmente, para esta implementac ao s
ao necess
arios no mnimo
dois discos. O funcionamento deste nvel e simples: todos os dados s
ao gravados
em dois discos diferentes; se um disco falhar ou for removido, os dados preser-
vados no outro disco permitem a n ao descontinuidade da operac ao do sistema.
A figura 51.2 apresenta este esquema.
Figura 51.2: RAID 1
Apesar de muitas implementac oes de RAID 1 envolverem dois grupos de

dados (da o termo espelho ou mirror), tres ou mais grupos podem ser criados
se a alta confiabilidade for desejada. O RAID 1 e o que oferece maior seguranca,
pois toda informac ao e guardada simultaneamente em dois ou mais discos. Se
ocorrer uma falha num dos discos do array, o sistema pode continuar a trabalhar
sem interrupcoes, utilizando o disco que ficou operacional. Os dados entao sao
reconstrudos num disco de reposic ao (spare disk) usando dados do(s) disco(s)
sobrevivente(s). O processo de reconstruc ao do espelho tem algum impacto
sobre o desempenho de I/O do array, pois todos os dados ter ao de ser lidos e
copiados do(s) disco(s) intacto(s) para o disco de reposic
ao.
Alguns pontos em relac ao ao desempenho deste tipo de esquema sao descritos
abaixo:
Um pedido de leitura pode ser satisfeito por qualquer um dos dois discos
que contenha os dados em questao, podendo ser escolhido o que implicar
um tempo menor de procura e latencia de rotac
ao.
Um pedido de escrita requer uma atualizac ao em ambos os discos, mas isto

pode ser feito em paralelo. Deste modo, a performance de escrita e ditada
pela mais lenta das duas faixas fsicas. Em outros nveis RAID em que
s
ao utilizados outros esquemas de redund ancia, quando uma u nica faixa
e atualizada e necess
ario calcular e atualizar bits de paridade provocando
um aumento no tempo necess ario para fazer uma escrita no disco. Em
RAID 1, este write penalty e inexistente.
A recuperac ao de uma falha e simples. Quando ocorre uma falha num dos
discos, e sempre possvel aceder aos dados utilizando o outro disco.
414
Conectando os discos prim

arios e os discos espelhados em controladoras
separadas, pode-se aumentar a toler
ancia a falhas pela eliminac
ao da con-
troladora como ponto u
nico de falha.
Num ambiente de transac oes, RAID 1 consegue satisfazer altas taxas de

pedidos I/O se a maioria dos pedidos forem leituras, onde se consegue aproximar
do dobro do desempenho conseguido por RAID 0. No entanto, sempre que uma
frac
ao substancial dos pedidos forem escritas, pode n ao haver superioridade de
desempenho relativamente a RAID 0.
Entre os n
ao-hbridos, este nvel tem o maior custo de armazenamento, pois
serao utilizados dois discos para a mesma informac ao. Este nvel adapta-se mel-
hor em pequenas bases de dados ou sistemas de pequena escala que necessitem
confiabilidade.
51.1.3 RAID 2
Raramente s ao usados, e em algum momento ficaram obsoletos pelas novas
tecnologias de disco. RAID-2 e similar ao RAID-4, mas armazena informac ao
ECC (error correcting code), que e a informac
ao de controle de erros, no lugar da
paridade. Isto ofereceu pequena protec ao adicional, visto que todas as unidades
de disco mais novas incorporaram ECC internamente. RAID 2 pode oferecer
maior consistencia dos dados se houver queda de energia durante a escrita.
Baterias de seguranca e um desligamento correto, porem, podem oferecer os
mesmos benefcios. As figuras 51.3 e 51.4 ilustram o esquema RAID 2 bem
como a forma em que as operacoes de leitura e escrita s ao realizadas.
Figura 51.3: RAID 2

Figura 51.4: Operac

oes de leitura e escrita em RAID 2
Em RAID 2 o ECC e calculado sobre os bits em posicoes an

alogas em cada
disco. Os bits do c odigo s
ao armazenados nas posicoes correspondentes em
multiplos discos de paridade. Normalmente e utilizado o c
odigo de Hamming
415
que torna possvel a correc

ao de erros de um bit e a detecc
ao de erros de dois
bits. Apesar de requerer menos discos que RAID 1 e ainda bastante caro. O
numero de discos redundantes e proporcional ao logaritmo do n umero de discos
de dados.
Numa leitura u nica, todos os discos s ao acessados simultaneamente. Os
dados e o codigo corretor associado sao entregues ao controlador do array. Se
existir um erro de um s o bit, o controlador consegue reconhecer e corrigi-lo
instantaneamente. Do mesmo modo, numa escrita, todos os discos de dados e
paridade devem ser acessados.
Esta pode ser uma opcao em ambientes em que existe uma alta probabilidade
de ocorrencia de erros. No entanto, dada a alta confiabilidade dos discos atuais,
normalmente n ao se implementa este esquema RAID.
51.1.4 RAID 3
Assim como RAID 2, raramente s ao usados, e e semelhante ao RAID 4, exceto
por usar o menor tamanho possvel para a stripe. Como resultado, qualquer
pedido de leitura invocar a todos os discos, tornando a execucao de requisic
oes
diferentes em paralelo difceis ou impossveis. A fim de evitar o atraso devido
a latencia rotacional, o RAID-3 exige que todos os eixos das unidades de disco
estejam sincronizados. A maioria das unidades de disco mais recentes n ao pos-
suem a habilidade de sincronizac ao do eixo, ou se sao capazes disto, faltam os
conectores necess arios, cabos e documentac ao do fabricante.
Figura 51.5: RAID 3

Figura 51.6: Operac

oes de leitura e escrita em RAID 3
Outra diferenca em relac

ao ao RAID 2 e que RAID 3 requer apenas um disco
redundante, qualquer que seja o tamanho do array de discos.
RAID 3 aplica acesso paralelo, com os dados distribudos em pequenas faixas.
Em vez de um codigo corretor de erros, um simples bit de paridade e calculado
416
para o conjunto de bits na mesma posic ao em todos os discos e armazenado

no disco redundante referido. De uma forma simplificada, pode-se pensar no
disco redundante como contendo a soma de todos os dados nos outros discos.
Quando ocorre uma falha, subtraem-se todos os dados nos discos bons pelos
dados contidos no disco de paridade. A informac
ao restante ter
a inevitavelmente
de ser a informac
ao que falta. Por exemplo, o c
alculo desta para o n-esimo bit
para um array de quatro discos ser a:
X3(n) = X2(n) xor X1(n) xor X0(n) (51.1)

Supondo que ocorre uma avaria no disco X0, adicionando X3 xor X0 a ambos
os lados da equac
ao obtemos:
X0 = X3(n) xor X2(n) xor X1(n) (51.2)

Este princpio e verdadeiro para cada os sistemas RAID de nvel 3 a 6. Dado
que os dados se encontram em faixas de tamanho bastante reduzido, em RAID
3 e possvel atingir altas taxas de transferencia de dados. Qualquer pedido I/O
implicar a a transferencia paralela de dados de todos os discos. Este aumento de
desempenho e mais visvel em grandes transferencias. Por outro lado, apenas
um pedido de I/O pode ser executado de cada vez, portanto n ao constituir
aa
melhor opc ao para um ambiente de transac oes.
51.1.5 RAID 4
Tal como nos outros sistemas RAID, s ao usadas faixas, mas no caso das imple-
mentac
oes RAID de 4 a 6, estas faixas sao relativamente grandes. Em RAID 4,
uma faixa de paridade e calculada bit a bit para faixas correspondentes em cada
disco de dados. Os bits de paridade s ao armazenados no disco redundante. Ao
contr
ario do sistema de RAID 3 que armazena a paridade bit-a-bit, em RAID
4 a paridade e armazenada sob a forma de blocos e associada a um conjunto de
blocos de dados.
Figura 51.7: RAID 4

No RAID 3, todo o acesso era realizado em todos os discos. Entretanto,

e possvel que algumas aplicacoes prefeririam acessos menores, permitindo que
ocorressem acessos independentes em paralelo. Essa e a finalidade dos nveis de
RAID 4-6. Tendo em vista que as informac oes de detecc
ao de erros em cada
setor s
ao examinadas nas leituras para verificar se os dados estao corretos, essas
pequenas leiturasem cada disco podem ocorrer independentemente, desde que
o acesso mnimo seja a um u nico setor.
As gravacoes s
ao outra quest ao. Aparentemente, cada pequena gravac ao
exigiria que todos os outros discos fossem acessados para ler o restante das in-
formacoes necess
arias para recalcular a nova paridade. Uma pequena gravac aoexigiria
417
a leitura dos dados antigos e da paridade antiga, adicionando as novas in-

formacoes, e depois a gravacao da nova paridade no disco de paridade e dos
novos dados no disco de dados.
A ideia-chave para reduzir essa sobrecarga e que a paridade e simplesmente
um somat orio de informacoes; observando quais bits se alteram quando grava-
mos as novas informac oes, s
o precisamos mudar os bits correspondentes no disco
de paridade. Dessa forma, temos de ler os dados antigos do disco que est a sendo
gravado, comparar os dados antigos com os novos para verificar quais bits mu-
daram, ler a paridade antiga, modificar os bits correspondentes, depois gravar
os novos dados e a nova paridade. Desse modo, uma pequena gravac ao en-
volve quatro acessos a dois discos, em vez do acesso a todos os discos. Uma
desvantagem do sistema e que o disco de paridade deve ser atualizado em cada
gravacao; assim ele e o gargalo de gravac
oes (write bottleneck).
Os sistemas RAID dos nveis 4 a 6 fazem uso de uma tecnica de acesso in-
dependente. Neste tipo de acesso, cada disco opera independentemente sendo
assim possvel satisfazer pedidos I/O em paralelo. Por esta raz ao, arrays deste
tipo e um arranjo perfeitamente ajustado para ambientes transacionais que re-
querem muitas leituras pequenas e simult aneas e menos para aplicac oes que
necessitem de altas taxas de transferencia.
51.1.6 RAID 5
Este tipo de RAID largamente usado funciona de forma similar ao RAID 4, mas
supera alguns dos problemas mais comuns sofridos por esse tipo. As informac oes
sobre paridade para os dados do array s ao distribudas ao longo de todos os
discos do array , ao inves de serem armazenadas num disco dedicado, oferecendo
assim mais desempenho que o RAID 4, e, simultaneamente, toler ancia a falhas.
A ideia de paridade distribuda reduz o gargalo de escrita, pois agora as
escritas concorrentes nem sempre exigem acesso ` as informac
oes de paridade
a um mesmo disco dedicado. Contudo, o desempenho de escrita geral ainda
sofre por causa do processamento adicional causado pela leitura, rec alculo e
atualizac
ao da informacao sobre paridade.
Figura 51.8: RAID 5
Para aumentar o desempenho de leitura de um array RAID 5, o tamanho

de cada segmento em que os dados s ao divididos pode ser otimizado para o
array que estiver a ser utilizado. O desempenho geral de um array RAID 5
e equivalente ao de um RAID 4, exceto no caso de leituras seq uenciais, que
reduzem a eficiencia dos algoritmos de leitura por causa da distribuicao das
informac
oes sobre paridade. A informac
ao sobre paridade ao ser distribuda ao
longo de todos os discos, havendo a perda de um, reduz a disponibilidade de
418
ambos os dados e da informacao sobre paridade, ate ` a recuperac

ao do disco que
falhou. Isto pode causar degradac ao do desempenho de leitura e de escrita.
Como em outros arranjos baseados em paridade, a recuperac ao de dados em
um arranjo RAID-5 e feita calculando a func ao XOR das informac oes dos discos
restantes do arranjo. Pelo fato de que a informac ao sobre paridade e distribuda
ao longo de todos os discos, a perda de qualquer disco reduz a disponibilidade
de ambos os dados e informac ao sobre paridade, ate a recuperac ao do disco
que falhou. Isto pode causar degradac ao da performance de leitura e de es-
crita. Alem disso, esta estrutura e vista como contendo uma limitac ao crtica, o
throughput das aplicac oes sofre normalmente uma penalizac ao ate cerca de 4x,
comparativamente a arrays n ao redundantes para pequenas escritas.
51.1.7 RAID 6 (Redund

ancia de P+Q)
Os esquemas baseados em paridade protegem contra uma u nica falha auto-
identificada. Quando uma u nica correc
ao de falha nao e suficiente, a paridade
pode ser generalizada para ter um segundo c alculo sobre os dados e outro disco
de verificac
ao de informac
oes. Esse segundo bloco de verificac ao permite a recu-
perac
ao de uma segunda falha. Desse modo, a sobrecarga de armazenamento e
o dobro do overhead do RAID 5. o atalho de pequena gravac ao apresentado an-
teriormente funciona bem exceto pelo fato de haver agora seis acessos ao disco,
em vez de quatro, para atualizar as informac oes P e Q. A figura ?? ilustra essa
configuracao.
Figura 51.9: RAID 6 - Redund

ancia P+Q
Em RAID 6 s ao efetuados dois calculos diferentes para a paridade e ar-

mazenados em blocos separados em discos diferentes. Na realidade, um array
de n discos organizados em RAID 6 requer n+2 discos.
P e Q s
ao dois algoritmos diferentes de verificac
ao de dados. Um dos dois e o
c
alculo por xor j
a referido e usado em RAID 4 e 5, sendo o outro um algoritmo
independente. Isto torna possvel a regenerac ao de dados mesmo que ocorra
uma falha em dois dos discos.
A grande vantagem desta organizac ao e o fato de providenciar alta disponi-
bilidade de dados. Teria de ocorrer um erro em tres dos discos durante o tempo
medio para reparac
ao para que isso tornasse os dados indisponveis. Por outro
lado, subjacente a este sistema est a um write penalty substancial, pois cada
escrita afeta obrigatoriamente dois blocos de paridade.
51.1.8 Tipos Hbridos

Dadas as limitac
oes de cada nvel RAID, diversos criadores de dispositivos de
armazenamento tentaram criar novas formas RAID combinando caractersticas
de cada um dos nveis originais.
419
RAID 10: Nesta variedade combina-se o espelhamento existente em RAID

1 com a divisao em faixas do RAID 0. Numa implementac ao 0+1 os dados
s
ao divididos por conjuntos de drives duplicadas. Numa implementac ao
1+0, os dados s ao divididos por diversas drives e este array completo
de discos e duplicado por um ou mais array de drives. O desempenho na
reposic
ao de dados e melhor neste tipo de arrays que em sistemas baseados
em paridade, pois os dados n ao precisam ser regenerados com base nesta,
mas sim simplesmente copiados para a nova drive.
RAID 30 e 50: Esta forma consiste em manter a informac ao dividida
em faixas ao longo de uma matriz RAID 3 ou 5. Estes hbridos provi-
denciam os mesmos benefcios de arrays acesso paralelo (altas taxas de
transferencia) ou as vantagens de arrays de acesso independente baseados
em paridade (alto throughput).
51.1.9 Comparativo de Desempenho entre as diversas con-

figura
coes RAID
51.2 SAN - Storage Area Network

A SAN poderia ser definida como uma rede de alta velocidade, comparada ` a
LAN (Local Area Network), que permite o estabelecimento de conex oes diretas
entre os dispositivos de armazenamento e processadores (servidores) centraliza-
dos à extens
ao suportada pela dist ancia das fibras oticas. A SAN pode ser vista
como uma extens ao do conceito que permite que os dispositivos de armazena-
mento sejam compartilhados entre servidores e interconectados entre si. Uma
SAN pode ser compartilhada entre servidores ou dedicada a um servidor local
ou remoto.
Outra definic
ao diz que SAN s ao dois ou mais dispositivos se comunicando
via protocolo serial SCSI, tal como Fibre Channel ou iSCSI. Segundo essa
definic
ao, uma LAN que trafega nada mais do que tr afego de storage n
ao pode
ser considerada uma SAN. O que diferencia uma LAN de uma SAN (ou de uma
NAS) e o protocolo que e usado. Assim, se o tr afego de storage trafega em uma
LAN atraves do protocolo iSCSI, ent ao essa LAN pode ser considerada uma
SAN. Entretanto, simplesmente enviar dados de backup atraves de uma LAN
dedicada isso nao a torna uma SAN. Enfim, uma SAN e uma rede que usa um
protocolo serial SCSI para transferir dados.
A figura 51.10 abaixo mostra uma vis ao geral de uma SAN conectando v arios
servidores a varios sistemas de armazenamento:
SANs criam novos metodos de conex ao de armazenamento aos servidores.

Estes novos metodos prometem uma not avel melhora em performance e disponi-
bilidade. SANs s ao usadas para conectar conjuntos de armazenamento com-
partilhados a v arios servidores, e s ao usadas por servidores em ambiente de
cluster para fail over. Elas podem interconectar discos ou fitas de mainframe a
servidores ou clientes de rede e podem criar caminhos paralelos de dados para
ambientes de computac ao e de alta largura de banda. A SAN e uma outra rede
que difere das redes tradicionais, porque foi concebida a partir de interfaces de
armazenamento.
Alem disso, a SAN pode ser usada para contornar os conhecidos gargalos de
rede, pois suporta diretamente altas velocidades de transferencia de dados entre
420
Figura 51.10: Exemplo de SAN
os servidores e dispositivos de armazenamento nas seguintes formas:
Servidor para storage: e o modelo tradicional de interac

ao com os dis-
positivos de armazenamento e cuja vantagem e que um mesmo disposi-
tivo de armazenamento pode ser acessado serial ou concorrentemente por
multiplos servidores;
Servidor para servidor: no qual a SAN pode ser usada para alta velocidade
e comunicac
oes de alto volume entre servidores;
Storage para storage: permite a movimentacao dos dados sem intervenc
ao
do servidor, liberando o processador para outras atividades. Por exemplo:
um disco pode realizar o backup de dados para uma fita sem a intervenc
ao
do servidor ou um espelhamento de dispositivo remoto atraves da SAN.
O uso de SANs gera uma melhora de performance das aplicac oes, por ex-
emplo, permitindo que o dado enviado diretamente do dispositivo de origem ao
dispositivo de destino nao requeira intervenc
ao do servidor. As SANs tambem
habilitam novas arquiteturas de rede nas quais varios computadores (hosts) aces-
sam varios dispositivos de armazenamento conectados na mesma rede. Conheca
outros benefcios que o uso da SAN pode oferecer ` as empresas:
Mais disponibilidade: armazenamento independente de aplicac

oes acessveis
atraves de caminhos alternativos de dados;
Alta performance: os dados s
ao descarregados do servidor e movidos para
uma rede independente;
Armazenamento centralizado e consolidado: gerenciamento mais simples,
escalabilidade, flexibilidade e disponibilidade;

Transferencia e armazenamento: c opia remota de dados habilitada para
protec
ao contra falhas e desastres;
Gerenciamento centralizado mais simplificado: a imagem simples do meio
de armazenamento simplifica o gerenciamento.
51.2.1 Hardware para SAN

Talvez a parte mais importante para a implantac
ao de uma SAN seja referente
ao hardware. Os principais componentes s
ao:
421
Servidor de Disco: Servidores de discos, tambem chamados de storages s ao

dispositivos que armazenam discos compartilhados pelos hosts da rede.
Eles possuem, em geral, diversas areas diferentes, com esquemas de RAID
diferentes ou discos especficos para a realizac
ao de espelhamentos para
backup, os chamados BCV (business continuance volumes). Os BCVs
facilitam muito tanto o backup quanto a restaurac ao dos dados. O seu
conte udo e sincronizado com o conte udo do disco principal, ate que se
faca uma quebra do sincronismo, o chamado split. Neste momento, o BCV
guarda uma imagem do disco antes do split, e pode ser usado para backup,
enquanto o servidor continua trabalhando, sem impactos na produc ao.
Este procedimento pode ser feito com a freq uencia mais conveniente para
o usu ario e, em muitos casos, o BCV e utilizado tambem para restaurac
ao
de dados perdidos, que e muito mais rapido do que acessar fitas de backup.
Switches fibre channel: Switches fibre channel s ao bem mais complexos

que os hubs, tanto em seu projeto quanto em funcionalidade. Enquanto
os hubs s ao apenas um concentrador de cabos para um segmento com-
partilhado, um switch e um dispositivo de r
apido roteamento dos dados e
possui uma taxa de transferencia de dados exclusiva para cada porta. As
taxas de transferencia variam bastante dependendo do switch, que vem
evoluindo rapidamente. Atualmente, a velocidade m axima est
a em 400
MB/s para cada porta. Enquanto os hubs n ao participam de atividades
no nvel do protocolo Fibre Channel, os switches participam ativamente,
tanto para fornecer servicos quanto para supervisionar o fluxo de frames
entre a origem e o destino.
HBA (Host Bus Adapter): Uma HBA e um dispositivo capaz de conectar

dispositivos externos a um servidor. Por exemplo: para conectarmos um
disco SCSI a um micro (barramento interno PCI), ser a necess
ario utilizar
uma HBA SCSI-PCI. No caso da SAN, e necess ario instalar em todos os
servidores participantes dela uma HBA Fibre Channel, que se encarregar a
de fazer as convers
oes dos diferentes meios internos e externos ao servidor.
As HBAs FC possuem, ainda, uma especie de processador (um chip) capaz
de fazer a conversao de protocolos para poupar a CPU do servidor deste
trabalho.
51.2.2 Topologias de SAN

As SANs atuais s ao todas construdas em uma topologia fsica de estrela. Um
switch e conectado ao storage e neles conectamos todos os outros servidores da
rede. A excec
ao fica com a ligac
ao ponto-a-ponto, como veremos a seguir.
Liga
cao ponto-a-ponto (point-to-point)
Para alguns nao e considerada uma topologia de SAN, uma vez que n ao possui
escalabilidade alguma. Neste tipo de ligacao, os servidores s
ao ligados dire-
tamente ao storage, sem nenhum equipamento intermedi ario, como switch. O
n
umero m aximo de servidores envolvidos e igual ao n
umero de portas que o
storage possui. Comparado com a ligac ao SCSI, no entanto, esta topologia,
que utiliza Fibre Channel, apresenta uma performance muito melhor e atinge
dist
ancias maiores.
422
Figura 51.11: SAN ponto a ponto
Loops ou an
eis: Fibre Channel Arbitrated Loop (FC-AL)
Nesta topologia utiliza-se hub, cuja largura de banda de no maximo de 100 MB/s
e compartilhada por todos os seus membros. Teoricamente suporta loops com
ate 126 dispositivos, mas na pratica este n
umero e bem menor. Esta topologia
esta sendo muito pouco utilizada nas SANs modernas. Algumas pessoas com-
param esta topologia como uma rede Token Ring, em que a largura de banda e
dividida por todos os dispositivos do loop. Entretanto h a equipamentos antigos
que n ao suportam o modo fabric e, assim, e utilizado o modo em loop.
Figura 51.12: SAN FC-AL - Fibre Channel Arbitrated Loop
Malha (Switched Fabric ou Fabric)

Nesta topologia, utiliza-se switches Fibre Channel, o que permite um grande
n
umero e dispositivos interconectados. Dedica largura de banda integral a cada
uma das portas e ermite transferencias de dados simultaneamente para um u
nico
n a topologia que permite ais escalabilidade e crescimento. Teoricamente,
o. E
pode conter mais de 7,7 milhoes de nos.
51.3 NAS - Network Attached Stotage

O compartilhamento de arquivos na rede ja era possvel mesmo antes da chegada
do sistema NAS. Isso era possvel gracas aos protocolos NFS (Network File
System) do Unix e CIFS (Common Internet File System) do Windows. En-
tretanto, ambos possuam limitac
oes de desempenho e gerenciamento. Alem
disso, servidores deviam ser dedicados a usar ou NFS ou CIFS. O sucesso do
NAS, portanto, foi corrigir algumas limitac
oes de cada protocolo e permitir que
ambos pudessem operar em um mesmo servidor. Assim, pode-se dizer que NAS
423
Figura 51.13: SAN Switched Fabric
(Network attached storage) e um computador dedicado a compartilhamento de

arquivos atraves de NFS, CIFS ou DAFS(Direct Access Files). Cabe ressaltar
que e um dispositivo dedicado exclusivamente ao compartilhamento de arquivos,
centralizando a responsabilidade de servir os arquivos em uma rede e desse modo
libera recursos de outros servidores.
Um dispositivo NAS combina a tecnologia dos arrays de discos com a in-
teligencia de uma pequena unidade de processamento. Nesse sentido, e possvel
adicionar armazenamento na rede sem ser necess ario desligar o servidor. E co-
mum a familiaridade com o conceito de impressora de rede, ou seja, aquela
onde o usu ario pode imprimir. Do mesmo modo o NAS e uma unidade partil-
hada atraves da LAN e todos os usuarios com os direitos e permiss
oes de acessos
adequados podem montar sistemas de arquivos diretamente sem ter que veicular
os dados atraves do servidor. Tipicamente, cada interacao entre aplicac
oes e o
NAS envolve a transferencia de um volume de dados relativamente pequeno e
de curta durac ao. Alem disso o NAS pode estar ligado em qualquer parte da
LAN.
51.4 Comparativo entre SAN e NAS

Vistas como concorrentes, as SANs e as s ao tecnologias complementares. En-
quanto as primeiras sao otimizadas para transferencias de altos volumes de da-
dos orientadas em bloco, as NAS oferecem acesso a dados em nvel de arquivo.
Baseadas em protocolos abertos, como Fibre Channel e TCP/IP, oferecem varias
vantagens em relac
ao ao sistema de armazenamento ligado ao servidor. A seguir
um resumo das principais diferencas entre cada tecnologia.
Protocolo:
SAN: Serial SCSI-3
NAS: TCP/IP, NFS/CIFS
Compartilhamento:
SAN: Drives de discos e fitas
NAS: Sistemas de arquivos
424
Permite:
SAN: Diferentes servidores acessarem o mesmo drive de disco ou fita
de forma transparente para o usuario final.
NAS: Diferentes usu
arios acessarem o mesmo sistema de arquivos ou
ate um mesmo arquivo.
Substitui:
SAN: Os drivers de discos e fitas locais, ou seja, drivers conectados

diretamente ao servidor. Com SAN, centenas de sistemas podem
compartilhar o mesmo drive de disco ou fita.
NAS: Servidores Unix NFS e servidores NT CIFS que possibilitavam
sistemas de arquivos compartilhados em rede.
Aplicac
oes:
SAN:Processamento de aplicac oes de banco de dados de missao crit-

ica; Backup de dados centralizado; Operacoes de recuperac
ao de de-
sastres; Consolidacao de armazenamento.
NAS: Compartilhamento de arquivo em NFS e CIFS; Transferencia
de pequenos blocos de dados a longas dist
ancias; Acesso ao banco de
dados limitado somente a leitura.
Vantagens:
SAN: Alta disponibilidade; Confiabilidade na transferencia de dados;

Trafego reduzido na rede primaria; Flexibilidade de configurac ao;
Alto desempenho; Alta escalabilidade; Gerenciamento centralizado;
Oferta de m
ultiplos fornecedores.
NAS: Poucas limitac
oes de distancia; Adic
ao simplificada da capaci-
dade de compartilhamento de arquivo; Facil instalac
ao e manutenc
ao.
Muitos poderiam argumentar que SAN e mais poderoso que NAS ou que
NFS e CIFS sendo executado sobre TCP/IP gera muita mais sobrecarga para
o cliente que o iSCSI sendo executado sobre um Fibre Channel. Estas quest oes
poderiam dar a entender que sistemas SAN resultam em maior throughput para
o cliente que os sistemas NAS. Essa observac ao e verdadeira se consideramos
como clientes os grandes servidores, entretanto grande parte das aplicac oes s
ao
menos exigentes sob esse ponto de vista sendo o desempenho oferecido pelo NAS
bastante suficiente.
Enquanto SAN oferece acessos concorrentes em nvel de dispositivos, NAS
oferece em nvel de arquivos e essa e uma exigencia de muitas aplicac
oes. Outra
vantagem do NAS e que ele e mais simples de se entender e aprender. Em geral,
os protocolos e tecnologias que envolvem os sistemas SAN s ao relativamente
complexos. Alem disso, SAN e composto de diversas partes de hardware, que
s
ao especializados para tal sistema, de diferentes fabricantes. Se o ambiente onde
ser
a implantado a SAN nunca recebeu um sistema assim, todos os equipamentos
devem ser adquiridos. No caso do NAS isso n ao acontece, pois o NAS permite
usar a infra-estrutura de rede ja presente no ambiente. Enfim, o sistema NAS e
mais facil de se manter que o sistema SAN. Outra conseq uencia imediata e que
425
sistemas SAN s ao mais caros que os NAS. Outro destaque e que o NAS permite
que arquivos sejam replicados automaticamente para outros pontos, tornando
mais f acil protege-los contra falhas.
Entretanto, NAS tem limitac oes tambem. Embora os esquemas de replicac ao
oferecidos por alguns NAS propiciem excelentes formas de recuperac ao, carac-
terstica mais difcil de ser suportada em SANs, backups ter ao de serem feitos
em fitas em algum momento e fazer backup de um arquivo para uma fita pode
ser um desafio. Uma das raz oes e que fazer um backup completo para fita ir a
exigir muito mais tarefas de I/O que qualquer outra aplicac ao. Isso significa que
fazer backup de um arquivo relativamente grande ir a sobrecarregar bastante o
sistema. Nesse sentido, sistemas SANs ainda s ao mais eficientes. Em comple-
mento, realizar backup de um determinado arquivo significa que o sistema de
arquivo ter a que ser atravessado da mesma forma como se um usu ario estivesse
usando-o e isso e outro motivo de sobrecarga no sistema. Por fim, embora seja
plausvel que a maioria das aplicac oes nao seja limitada pelo throughput de um
sistema de arquivos e importante ressaltar que teoricamente um sistema NAS
e capaz de transferir mais dados que o NAS. Assim se a aplicac ao necessitar
de grandes transferencias de dados e preciso fazer uma avaliac ao de qual opc ao
melhor se adapta ao perfil da aplicac ao.
Assim como o NAS possuem vantagens e desvantagens o mesmo ocorre com
SAN. A primeira vantagem do SAN em relac ao ao NAS e que o ultimo so e capaz
de atender a requisic oes em nvel de arquivos via NFS e CIFS enquanto o SAN
e capaz de atender requisic oes de acesso a dispositivos. Alem disso, enquanto
alguns veem complexidade no SAN outros veem como flexibilidade, ou seja, os
recursos de sistema de arquivos e gerenciamento de volumes disponveis no SAN
nao podem ser oferecidos pelo NAS. Outro ponto diz respeito ao fato que SAN
pode ser mais r apido que NAS, conforma discutido anteriormente. A capacidade
em throughput da SAN possibilita backups em maior escala e recuperac ao mais
f
acil. V arias desvantagens da SAN j a foram citadas, mas a principais s ao seu
custo e complexidade.
426
Captulo 52
Clusters de servidores
Um cluster e um conjunto de m
aquinas independentes, chamadas n os, que co-
operam umas com as outras para atingir um determinado objetivo comum. Por
serem fracamente agrupadas, para atingir este objetivo elas devem comunicar
umas com as outras a fim de coordenar e organizar todas as ac oes a serem
tomadas. Deste modo, para um usu ario externo, o cluster e visto como sendo
um unico sistema.
Figura 52.1: Cluster de 4 n

os
O objetivo desejado em um cluster resume-se em:
Alta Disponibilidade, quando se deseja que o cluster forneca determinados

servicos, sendo que estes devem estar sempre (ou quase sempre) disponveis
para receber solicitac
oes. Esta probabilidade do servico estar apto a rece-
ber solicitac
oes e um fator dependente do cluster.
Alto Processamento, quando se deseja que o cluster execute determinadas

tarefas, sendo que elas sao divididas (na sua ntegra ou em frac
oes de uma
mesma tarefa) e processadas separadamente em v arios n
os, a fim de a
velocidade de processamento seja incrementada.
E possvel ainda ter uma situac

ao onde o cluster deve atingir os dois objetivos
juntos; `
as vezes, por razoes de simplicidade, tal objetivo e atingido eliminando-se
alguns rigores das definicoes acima.
52.0.1 Princpios de um Cluster

Para ser u
til, um cluster precisa seguir alguns princpios b
asicos:
427
Comodidade: Os n os em um cluster devem ser m aquinas normais inter-

conectadas por uma rede generica. O sistema operacional tambem deve
ser padr
ao, sendo que o software de gerenciamento deve ir acima dele como
uma aplicac
ao qualquer.
Escalabilidade: Adicionar aplicacoes, n

os, perifericos e interconex
oes de
rede deve ser possvel sem interromper a disponibilidade dos servicos do
cluster.
Transparencia: O cluster, que e construdo com um grupo de n os indepen-

dentes fracamente agrupados, deve apresentar-se como um u nico sistema
a clientes externos ao cluster. Aplicac
oes clientes interagem com o cluster
como se fosse um u nico servidor com alta performance e/ou alta disponi-
bilidade.
Confiabilidade: o cluster deve ter capacidade de detectar falhas internas

ao grupo, assim como de tomar atitudes para que estas n
ao comprometam
os servicos oferecidos.
Gerenciamento e Manutenc ao: Um dos problemas dos clusters e sua manutenc
ao
e configurac
ao, que muitas vezes s
ao tarefas complexas e propensas a gerar
erros. Um mecanismo f acil de configuracao e manutenc
ao do ambiente
deve existir a fim de que o cluster nao seja um grande sistema complexo
com um arduo trabalho de administrac ao.
52.0.2 Abstra
coes em um Cluster
Um cluster possui varios elementos que, juntos com sua arquitetura, fornecem
a funcionalidade desejada. Uma abstrac ao dos elementos e necess
aria para se
poder compreender qual o comportamento de cada um deles.
No: Como visto anteriormente, o no e a unidade b

asica do cluster; gru-
pos de n
os formam um cluster. Em um cluster, um n o comunica-se com
os outros atraves de mensagens sobre conexoes de rede, e falhas em n os
podem ser detectadas atraves de timeouts de comunicacao. Um n o e um
sistema computacional unicamente identificado conectado a um ou mais
computadores em uma rede. Assim, um n o tem quatro componentes prin-
cipais:
CPU;
Mem
oria;
Reposit
orio de Armazenamento;
Interconex
ao.
Recurso: Um recurso representa certa funcionalidade oferecida em um n o.
Ele pode ser fsico, como por exemplo uma impressora, ou l ogico, como por
exemplo um endereco IP. Recursos s ao a unidade b
asica de gerenciamento,
e podem migrar de um n o a outro. Independentemente se for resultado de
uma falha ou intervencao humana, o processo de migrac ao de um recurso
de um no para outro e chamado de failover. Como um recurso representa
uma funcionalidade, ele pode falhar. Por isso, monitores devem observar
428
o status dos recursos, a fim de tomar atitudes desejadas em caso de falha

(por exemplo, iniciar o servico em outro no). Um recurso tem associado
a si um tipo, que descreve seus atributos genericos e seu comportamento.
Cada tipo deve ter associado a si mecanismos de iniciac ao/parada, a fim
de que possam ser manipulados corretamente pelo gerenciador do cluster.
Dizemos que um n o p hospeda um recurso r se em determinado momento
o servico associado a r est
a sendo fornecido a partir de p.
Dependencias de Recursos: Freq uentemente, recursos dependem da disponi-
bilidade de outros recursos. Por exemplo, um servidor HTTP depende da
presenca de uma interface de rede online e de um sistema de arquivos
operacional para fornecer os arquivos. Por outro lado, um sistema de ar-
quivos pode depender de um volume manager. Estas dependencias s ao
descritas em um grafo de dependencias de recursos. Este grafo de de-
pendencias descreve a seq
uencia na qual os recursos devem ser iniciados.
Ainda, durante uma migrac ao de recursos ele descreve quais recursos de-
vem ser migrados juntos.
Grupos de Recursos: Um grupo de recursos e a unidade de migrac ao.
Apesar de um grafo de dependencias descrever os recursos que devem ser
migrados juntos, pode haver consideracoes adicionais para agrupar recur-
sos. O administrador de sistemas pode associar uma colec ao de recursos
independentes em um u nico grupo de recursos, a fim de garantir que todo
o grupo seja migrado junto. Polticas de migrac
ao s
ao definidas baseadas
em grupos. As dependencias de recursos vistas acima n ao podem ultra-
passar as barreiras de um grupo, ou seja, recursos de um grupo devem
depender somente de recursos contidos em seu pr oprio grupo.
52.0.3 Arquitetura de um Cluster

Isoladamente, os elementos descritos acima nao proveem a funcionalidade de-
sejada do cluster. E necessario que haja uma arquitetura que una todos os
elementos e forneca o funcionamento que cada um espera do outro. Devido ` a
natureza fracamente agrupada do cluster, uma abstrac ao ideal de arquitetura
deve ser baseada em componentes. Tal estrutura seria formada pelas seguintes
camadas basicas:
Camada de Comunicacao: trata das comunicac

oes ponto-a-ponto entre os
n
os.
Camada de Ligac
ao: agrupa canais de comunicac
ao em uma u
nica ligac
ao
entre dois n
os.
Camada de Integrac
ao: forma a topologia do cluster.
Camada de Recuperacao: executa a recuperac ao (failover) e a inicial-
izac
ao/parada controlada de servicos depois de uma transicao do cluster.
Existem ainda quatro servicos chaves para um cluster:
JDB: armazena estados persistentes internos ao cluster (e usados para

o banco de dados do quorum). Nada mais e do que um reposit orio de
informac
oes local a cada n
o do cluster.
429
Camada de Qu orum: determina qual partic

ao do cluster possui autor-
izac
ao para prosseguir com sua execuc
ao.
Servico de Barreiras: prove um servico de sincronizac

ao global ao cluster.
Servico de Nomes: prove um servico de nomes global ao cluster.
52.0.4 Cluster X Sistemas Distribudos

Um sistema distribudo consiste em um conjunto de processos concorrentes que
cooperam uns com os outros para executar determinada tarefa. Ele e formado
por varios n os, que se utilizam da rede de comunicac ao para trocarem men-
sagens. As m aquinas s
ao autonomas, formando um sistema fracamente agru-
pado, onde n ao existe mem oria compartilhada entre diferentes n os. Entre as
aplicac
oes tpicas de um sistema distribudo est
ao servicos de arquivos de/para
maquinas distribudas e distribuic
ao de carga de processamento entre diversas
maquinas. A figura 52.2 ilustra essa organizac ao.
Figura 52.2: Sistema Distribudo
Clusters sao uma subclasse de sistemas distribudos. Geralmente eles s ao

grupos de computadores homogeneos em menos escala, dedicado a um n umero
pequeno e bem definido de tarefas, nas quais o cluster atua como uma u nica
maquina. Entre os usos tpicos de um cluster est
ao adicionar alta disponibilidade
a servicos e aumentar a capacidade de processamento do grupo (fazenda de
servidores).
A tabela abaixo enumera as principais diferencas entre cluster e sistemas
distribudos. Analisando a tabela pode-se concluir que um cluster nada mais e
do que um sistema distribudo especializado para uma determinada tarefa.
Estrutura:
Cluster:homogenea - adquirido para realizar determinada tarefa

Sist. Distribudo: heterogenea - montado a partir do hardware disponvel.

Tarefa:
Cluster: especializada - feita para executar um pequeno conjunto de

tarefas bem definido.
Sist. Distribudo: generalizada - usalmente precisam ser um ambi-
entes de computacao genericos
Preco:
Cluster: relativamente baixo.
430
Sist. Distribudo: barato / caro.

Confiabilidade:
Cluster: t
ao confi
avel quanto precisa ser.
Sist. Distribudo: pouco / muito confi
avel.
Seguranca:
Cluster: os n
os confiam uns nos outros.
Sist. Distribudo: os n
os n
ao confiam uns nos outros.
52.0.5 Cluster de Alta Disponibilidade

Pelo fato do termo cluster abranger uma grande quantidade de implementac oes,
convencionou-se o uso de termos especficos para cada tipo de implementac ao.
Clusters Beowulf s ao usados para oferecer escalabilidade e processamento par-
alelo para execuc ao de funcoes computacionais. Soluc oes de clusters de alta
disponibilidade, por sua vez, s ao usados para fornecer alta disponibilidade para
servicos ou aplicac
oes. Clusters de alta disponibilidade sao comumente conheci-
dos como Failover Cluster.
Failover e o processo no qual uma m aquina assume os servicos de outra,
quando esta apresenta alguma falha. O failover pode ser autom atico ou manual,
sendo o autom atico normalmente esperado em uma soluc ao de alta disponibili-
dade.
Para se executar o failover de um servico, e necess
ario que as duas m aquinas
envolvidas possuam recursos equivalentes. Um recurso pode ser uma placa de
rede, um disco rgido, os dados neste disco ou qualquer elemento necess ario
a prestac
` ao de um determinado servico. E importante que a soluc ao de alta
disponibilidade mantenha recursos redundantes com o mesmo estado, de forma
que o servico possa ser retomado sem perdas. Para isto, pode-se usar tecnicas
de espelhamento de disco, replicac ao de dados ou sistemas de armazenamento
compartilhados.
Ao ser resolvida a falha, o servidor ser
a recolocado em servico, e ent ao tem-se
a opcao de realizar o processo inverso do failover, chamado failback. O failback
e o processo de retorno de um determinado servico de uma outra m aquina para
sua m aquina de origem. Este processo tambem pode ser autom atico, manual ou
ate mesmo indesejado. Em alguns casos, em func ao da possvel nova interrupc
ao
na prestacao de servicos, o failback pode n ao ser atraente.
Tipos de Clusters de Alta Disponibilidade

Existem dois tipos b asicos de clusters de alta disponibilidade, os simetricos e os
assimetricos. Clusters de alta disponibilidade assimetricos s
ao os mais simples de
se implementar. Eles se baseiam no conceito de servidores prim ario e secund
ario.
Servidores que est ao provendo algum tipo de servico s ao considerados como
primarios. Servidores que aguardam a ocorrencia de alguma falha no servidor
primario s
ao denominados servidores secund arios. A deteccao da falha ocorre
atraves do monitoramento dos servidores prim arios por parte dos secund arios.
A principal diferenca entre clusters assimetricos e simetricos e que em um
cluster simetrico n
ao h
a a figura de um servidor inativo aguardando uma falha de
431
Figura 52.3: Cluster de Alta Disponibilidade Assimetrico
outro, primario, para ent

ao servir a aplicacao. Neste modelo, ambos servidores
servem alguma aplicac ao. Assim, os termos prim ario e secundario deixam de
ser usados para designar o servidor, passando a ser usado para a aplicac ao.
De forma semelhante ao que ocorre em clusters assimetricos, na ocorrencia de
uma falha em um dos servidores, d a-se incio ao processo de failover. Neste caso,
o servidor ainda ativo assume o controle da aplicac ao do servidor problem atico.
Ao contrario do modelo anterior, neste o monitoramento dever a ocorrer entre
todos os nos.
Figura 52.4: Cluster de Alta Disponibilidade Simetrico
Tipos de Armazenamento
Dependendo da escala, performance, funcionalidade e flexibilidade do cluster,
s
ao necess arias diferentes implementacoes de armazenamento. Os principais
metodos de armazenamento sao o compartilhamento total, sem compartilhamento
e espelhamento de disco.
No compartilhamento total, todos os servidores acessam o mesmo meio de
armazenamento. Este modelo apresenta potenciais problemas de corrupc ao de
dados quando mais de um servidor est a ativo. Para soluc
ao deste problema,
caractersticas de locking s
ao desejadas. Esta implementac
ao e bastante comum
em clusters assimetricos.
Figura 52.5: Cluster com compartilhamento total de armazenamento
432
No armazenamento sem compartilhamento, dois ou mais servidores possuem

seu pr
oprio meio de armazenamento. No evento de uma falha em um dos servi-
dores, o servidor respons
avel pela substituic
ao passa a ter acesso total ao meio
de armazenamento original do n o defeituoso. Esta implementac ao e comum em
clusters simetricos.
Figura 52.6: Cluster sem compartilhamento de armazenamento
Em um ambiente de espelhamento de discos, n ao ha nenhum tipo de com-

partilhamento entre os n os servidores. Atraves do uso de software, os dados
s
ao espelhados ou replicados de um servidor para o outro atraves da rede. O
princpio deste modelo e que todos servidores potenciais substitutos devem pos-
suir seu proprio meio de armazenamento e, ao mesmo tempo, uma replica do
armazenamento do servidor a ser substitudo.
Figura 52.7: Cluster sem compartilhamento de armazenamento
Em um ambiente de espelhamento de discos, n ao ha nenhum tipo de com-

partilhamento entre os n os servidores. Atraves do uso de software, os dados
s
ao espelhados ou replicados de um servidor para o outro atraves da rede. O
princpio deste modelo e que todos servidores potenciais substitutos devem pos-
suir seu proprio meio de armazenamento e, ao mesmo tempo, uma replica do

armazenamento do servidor a ser substitudo.
52.0.6 Cluster de Alto Desempenho

Sistemas de processamento paralelo vem se tornando cada vez mais populares
em func
ao da demanda por processamento de alto desempenho, exigido pelas
diversas
areas da ciencia (ex.: qumica, biologia, meteorologia). Infelizmente,
os sistemas que oferecem a capacidade de processamento para satisfazer a essa
demanda, representados pelas m aquinas de arquiteturas macicamente paralelas
ou tem um custo elevado, ou s ao difceis de programar, ou ambos. Em funcao
433
Figura 52.8: Cluster com espelhamento de dados
disso, nos u ltimos anos, tem-se investido na pesquisa de m aquinas paralelas

baseadas em clusters de multiprocessadores simetricos por possurem um custo
relativamente mais baixo que as m aquinas de arquitetura macicamente paralelas
alem de serem mais flexveis que essas.
Atualmente, existem diferentes tipos de arquiteturas dedicadas ` a execucao
de aplicac
oes paralelas, sendo que essas podem ser classificadas em tres tipos:
Arquiteturas macicamente paralelas (MPP): s ao arquiteturas que possuem

processadores altamente poderosos e links de comunicacao dedicados. Este
tipo de arquitetura, chamada de supercomputadores ou arquiteturas dedi-
cadas, apresentam um alto custo, devido aos recursos que oferecem. Como
exemplo, pode-se citar o Intel Paragon e o IBM SP2.
Multiprocessadores simetricos (SMP): s ao arquiteturas compostas por um
conjunto de processadores iguais, que se comunicam, geralmente, atraves
de uma mesma mem oria. termo simetrico significa que todos os proces-
sadores s
ao identicos em termos de arquitetura interna e poder de proces-
samento. Exemplos dessa arquitetura s ao os processadores Dual Pentium.
Redes de estacoes (NOW): s ao arquiteturas que correspondem a um con-

junto de estac
oes de trabalho interligadas atraves de uma rede local (LAN)
e que servem como plataforma de execuc ao de aplicac
oes distribudas.
Nesse tipo de arquitetura, a comunicac ao e feita por troca de mensagens
entre as diversas aplicac
oes que executam na rede. Esse tipo de arquite-
tura e largamente utilizado, tanto comercialmente como academicamente.
Como exemplo, podemos citar Estac oes Sun interligadas por rede Ether-
net.
Nesse contexto, um cluster pode ser caracterizado como uma plataforma al-
ternativa, aliando o poder e a velocidade de processamento das arquiteturas ded-
icadas (MPPs) com a disponibilidade de recursos (hardware e software baratos)
das redes de estac
oes.
Quando comparados com arquiteturas dedicadas, os clusters de multipro-
cessadores simetricos apresentam um grande n umero de vantagens. Eles s ao
relativamente baratos (seus custos s ao menores que o custo de um supercom-
putador paralelo), eles oferecem uma boa relac ao custo/desempenho (porque
todo o hardware e o software necess arios est
ao `
a disposic
ao), e, da mesma forma,
suas volumosas vendas atraem investimentos diretos para o seu r apido melhora-
mento. Eles tambem permitem um desenvolvimento progressivo de aplicac oes,
434
comecando com apenas um processador, passando para multiprocessadores e,

finalmente, usando um conjunto de estac
oes de trabalho multiprocessadoras in-
terconectadas por alguma rede de comunicacao de dados local.
Em complemento, podem-se caracterizar basicamente, duas classes de ar-
quiteturas baseadas em clusters:
Arquiteturas homogeneas: onde os nodos que comp oem o cluster possuem

a mesma arquitetura e sistema operacional, logo entendem as mesmas in-
struc
oes sem a necessidade de convers
ao de dados a fim de possibilitar o
processamento dos mesmos, em diferentes processadores. As arquiteturas
homogeneas estao se tornando um padr ao na area de clusters de alto de-
sempenho, por serem mais simples de operar e por n ao apresentarem prob-
lemas ligados `
a conversao de dados entre diferentes sistemas operacionais
e ou arquiteturas;
Arquiteturas heterogeneas: onde os nodos que formam o cluster possuem

processadores diferentes e, possivelmente, diferentes sistemas operacionais.
Exigem a convers ao de dados para que uma instruc ao possa processar em
diferentes processadores. Apresentam problemas ligados ` a conversao de
dados entre diferentes sistemas operacionais e ou arquiteturas.
Alem dessas classes de arquiteturas cluster, pode-se distinguir dois tipos de

classificac
ao quanto aos nodos que fazem parte do cluster:
Arquitetura simetrica: possuem todos os nodos homogeneos, sendo que to-

dos os nodos possuem a mesma velocidade e capacidade de processamento,
alem de possurem a mesma quantidade de recursos computacionais (ex.:
mem oria). Somente clusters com esse tipo de arquitetura possibilitam
uma verdadeira an alise de desempenho.
Arquiteturas assimetricas: possuem nodos diferentes. Podem possuir no-

dos homogeneos, mas com diferentes velocidades e capacidades de pro-
cessamento ou nodos homogeneos com diferentes recursos de computac ao
(ex.: mem
oria). Arquiteturas dessa classe dificultam possveis an
alises de
desempenho.
435
Captulo 53
Balanceamento de Carga
Todo hardware tem o seu limite, e muitas vezes o mesmo servico tem que ser
repartido por v
arias maquinas, sob pena de se tornar congestionado. Estas
soluc
oes podem-se especializar em pequenos grupos sobre os quais se faz um
balanceamento de carga: utilizacao do CPU, de armazenamento ou de rede.
Qualquer uma delas introduz o conceito de clustering, ou server farm, j
a que o
balanceamento sera, provavelmente, feito para v
arios servidores.
53.1 Balanceamento de armazenamento (stor-

age)
O balanceamento do suporte de armazenamento permite distribuir o acesso a sis-
temas de arquivos por varios discos, pelo que derivam ganhos
obvios em tempos
acesso. Estas soluc
oes podem ser dedicadas ou existir em cada um dos servi-
dores do cluster. As soluc
oes existentes hoje s
ao implementadas em hardware,
dentre elas podemos citar as tecnicas RAID (Redundant Arrays of Independent
Disks) , SAN (Storage Area Network) e NAS (Network-Attached Storage).
53.2 Balanceamento de rede

O balanceamento da utilizacao da rede passa sobretudo por reencaminhar o
tr
afego por caminhos alternativos a fim de descongestionar os acessos aos servi-
dores.O mecanismo/dispositivo respons avel pelo balanceamento e chamado de
director. Na verdade, ele pode existir sob v arias formas, dependendo do(s)
servico(s) que se pretende balancear. Este director serve tambem de interface
entre o cluster de servidores e os clientes do(s) servico(s) - tudo o que os clientes
conhecem e o endereco semi-p ublico deste servidor. Esta abordagem (cl assica)
e algo limitada, em termos de escalabilidade e n umero de tramas que o direc-
tor consegue redireccionar, principalmente devido ` a velocidade dos barramentos
das placas de rede. Existem, no entanto, outras soluc oes mais complexas que
tiram melhor partido das caractersticas do protocolo TCP/IP em conjunto com
um roteamento de pacotes especializado, tais como NAT, IP Tunneling e Direct
436
Routing. Outras soluc

oes operam exclusivamente em apenas algumas camadas
(nveis) do modelo OSI no nvel 4, 5, 6 e 7.
53.2.1 NAT
Em redes de computadores, NAT, Network Address Translation, tambem con-
hecido como masquerading e uma tecnica que consiste em reescrever os enderecos
IP de origem de um pacote que passam sobre um router ou firewall de maneira
que um computador de uma rede interna tenha acesso ao exterior (rede p ublica).
Utilizamoe s seguinte situac

ao como exemplo. A estac ao com IP 192.168.1.13
faz uma requisicao, por exemplo, para um endereco externo. O pacote sai
com o IP da estacao e corre em direc ao ao intermediador entre o ambiente in-
terno e externo, o gateway. O gateway, atraves do protocolo NAT mascara o
IP da estac
ao com seu IP (200.158.112.126 - que e v alido na internet) assim
fazendo com que o pacote seja entregue no destino solicitado pela estac ao. No
retorno do pacote, ele parte do endereco externo, chega a nossa rede no servidor
NAT (200.158.112.126) e l a volta ate o IP da estac
ao assim chegando à estac
ao
(192.168.1.13).
Figura 53.1: Balanceamento de carga NAT
53.2.2 IP Tunneling
Um IP Tunnel e um termo tecnico para designar o encapsulamento de um pa-

cote IP dentro de outro, com o proposito de simular uma conex
ao fsica entre
duas redes remotas atraves de uma outra rede.
Este processo e frequentemente usado com o protocolo IPsec para criar um

meio de conectar duas redes usando uma VPN. O meio para que essas duas
redes se vejam e, tipicamente, a Internet. Dessa forma o fator limitador que
e a dist
ancia e praticamente eliminado, permitindo a utilizadores de uma rede
disp
or dos recursos de outra rede remota como se fossem locais.
437
53.2.3 Direct Routing

A figura 53.2 mostra como o Direct Routing funciona.
Figura 53.2: Balanceamento de carga com Direct Routing.
53.3 Algoritmos de balanceamento

Round-Robin: Distribui cada requisic
ao sequencialmente entre servidores
reais. Usando este algoritmo, todos os servidores s
ao tratados igualmente
sem considerar sua capacidade ou carga;
Weighted Round-Robin Scheduling: Distribui cada requisic ao seq
uencialmente
entre servidores reais, mas d
a mais requisic
oes para servidores com mais
capacidade;
Least-Connection: Distribui mais requisicoes para servidores com menos
conex
oes ativas. Por ele manter um hist orico de conex
oes ativas atraves
da tabela IPVS, least-connection e um tipo de algoritmo de escalonamento
din
amico, sendo a melhor escolha se ha um alto grau de variac
ao na carga
do pedido. Se h a um grupo de servidores com diferentes capacidades,
weighed least-connection e a melhor escolha;
Weighted Least-Connections (default): Distribui mais requisic oes para

servidores com poucas conexoes ativas em relac

ao `
a sua capacidade. Este
algoritmo e ideal quando os servidores contem hardware de capacidade
variedade;
Destination Hash Scheduling: Distribui requisicoes para os servidores
procurando o endereco IP de destino numa tabela hash est atica. Este
algoritmo e projetado para us
a-lo em um servidor de proxy-cache;
Source Hash Scheduling: Distribui requisic

oes para os servidores procu-
rando o endereco IP de origem numa tabela hash est
atica. Este algoritmo
e projetado para roteadores LVS (Linux Virtual Server) com m ultiplos
438
firewalls. O LVS e uma soluc

ao de balanceamento de carga para sis-
temas Linux. Basicamente, conta com um software para balancemaneto
IP (IPVS) e um para balanceamento na camada de aplicac
ao (KTCPVS).
53.4 Balanceamento de CPU

Este tipo de balanceamento e efectuado pelos sistemas de processamento dis-
tribudo e consiste, basicamente, em dividir a carga total de processamento pelos
v
arios processadores no sistema (sejam eles locais ou remotos).
53.4.1 Sistema de processamento distribudo

Um sistema de processamento distribudo ou paralelo e um sistema que interliga
v
arios n
os de processamento (computadores individuais, n ao necessariamente
homogeneos) de maneira que um processo de grande consumo seja executado
no no mais disponvel, ou mesmo subdividido por v arios nos. Adivinham-se,
portanto, ganhos obvios nestas soluc
oes: uma tarefa qualquer, se divisvel em
v
arias subtarefas pode ser realizada em paralelo.
A nomenclatura geralmente utilizada neste contexto e HPC (High Per-

formance Computing) e/ou DPC (Distributed/Parallel Computing).//
Com os desenvolvimentos nesta area, surgiram soluc
oes por software que fazem,
geralmente (mas n ao necessariamente), alterac
oes no nucleo do sistema opera-
cional e que, na maioria dos casos, nao s
ao compatveis entre elas, e dificilmente
entre versoes diferentes da mesma solucao. Assentam, no entanto, em arquitec-
turas de comunicac ao standard, como e o caso da Parallel Virtual Machine e
Message Passing Interface. Resumidamente, estas arquiteturas conseguem
transportar um processo (tarefa) e o seu contexto (arquivos abertos, etc.) pela
rede ate outro no. O no que originou o processo passa, assim, a ser apenas um
receptor dos resultados desse processo.
Atualmente, a principal barreira destes sistemas e implementar mecanismos

de Inter-Process Communication (IPC), os Distributed IPC, dada a sua
extrema complexidade.
A figura 53.3 ilustra as v

arias camadas de interoperabilidade de um sistema
distribudo. Atraves do gateway a rede p
ublica tem acesso a um supercomputa-
dor, sem ter conhecimento disso, dado que s o conhece o gateway. Qualquer
aplicac
ao executada no gateway (preparada para ser paralelizada) pode ser dis-
tribuda por v
arios nos, entregando os resultados mais rapido do que se fosse
processada por apenas um n o.
Parallel Virtual Machine

PVM e a abreviac
ao de Parallel Virtual Machine. Este e um pacote de soft-
ware que permite que uma rede heterogenea de computadores de todos os tipos
seja programada como se fosse apenas uma u nica M
aquina Paralela Virtual.
A programac
ao e baseada no paradigma de troca de mensagens. O PVM e
439
Figura 53.3: Sistema de processamento distribudo.
composto, basicamente, de tres partes: uma biblioteca de funcoes (em C e em

FORTRAN77) que implementam para o usu ario as diretivas de programac
ao
da M aquina Virtual (MV); um processo daemon que rodar a em cada host par-
ticipante da MV e um console de onde podem ser executadas algumas func oes
basicas de controle (configurac
ao da MV, gerenciamento de tarefas, etc.).
A implementacao do PVM e baseada em processos do Unix. Na verdade,

cada tarefa PVM e um processo Unix. Isto explica parcialmente a alta porta-
bilidade do sistema para computadores de arquiteturas t ao diferentes. Tarefas
s
ao as unidades basicas de execuc
ao do PVM. E verdade que, em algumas im-
plementac
oes, as tarefas podem n ao ser processos. Nestes casos, cabera ao
implementador garantir a compatibilidade (tais excec oes s
ao mais comuns em
sistemas de natureza mais complexa como computadores paralelos).
Os programas em PVM podem rodar espalhados por uma rede de natureza

heterogenea. Mais particularmente, e possvel disparar tarefas em computadores
em qualquer parte da Internet (desde que o usu ario tenha acesso a esta maquina,
obviamente). Esta independencia em relac ao à rede de comunicacoes que liga
os hosts que participam da MV e garantida pelo uso do protocolo TCP/IP para
comunicacao entre as tarefas atraves da rede.
O pacote PVM e relativamente pequeno (cerca de 4.5 MB de c odigo fonte em

C), e necessita ser instalado apenas uma vez em cada m aquina para ser acessvel
a todos os usu
` arios. Alem disso, a instalac
ao n
ao requer privilegios especiais e
pode ser efetuada por qualquer usu ario.
Message Passing Interface

Message Passing Interface (MPI) e um padr ao para comunicac ao de dados em
computacao paralela. Existem v arias modalidades de computac ao paralela, e
dependendo do problema que se est a tentando resolver, pode ser necess
ario pas-
sar informac
oes entre os v
arios processadores ou nodos de um cluster, e o MPI
oferece uma infraestrutura para essa tarefa.
440
No padrao MPI, uma aplicac ao e constituda por um ou mais processos

que se comunicam, acionando-se func oes para o envio e recebimento de men-
sagens entre os processos. Inicialmente, na maioria das implementac oes, um
conjunto fixo de processos e criado. Porem, esses processos podem executar
diferentes programas. Por isso, o padr ao MPI e algumas vezes referido como
MPMD (multiple program multiple data). Elementos importantes em imple-
mentac
oes paralelas sao a comunicacao de dados entre processos paralelos e o
balanceamento da carga. Dado o fato do n umero de processos no MPI ser nor-
malmente fixo, neste texto e enfocado o mecanismo usado para comunicac ao de
dados entre processos. Os processos podem usar mecanismos de comunicac ao
ponto a ponto (operac oes para enviar mensagens de um determinado processo
a outro). Um grupo de processos pode invocar operac oes coletivas (collective)
de comunicacao para executar operac oes globais. O MPI e capaz de suportar
comunicacao assncrona e programac
ao modular, atraves de mecanismos de co-
municadores (communicator) que permitem ao usu ario MPI definir m odulos que
encapsulem estruturas de comunicac ao interna.
441
Parte X
Sistemas Operacionais
442
Captulo 54
Ambiente Microsoft
Windows 2000/2003
54.1 DHCP - Dynamic Host Configuration Pro-

tocol
A implementac ao do DHCP no Windows 2000/2003 Server e baseada em padr oes
definidos pelo IETF - Internet Engineering Task Force. Por padr ao, este servico
e instalado durante a instalac
NAO ao tpica do Windows 2000/2003 Server. E
importante ressaltar que este servico nao pode ser instalado nos Windows 98,
Me, 2000 Professional, XP Professional, XP Home, Vista, etc. J a os clientes
DHCP podem ser quaisquer hosts baseados no Microsoft Windows.
A maioria das tarefas de administrac ao do DHCP pode ser executada no

console DHCP, que e acessado atraves de: Iniciar >> Programas >> Ferramen-
tas Administrativas >> DHCP. Inclusive, e possvel utilizar um u nico console
DHCP para se conectar, remotamente atraves da rede, com diferentes servi-
dores DHCP. Por padr ao, a maior parte das informac
oes (log e banco de dados)
deste servidor e armazenada na pasta \%windir%\System32\dhcp, onde windir
se refere `
a pasta onde o Windows foi instalado.

ao/Configurac
ao
O processo de instalac ao se d
a seguindo os passos: Iniciar >> Configurac oes
>> Painel de Controle; Adicionar ou Remover Programas; Adicionar ou Re-

mover Componentes do Windows. O DHCP e classificado como um SERVIC O
DE REDE (Networking Services). Ap os a instalac
ao, n
ao e preciso reinicializar
o servidor para que o servico possa ser disponibilizado, basta seguir alguns pro-
cedimentos obrigat orios que ser
ao mencionados abaixo. Lembrando que este
servico e configurado para executar no contexto da conta LOCAL SYSTEM.
Ap
os ter instalado o servidor DHCP, o PROXIMO PASSO e autorizar o
servidor DHCP no Active Directory. Somente membros do grupo Enterprise
Admins (Administradores de empresa) tem permissao para autorizar um servi-
dor DHCP no Active Directory. A autorizac
ao obrigat
oria no Active Directory
443
e uma medida de seguranca para evitar que servidores DHCP secundarios se-
jam introduzidos na rede sem o conhecimento do administrador. O caminho a
ser seguido e o: Iniciar >> Programas >> Ferramentas Administrativas >>
DHCP; clique no nome do servidor DHCP; Selecione o comando Acao >> Au-
torizar.
Agora que o servidor DHCP est a devidamente instalado e autorizado no

Active Directory sera necess
ario a criacao de um ou mais ESCOPOS. Para
criar e configurar um escopo e utilizado o console de administrac
ao do DHCP:
Iniciar >> Programas >> Ferramentas Administrativas >> DHCP. Algumas
propriedades importantes que devem ser configuradas neste passo s ao:
Escopo DHCP: uma faixa especfica de enderecos IP que deve estar dentro
da faixa de enderecos da rede onde o servidor DHCP ser a utilizado. Mais
de um escopo pode ser definido para uma rede (10.10.20.0/255.255.255.0),
por exemplo: 10.10.10.20.30 a 10.10.20.100; 10.10.10.20.120 a 10.10.20.150;
e 10.10.10.20.200 a 10.10.20.250. Cada escopo definira uma sub-rede. Para
cada escopo, e necess
ario configurar uma serie de par
ametros: m ascara de
sub-rede, default gateway, endereco IP de um ou mais servidores DNS,
endereco IP do servidor WINS e assim por diante;
Intervalos de Exclusao: uma faixa especfica de enderecos IP para retirar
de um escopo, ou seja, enderecos que voce n ao quer que sejam concedi-
dos aos clientes da rede. Lembrando que enderecos IPs excludos podem
estar ativos na sua rede, como por exemplo, em computadores ou outros
dispositivos de rede configurados manualmente (IP fixo);
Pool de Enderecos: conjunto de enderecos especificados no escopo DHCP
descontando os eventuais intervalos de exclus
ao. Enfim, os enderecos que
ser
ao cedidos automaticamente aos clientes do servico;
Intervalo de Duracao da Concess ao: especifica por quanto tempo um
cliente DHCP pode usar um endereco IP atribudo antes que seja necess
ario
renovar a configurac
ao com o servidor DHCP;
Enderecos Reservados: concess ao permanente a hosts especificados na sua
rede. Cada reserva de IP e associada ao MAC Address da interface de rede
do host em questao. Vale ressaltar que os enderecos reservados devem estar
fora do intervalo de exclusao.
Apos definir e configurar um escopo, ele deve SER ATIVADO antes que o
servidor DHCP comece a fazer concess oes aos clientes. No entanto, voce n
ao
deve ativar um novo escopo ate ter especificado as opc
oes DHCP para ele (de-
fault gateway, numero IP do servidor DNS e assim por diante).
Entao, o processo de instala

c
ao como um todo pode ser resumido
em: instalar servidor DHCP; ativ a-lo no Active Directory; criar e
configurar o Escopo; e por fim ativar o Escopo.
importante notar que as opc

E oes do DHCP (default gateway, endereco IP
de um ou mais servidor DNS e assim por diante), podem ser configuradas em
tres nveis: servidor (s
ao v
alidas para todos os escopos configurados no servidor
444
DHCP); escopo (se aplicam a um escopo especificamente) e opc oes de uma

reserva (se aplicam a reserva e, por padr
ao, s
ao herdadas do escopo onde a
reserva foi criada).
54.1.2 Integra
c
ao do DHCP com o DNS
O servidor DHCP pode ser utilizado para fazer atualizac oes din
amicas no DNS,
em nome dos clientes DHCP. Ou seja, quando um cliente DHCP e inicializado
e obtem uma concess ao de endereco, o DHCP pode atualizar os registros de
recurso de endereco (A) e ponteiro (PTR) do cliente, na base de dados do DNS.
Esse processo exige o uso de uma opc ao de DHCP adicional, a opc
ao FQDN do
Windows. Essa opc ao permite ao cliente fornecer seu nome de domnio total-
mente qualificado (FQDN) e instruc oes para o servidor DHCP sobre como deseja
que o servidor processe atualizac
oes dinamicas de DNS (se houver) em seu nome.
Clientes baseados em Windows XP ou Windows Server 2000/2003 atualizam

automaticamente os registros do tipo A na zona direta do DNS. Ou seja, n ao
e necess aria nenhuma integracao entre DNS e DHCP para isso acontecer. J a
para os registros da zona reversa (registros PTR), a hist
oria e diferente. Esses
clientes nao conseguem atualizar seus registros PTR diretamente, esta atual-
izac
ao tem que ser feita pelo servidor DHCP.
Clientes mais antigos, baseados em Windows 95, 98, Me ou NT 4.0, n

ao sao
capazes de atualizar dinamicamente nem seus registros A, nem seus registros
PTR no DNS. Para estes clientes, o servidor DHCP atualiza ambos os registros
no servidor DNS.
54.1.3 APIPA - Automatic Private IP Addressing

Esta e uma funcionalidade que foi introduzida no Windows 98. Ela tambem
est
a presente no Windows XP, Vista, Longhorn Server e no Windows Server
2000/2003. Se os clientes estiverem configurados para usar um servidor DHCP
(em vez de serem configurados manualmente com um endereco IP e outros
parametros), o servico do cliente DHCP entrar a em funcionamento a cada vez
que o computador for inicializado. O servico do cliente DHCP usa um processo
de tres etapas para configurar o cliente com um endereco IP e outras informac
oes
de configuracao:
O cliente DHCP tenta localizar um servidor DHCP e obter as configurac

oes
do protocolo TCP/IP, a partir desse servidor;
Se um servidor DHCP n ao puder ser encontrado, o cliente DHCP con-

figura automaticamente seu endereco IP e m ascara de sub-rede usando
um endereco selecionado da rede classe B reservada, 169.254.0.0, com a
m ascara de sub-rede, 255.255.0.0 (RECURSO APIPA). O cliente DHCP
ir
a fazer uma verificacao na rede, para ver se o endereco que ele est a se
auto-atribuindo j a nao est
a em uso na rede. Se o endereco j a estiver em
uso sera caracterizado um conflito de enderecos. Se um conflito for encon-
trado, o cliente selecionara outro endereco IP. A cada conflito de endereco,
o cliente ir
a tentar novamente a configurac ao autom atica escolhendo um
445
novo endereco IP. Ap

os 10 tentativas o cliente tenta novamente localizar
um servidor DHCP;
Depois de selecionar um endereco no intervalo de rede 169.254.0.0 que n ao

est
a em uso, o cliente DHCP ir a configurar a interface com esse endereco.
O cliente continua a verificar se um servidor DHCP n ao est
a disponvel.
Esta verificac
ao e feita a cada cinco minutos. Se um servidor DHCP for
encontrado, o cliente abandonar a as informac
oes configuradas automati-
camente e usar a um endereco oferecido pelo servidor DHCP (e quaisquer
outras informac oes de opc
oes de DHCP fornecidas).
54.1.4 Comandos ipconfig Relacionados ao DHCP

Os principais comandos relacionados ao DHCP e suas funcionalidades s ao: (1)
ipconfig /release: para liberar a concessao (release) do cliente; (2) ipconfig /re-
new: para renovar a concess ao do cliente; (3) ipconfig: para obter informac oes
basicas sobre as configurac
oes do protocolo TCP/IP; (4) ipconfig /all: exibe
informacoes detalhadas sobre as configuracoes do protocolo TCP/IP em todas
as interfaces do computador.
Clientes mais antigos como o Windows 95, 98 ou Me, n ao disponibilizam o

comando ipconfig. Nestes clientes, voce pode utilizar o comando WINIPCFG
para verificar as configurac
oes do protocolo TCP/IP e para liberar ou renovar
uma concess ao do servidor DHCP.
54.1.5 Regra 80/20

Para equilibrar o uso do servidor DHCP, uma boa pr atica e usar a REGRA
80/20 para dividir os enderecos do escopo entre dois servidores DHCP. Se o
Servidor 1 estiver configurado para disponibilizar a maioria (aproximadamente
80%) dos enderecos, o Servidor 2 pode ser configurado para disponibilizar os
outros enderecos (aproximadamente 20%) para os clientes.
54.2 DNS - Domain Name System

A implementac ao do DNS no Windows 2000/2003 Server e baseada em padr oes
definidos pelo IETF - Internet Engineering Task Force. Por padr ao, este servico
e instalado durante a instalac
NAO ao tpica do Windows 2000/2003 Server. E
importante ressaltar que este servico nao pode ser instalado nos Windows 98,
Me, 2000 Professional, XP Professional, XP Home, Vista, etc. J a os clientes

DNS podem ser quaisquer hosts baseados no Microsoft Windows.
A maioria das tarefas de administrac

ao do DNS pode ser executada no con-
sole DNS, que e acessado atraves de: Iniciar >> Programas >> Ferramen-
tas Administrativas >> DNS. Inclusive, e possvel utilizar um u nico console
DNS para se conectar, remotamente atraves da rede, com diferentes servi-
dores DNS. Por padr ao, a maior parte das informac oes (lista de servidores
ROOT HINTS e informac oes sobre zonas) deste servidor e armazenada na pasta
\%windir%\System32\Dns, onde windir se refere ` a pasta onde o Windows foi
instalado.
446

ao/Configurac
ao
O processo de instalac ao se d
a seguindo os passos: Iniciar >> Configurac oes
>> Painel de Controle; Adicionar ou remover programas; Adicionar ou Re-
mover Componentes do Windows. O DNS e classificado como um SERVIC O
DE REDE (Networking Services). Ap os a instalac
ao, n
ao e preciso reinicializar
o servidor para que o servico possa ser disponibilizado. Lembrando que este
servico e configurado para executar no contexto da conta LOCAL SYSTEM.
Apos a instalac
ao do servidor DNS, o PROXIMO PASSO e criar uma ZONA

PRIMARIA DIRETA. Por exemplo, vamos supor que voce est a implementando
a estrutura de DNS da rede da sua empresa, cujo domnio root e abc.com.br.
A zona e chamada prim aria porque ela ainda nao existe e esta sendo criada
para conter as informac oes do domnio. Ela e chamada direta, porque conter a
informac
oes para resoluc ao de nomes para endereco IP, ou seja, fornecido um
nome no domnio abc.com.br, esta zona conter a informac
oes para retornar o
endereco IP associado a este nome.
A maioria das consultas realizadas sao as chamadas consultas diretas (For-

ward Lookup). Neste tipo de consulta, o cliente fornece um nome e o servidor
DNS retorna um endereco IP associado a esse nome. O DNS tambem d a suporte
as chamadas consultas inversas (Reverse Lookup), na qual o cliente fornece um
`
endereco IP v
alido e o servidor DNS retorna o nome associado a esse endereco
IP. Originalmente o DNS n ao foi projetado para dar suporte `
as consultas re-
versas. Pela maneira hier arquica como o DNS e organizado, a u nica maneira
para responder este tipo de consulta seria pesquisar todos os servidores DNS
existentes no mundo. O que faria com que o tempo de consulta fosse muito
elevado, inviabilizando o uso de pesquisas reversas.
Para resolver esta questao foi criado um domnio especial chamado de IN-
ADDR.ARPA. Este domnio faz parte das definic oes atuais do DNS e foi a
maneira encontrada para fornecer a resoluc ao reversa de nomes sem que hou-
vesse a necessidade de pesquisar em todos os servidores DNS. Para criar o espaco
de nomes reverso, sao criados subdomnios do domnio especial in-addr.arpa. Os
nomes destes subdomnios s ao formados pela ordem inversa do n umero IP da
rede. Por exemplo, considere a rede 100.20.50.0/255.255.255.0. A zona para res-
oluc
ao reversa desta rede seria 50.20.100.in-addr.arpa. E importante ressaltar
que o uso de domnios in-addr.arpa e aplicado a todas as redes baseadas no
protocolo IPv4. Ou seja, este uso n ao e uma particularidade dos sistemas Win-
dows. Outro aspecto relevante e o fato dos mecanismos de recurs ao e interac

ao
tambem serem utilizados para a resoluc ao reversa.
Quando voce cria uma zona pela primeira vez, ela e uma zona prim aria.
Somente na zona prim aria e permitido fazer alterac oes nos registros da zona.
Alem da zona prim aria, o DNS permite que sejam feitas c opias da zona em out-
ros servidores DNS. Estas c opias s
ao as ZONAS SECUNDARIAS. Por exemplo,
voce pode ter uma zona primaria no servidor DNS da matriz da empresa e criar
uma zona secund aria (c
opia da zona prim aria), nos servidores DNS de cada fil-
ial, para reduzir o tr
afego, devido à resoluc
ao de nomes DNS, nos links de WAN.
As zonas secund arias tambem s ao reconhecidas como AUTORIDADES para o
447
domnio em quest ao e podem responder ` as consultas enviadas pelos clientes. A

u
nica diferenca, em relacao à zona prim aria, e que nas zonas secund arias nao
podem ser feitas alterac oes, adic
oes e exclusoes de registros de recursos. Sem-
pre que houver alterac oes, o servidor DNS onde est a a zona prim aria, notifica
os servidores DNS onde existem zonas secund arias e, ent
ao, os servidores DNS
da zona secund ario solicitam que as alterac oes sejam envidas a partir da zona
primaria. Com isso o DNS mantem as zonas sincronizadas, ou seja, alterac oes
feitas nas zonas prim arias s
ao repassadas para as zonas secund arias. O DNS
usa um mecanismo de REPLICAC INCREMENTAL, ou seja, somente as
AO
alterac
oes s
ao replicadas e n ao todo o conteudo da zona.
Por padr ao, quando o servidor DNS e instalado, uma lista chamada ROOT
HINTS e criada e gravada em um arquivo chamado Cache.dns localizado na
pasta \%windir%\System32\Dns. Esta lista armazena informac oes dos servi-
dores para o domnio root (representado pelo ponto .) e para os domnios de
nvel superior (.com, .net, .gov, etc.). Este recurso garante a interac
ao entre
servidores DNS ao redor do mundo de forma a ser possvel a resoluc ao de qual-
quer FQDN (Nome de Domnio Totalmente Qualificado).
Apos a instalac
ao e configurac
ao do servidor DNS e necess
aria a criac
ao de
novos registros de recursos. No Windows 2000/2003 Server, foram dados os
seguintes nomes para os campos do registro de recursos: Owner; Time to Live;
Class; Type; Record-specific data. Alem dos tipos de registros padr ao IPv4,
tambem s ao suportados outros tipos, como por exemplo, o tipo AAAA que
define um mapeamento de um nome DNS em um endereco de host no padr ao
IPv6. (ipv6 host1.example.microsoft.com. IN AAAA 4321:0:1:2:3:4:567:89ab).
Nos CLIENTES Windows 2000/2003 Server, a configurac ao do DNS envolve as
seguintes tarefas (ao configurar as propriedades do TCP/IP do cliente):
Configurar um nome (de host) DNS para cada computador;
Configurar um sufixo DNS prim

ario para o computador, que e posicionado
ap
os o nome de host para formar o FQDN. Por exemplo, abc.com.br;
Configurar uma lista de servidores DNS que ser ao usados pelos clientes
para resolver nomes DNS. Vale ressaltar que a lista sempre e utilizada de
forma sequencial, ou seja, primeiramente o primeiro servidor da lista e
consultado. Caso este esteja offline ou haja problemas na comunicacao, o
cliente consultar
a o pr
oximo servidor da lista e assim por diante;
Configurar a lista ou metodo de pesquisa de sufixo DNS a ser usado

pelo cliente quando ele executar pesquisas de consultas DNS para nomes
de domnio curtos n ao qualificados. Alem do sufixo DNS prim ario, po-
dem ser adicionados sufixos especficos, por exemplo, vendas.abc.com.
Desta forma, ao se fazer uma consulta do tipo xyz (nome n ao totalmente
qualificado), na verdade, ser a consultado xyz.vendas.abc.com (sufixo es-
pecfico) e se nao houver exito tambem ser
a consultado xyz.abc.com (su-
fixo prim ario);
448
54.2.2 Seguran
ca de Acesso
Voce pode definir configuracoes de seguranca para limitar o acesso ` as con-
figurac
oes dos servidores DNS. Por padr ao, os grupos Domain Admins (Ad-
ministradores do domnio), Enterprise Admins (Administradores de empresa),
DNS Admins (Administradores do DNS) e o grupo Administrators tem per-
missao de controle total nos servidores DNS. Voce pode retirar as permiss oes
de todos os grupos deixando apenas as permiss oes do grupo DNS Admins (e
talvez tambem a do grupo Administrators). Com isso, voce pode controlar
quais usu arios podem fazer alterac
oes nos servidores DNS por meio da inclus ao
destes usu arios no grupo DNS Admins. E muito IMPORTANTE notar que e
necessario manter as permissoes padr ao de acesso a servidor DNS atribudas ao
grupo Authenticated Users (Usu arios Autenticados). Se voce retirar este grupo,
os usu arios da rede n
ao conseguirao ler informac
oes no servidor DNS, ou seja,
as consultas dos clientes n
ao ser
ao respondidas. Na pr atica e como se o servidor
DNS estivesse desligado.
54.2.3 Integra
cao do DNS com o Active Directory
Outro controle que e muito importante e em relacao `
as quais clientes ter
ao per-
missao para incluir registros dinamicamente no DNS. Sem um controle de quem
pode fazer atualizacoes din
amicas, um usu ario mal intencionado poder a regis-
trar uma serie de registros falsos ou ate mesmo registrar milhares de registros
em um ataque do tipo Denial of Service, apenas com o objetivo de paralisar
o servidor DNS e com isso os servicos que dependem do DNS. No Windows
2000/2003 Server voce pode fazer com que o DNS somente aceite atualizac oes
din
amicas enviadas por hosts autenticados no domnio, proporcionando assim
uma maior seguranca no acesso ` as informac
oes das zonas do DNS. Este tipo
de atualizac
ao e conhecido como Atualizac ao Dinamica Segura (Security Dy-
namic Update). Porem, este tipo de atualizac ao somente est a disponvel em
zonas DNS integradas com o Active Directory, onde voce pode definir uma lista
de permissao de acesso (semelhante a uma lista de permiss oes NTFS em uma
pasta).
Existem dois pontos fundamentais a serem considerados na integrac

ao do
DNS com o Active Directory:
O DNS e necess
ario, obrigat
orio, para localizac
ao dos DCs (Controladores
de Domnio) do domnio;
O servico Netlogon usa o novo suporte ao servidor DNS para fornecer

registro de controladores de domnio no seu espaco de nomes de domnio
DNS. Enfim, sua func
ao basica e executar registros a cerca do AD no DNS.
A integrac
ao inicia no momento da instalac ao do Active Directory em um
member server para torn a-lo um DC. O assistente de instalac ao do Active Di-
rectory solicita que voce informe o nome DNS do domnio para o qual est a sendo
criado um novo DC. Durante a instalac ao o assistente deve ser capaz de se conec-
tar a um servidor DNS que seja AUTORIDADE para o domnio informado. Se
isso n
ao for possvel, o assistente ir
a se oferecer para instalar e configurar o DNS
no proprio servidor que est a sendo promovido a DC. Se isso tambem n ao for
449
possvel, o Active Directory n

ao poder
a ser instalado.
Depois que o Active Directory estiver instalado, existem duas opc

oes para o
tipo de armazenamento e duplicac
ao de zonas do DNS:
Armazenamento de zona padr ao usando um arquivo baseado em texto: as

zonas armazenadas dessa maneira est ao localizadas em arquivos de texto,
com a extens ao .dns, os quais s
ao armazenados na pasta \%windir%\System32\Dns
em cada computador que opera um servidor DNS. Os nomes de arquivo
de zona correspondem ao nome que voce escolhe para a zona durante a
sua criac
ao, como Exemplo. abc.com.br.dns e o arquivo que armazena
informacoes para a zona abc.com.br;
Armazenamento de zona integrada ao diret orio usando o banco de dados

do Active Directory: as zonas armazenadas dessa maneira est ao local-
izadas na arvore do Active Directory. Cada zona integrada ao diret orio
e armazenada em um objeto do tipo dnsZone identificado pelo nome que
voce escolhe para a zona durante a sua criac
ao.
Em redes que distribuem o DNS para oferecer suporte ao Active Directory,

as zonas prim
arias integradas ao diretorio s
ao especialmente recomendadas e
proporcionam os seguintes benefcios:
Atualizacoes multi-master e recursos de seguranca avancada baseados nos

recursos do Active Directory. Para ZONAS NAO INTEGRADAS, o mod-
elo de atualizac
ao e do tipo single-master. Neste u ltimo, somente a zona
primaria sofre alterac
oes e repassa estas alterac
oes para as zonas secund
arias.
Se o servidor onde est a a zona prim aria apresentar problemas, novas at-
ualizac
oes din
amicas n ao poderao ser processadas enquanto este servidor
n
ao for recuperado. J a com ZONAS INTEGRADAS, podem ser feitas
alterac
oes em qualquer c opia da zona e existe uma c opia em todos os DCs
do domnio onde o DNS estiver instalado. O mecanismo de replicac ao do
Active Directory se encarrega de manter as v arias c
opias sincronizadas;
Com esse modelo, n ao haver

a um ponto u nico de falha (como no caso do
modelo baseado em zonas padr ao), pois qualquer servidor DNS poder a
receber atualizac
oes din
amicas enviadas pelos clientes;
Outra vantagem das zonas integradas e que todo objeto do Active Direc-
tory possui uma ACL - Access Control List (identica `
a lista de permiss
oes
NTFS para uma pasta ou arquivo). Esta lista pode ser editada para ter
um controle mais refinado sobre quem tem acesso e qual o nvel de acesso;
A replicac
ao do Active Directory e mais r
apida, mais eficiente e mais
segura do que o mecanismo de transferencia de zonas padr
ao do DNS.
Nota: Apenas as zonas prim arias podem ser armazenadas no Active Direc-
tory. Um servidor DNS nao pode armazenar zonas secund
arias no diret
orio. Ele
devera armazen
a-las em arquivos de texto padr
ao.
450
54.2.4 Servidor DNS somente Cache

Um servidor DNS somente cache e um servidor que n ao tem nenhuma zona
configurada. A func
ao deste servidor e resolver consultas utilizando os metodos
de recurs
ao e/ou interac
ao e armazenar os resultados obtidos no cache do servi-
dor DNS. O cliente envia a consulta para o servidor DNS somente cache, este
servidor se utiliza de outros servidores DNS para resolver o nome. O nome
e armazenado no cache do servidor DNS somente cache e a resposta e retor-
nada para o cliente que fez a consulta. Futuras consultas a este mesmo nome,
dentro do perodo de expiracao, ser
ao respondidas com base nas informac oes
do cache do servidor DNS. Este tipo de servidor deve ter quantidade suficiente
de mem oria RAM para exercer esta func ao, pois toda a informacao do cache
do DNS e criada e mantida na mem oria RAM do servidor. Portanto, o servi-
dor DNS somente cache NAO ARMAZENA NENHUMA ZONA E NAO EH
AUTORIDADE para nenhum domnio.
54.2.5 Arquivo Hosts

Se n
ao for encontrada a resposta no cache local do DNS, o programa resolvedor
consulta as entradas do arquivo hosts. Este e um arquivo texto que fica na pasta
onde o Windows 2000/2003 Server foi instalado, dentro do seguinte caminho:
\system32\drivers\etc. Este arquivo possui entradas do tipo: um n umero IP
por linha associado a um ou mais nomes:
10.200.200.3 www.abc.com.br intranet.abc.com.br

10.200.200.4 ftp.abc.com.br arquivos.abc.com.br
54.2.6 Distribui
cao de Carga
Por padr ao, o servico DNS usa a atribuic
ao de prioridades a sub-redes locais
como o metodo para dar preferencia a enderecos IP da mesma rede quando uma
consulta de cliente e resolvida para um nome de host que esta mapeado a mais
de um endereco IP. Ou seja, se o cliente enviou uma consulta para um nome e
existem, por exemplo, dois enderecos IP associados a este nome, o servidor DNS
dara preferencia ao endereco IP que for da mesma rede do cliente que enviou
a consulta. Esse recurso permite que o aplicativo do cliente se conecte ao host
que esteja usando seu endereco IP mais proximo (e normalmente o mais rapido).
Round Robin e o algoritmo de rotac ao utilizado pelo Windows 2000/2003

Server para a realizac

ao da distribuic
ao de carga entre dois ou mais servidores
DNS da rede. Vale ressaltar que a atribuic ao de prioridade a sub-rede locais
substitui o uso da rotac
ao Round Robin para nomes com v arios enderecos IP as-
sociados. Entretanto, quando o recurso Round Robin est a ativado, ele continua
sendo utilizado como metodo de classificacao secundaria. Ou seja, caso haja um
nome associado a v arios enderecos IP nao pertencentes à rede local, o algoritmo
de Round Robin e utilizado para determinar qual endereco ser a retornado.
54.2.7 Comando ipconfig/dnscmd Relacionadas ao DNS

Os principais comandos relacionados ao DNS e suas funcionalidades s
ao:
451
ipconfig /flushdns: limpar o cache local;

ipconfig /displaydns: exibir o cache local;
ipconfig /registerdns: forca o registro das informac

oes do host no servidor;
dnscmd /clearcache: limpar o cache do servidor DNS (executado no servi-
dor).
54.3 Active Directory

Antes de falar em Active Directory, e necess
ario discursar sobre o LDAP (Lightweight
Directory Access Protocol). Este e um protocolo padr ao inicialmente projetado
para o acesso a servicos de diret
orio X.500 da International Standards Orga-
nization (ISO). O LDAP e a vers ao reduzida de um protocolo chamado DAP
(Directory Access Protocol). A principal func ao do DAP era a de estabelecer,
de forma padr ao, regras de comunicac ao de acesso com um diret orio baseado
no padrao X.500, mas por ser complexo permitiu o surgimento do LDAP que
implementa apenas as operac oes b asicas do DAP. A saber: Bind, Read, List,
Search, Compare, Modify, Add, Delete e ModifyRDN.
Em outras palavras, o LDAP e simplesmente um protocolo encarregado por

definir a maneira atraves da qual se realizam as pesquisas em uma base de da-
dos. Inicialmente, o LDAP foi criado somente para servir de interface entre os
clientes que queriam fazer consultas ao servidor X.500. Isto foi decorrente das
deficiencias que este protocolo tinha e de sua extrema lentidao. Mais adiante
se concluiu que, como a maioria das consultas chegava normalmente atraves da
interface LDAP, seria muito mais vantajoso utilizar o LDAP como um servico
independente de diret orio sem a necessidade de utilizar o X.500.
Um diret orio e uma base de dados estruturada hier arquica contendo difer-
entes tipos de informac oes e oferece uma versatilidade muito grande na hora de
buscar a informac ao desejada. Um servico de diretorio contem informac
oes em
forma de entradas. Cada entrada contem uma serie de dados (atributos). Uma
boa analogia seria uma lista telef onica, que contem entradas: nomes de pessoas,
nomes de empresas, etc. Cada entrada contem uma serie de atributos: telefone,
endereco, etc.
Active Directory e uma implementac ao do protocolo LDAP feita pela Mi-

crosoft. Isto somente e possvel porque o protocolo LDAP e um padr ao aberto.

Existem muitas outras implementac oes, por exemplo, OpenLDAP (uma vers ao
open source). O Active Directory implementa, alem do protocolo LDAP, out-
ras funcionalidades como o DNS e o Kerberos. Ele e utilizado como base de
dados centralizada de informac oes necessarias para a operac
ao de uma rede dis-
tribuda de computadores. Isto porque ele armazena informac oes de usu arios
e suas permiss oes, grupos, m aquinas existentes na rede, recursos comuns, seja
de disco ou fsicos, como impressoras e outros perifericos. Alem de armazenar
varios objetos em seu banco de dados, o AD disponibiliza v arios servicos, como:
autenticac
ao dos usu arios, replicac
ao do seu banco de dados, pesquisa dos ob-
jetos disponveis na rede, administrac ao centralizada da seguranca utilizando
452
GPO (Group Policy). Com a utilizac ao do AD, os usu arios poderao ter apenas
uma senha para acessar todos os recursos disponveis na rede. O que representa
um grande avanco se comparado a um cen ario onde e necess
ario ter diferentes
senhas para diferentes recursos (acessar o sistema principal da empresa, ler seus
e-mails, se logar no computador, etc.).
O AD surgiu juntamente com o Windows 2000 Server e pode ser instalado em

servidores que executem o Windows Server 2003 (Standard Edition, Enterprise
Edition e Datacenter Edition). Vale ressaltar que n
ao se pode instalar o AD em
um servidor que execute o Windows Server 2003 - Web Edition, mas se pode
ingressa-lo em um domnio do Active Directory como servidor membro.
54.3.1 Tipos de Servidores

Existem dois tipos de servidores:
Controlador de Domnio (DC - Domain Controller): e o computador que

possui o AD instalado, ou seja, e um servidor que possui uma copia da
base de dados do AD. Em um mesmo domnio podemos ter mais de um
Controlador de Domnio. As alteracoes efetuadas em um DC s ao repli-
cadas para todos os outros DCs. Sao os DCs quem fazem a autenticac
ao
dos usu
arios de um domnio;
Servidor Membro (Member Server): e um servidor que nao possui uma

c
opia do AD, porem tem acesso aos objetos do AD. N
ao fazem a auten-
ticac
ao dos usu
arios.
54.3.2 Defini
coes de Floresta, Domnio, Site e Unidade
Organizacional
Um domnio pode ser definido como um limite administrativo e de seguranca.
Ele e um limite administrativo, pois as contas de Administrador tem permiss oes
de acesso em todos os recursos do domnio, mas n ao em recursos de outros
domnios. Ele e um limite de seguranca porque cada domnio tem definic oes de
polticas de seguranca que se aplicam ` as contas de usu arios e demais recursos
dentro do domnio e n ao a outros domnios. Eles tambem podem ser definidos
como unidades de replicac ao. Todos os controladores de domnio podem receber
alterac
oes e replic
a-las em todos os outros controladores deste domnio. Cada
domnio do Active Directory e identificado por um sistema de nomes de domnios
(DNS) e requer um ou mais controladores. Se a rede precisar de mais de um

domnio, voce poder a criar facilmente varios domnios. Um ou mais domnios
que compartilham um esquema e um CATALOGO GLOBAL (controlador de
domnio que armazena uma c opia de todos os objetos do AD) s ao chamados
de FLORESTA. O primeiro domnio em uma floresta e chamado de DOMINIO
RAIZ da floresta. Se v arios domnios na floresta tiverem nomes de domnio DNS
contguos, essa estrutura ser
a chamada de ARVORE DE DOMINIO. No AD,
os SITES mapeiam a estrutura fsica da rede, enquanto os domnios mapeiam
a estrutura l ogica ou administrativa da organizac ao. A estrutura do site e a
estrutura do domnio s ao separadas e flexveis. Portanto, e possvel ter dois
cenarios distintos: um u nico site com mais de um domnio; e um u nico domnio
453
com mais de um site.
Com a utilizacao de domnios, podemos fazer com que nossa rede reflita
a estrutura de uma empresa. Desta forma, permite se que usu arios de um
domnio acessem recursos localizados em outros domnios. Algumas carac-
tersticas pr
oprias de cada domnio:
Um domnio armazena informac

oes somente dos objetos do pr
oprio domnio.
Um domnio possui suas pr
oprias diretivas de seguranca.
Os domnios do Windows 2000/2003 podem estar nos seguintes modos:
Native (Nativo): utilizado em domnios que possuem somente Contro-

ladores de Domnio (DC) Windows 2000/2003;
Mixed (Misto) (padrao de instalac

ao): utilizado em domnios que possuem
Controladores de Domnio (DC) Windows 2000/2003 e Windows NT. Este
modo existe para manter compatibilidade com o Windows NT geralmente
durante processos de upgrade.
Agora que foram definidos os conceitos de

arvore e domnio, podemos ent ao
definir UNIDADE ORGANIZACIONAL (Organization Unit - OU). Uma OU
e uma subdivis ao de um domnio que pode ser utilizada para organizar os ob-
jetos deste domnio em um agrupamento l ogico para efeitos de administrac ao.
Com a utilizac
ao de unidades organizacionais, e possvel restringir os direitos
administrativos apenas em nvel da Unidade Organizacional sem que, com isso,
o administrador tenha poderes sobre todos os demais objetos do Domnio. Vale
ressaltar que a infra-estrutura das OUs n
ao deve ser baseada na estrutura or-
ganizacional da companhia, mas sim na infra-estrutura da poltica da rede.
54.3.3 Recursos do Active Directory

Ao utilizar os domnios baseados no AD, temos os seguintes recursos:
Logon unico: com esse recurso, o usu

ario necessita fazer apenas um logon
para acessar os recursos em diversos servidores da rede, inclusive e-mail e
banco de dados;
Conta de usuario unica: os usu

arios possuem apenas um nome de usu ario
para acessar os recursos da rede. As contas de usu
arios ficam armazenadas
no banco de dados do AD;

Gerenciamento centralizado: com os domnios baseados no AD, temos
uma administracao centralizada. Todas as informac
oes sobre contas de
usu
arios, grupos e recursos da rede, podem ser administradas a partir de
um u
nico local no domnio;
Escalabilidade: os domnios podem crescer a qualquer momento, sem lim-

ite de tamanho. A forma de administrac ao e a mesma para uma rede
pequena ou grande.
454
54.3.4 Seguran
ca com o Active Directory
O Active Directory garante um ambiente de diret orio seguro para a organizac
ao,
pois usa os recursos internos de autenticac
ao de logon e autorizac
ao de usu
arios,
que s
ao os principais recursos da LSA (Autoridade de Seguranca Local). O AD
oferece suporte a v arios protocolos padr ao da Internet e mecanismos de au-
tenticac
ao usados para comprovar a identidade no logon, incluindo Kerberos
V5, certificados X.509 v3, cart oes inteligentes, infra-estrutura de KPI (chave
p
ublica) e protocolo LDAP usando a SSL (Secure Sockets Layer).
A autenticacao entre domnios ocorre por meio de relac oes de confianca.

Confianca e uma relac ao estabelecida entre dois ou mais domnios que per-
mite aos usu arios em um domnio serem autenticados por um controlador de
outro domnio. As relac oes de confianca podem ser transitivas ou intransiti-
vas, mas devem sempre estar presentes para que os usu arios de um domnio
tenham acesso aos recursos compartilhados de outro domnio. As relac oes de
confianca no Windows NT s ao diferentes das relac
oes de confianca em sistemas
operacionais Windows 2000/2003. No Windows NT 4.0 e vers oes anteriores,
as relac
oes de confianca s
ao limitadas a dois domnios e a relacao de confianca
e unidirecional e intransitiva. Todas as relac oes de confianca em florestas do
Windows 2000/2003 s ao relac
oes de confianca transitivas bidirecionais. Desta
forma, se o domnio X confia no domnio Y, e Y confia no domnio W, ent ao X
tambem confia em W (propriedade transitiva) e W confia em Y que confia em
X (propriedade bidirecional).
De uma forma geral, um PROTOCOLO DE CONFIANC A funciona da

seguinte maneira. Um controlador de domnio autentica usu arios e aplicativos
usando um destes dois protocolos: Kerberos V5 ou NTLM. O protocolo Ker-
beros V5 e o protocolo padr ao para computadores que executam o Windows
2000/2003. Se algum computador envolvido em uma transac ao nao fornecer su-
porte a Kerberos V5, o protocolo NTLM ser a usado. Com o protocolo Kerberos
V5, apos a autenticac
ao, o cliente solicita a um controlador no domnio de sua
conta uma permiss ao para o servidor no domnio confiante. Essa permiss ao e
emitida por um intermedi ario de confianca do cliente e do servidor. O cliente
apresenta essa permiss ao confi
avel ao servidor do domnio confiante para que
seja autenticada. Quando um cliente tenta acessar recursos de um servidor em
outro domnio usando a autenticac ao NTLM, o servidor que contem o recurso
deve entrar em contato com um controlador de domnio no domnio da conta
do cliente para verificar as credenciais dessa conta.
Alem de proteger o acesso à rede por meio de autenticac ao, o AD ajuda

a proteger os recursos compartilhados, pois facilita a autorizac ao de usu
ario.
Depois que um logon de usu ario e autenticado, os direitos atribudos ao usu
ario
atraves de grupos de seguranca e das permiss oes concedidas em relac ao ao re-
curso compartilhado determinar ao se o usuario tera autorizac
ao de acesso ao
recurso. Ou seja, o AD tambem implementa CONTROLE DE ACESSO (simi-
lar ao do NTFS). Lembrando que o controle de acesso e administrado no nvel
do objeto, por meio da configuracao de diversos nveis de acesso, ou permiss
oes,
aos objetos, como: Controle Total, Gravac ao, Leitura ou Sem Acesso.
455
54.3.5 Ferramentas de Controle

Varias ferramentas adicionais que podem ser usadas para configurar, gerenciar
e depurar o Active Directory est ao disponveis como ferramentas de linha de
comando. Essas ferramentas s ao conhecidas como ferramentas de suporte. As
mais usadas sao: Movetree, SIDWalk, LDP, Dnscmd, DSACLS, Netdom, NET-
Diag, NLTest, Repadmin, Replmon, DSAStat, ADSI Edit, SDCheck, ACLDiag,
DFSUtil, Dcdiag e ADMT.
54.4 IIS - Internet Information Services

O IIS (Internet Information Services) e um SERVIDOR WEB criado pela Mi-
crosoft para seus sistemas operacionais para servidores. Na verdade, para ser
mais preciso, ele e um conjunto integrado de servicos de rede que permite a
publicac
ao de conteudo, disponibilizac
ao de arquivos, e execuc
ao de aplicac
oes
em ambientes Intranet, Extranet e Internet.
Por padrao, o IIS NAO E instalado durante a instalac

ao tpica do Win-
dows 2000/2003 Server. Para instalar o IIS, clique no botao Iniciar >> Painel
de Controle >> Ferramentas Administrativas >> clique em Assistente para
configurar o Servidor >> clique em Avancar e Avancar. Para voce comecar a
configurar o IIS, clique no bot
ao Iniciar >> Painel de Controle >> Ferramen-
tas Administrativas >> clique em Gerenciador dos Servicos de informac oes da
Internet.
54.4.1 IIS versus Apache HTTP Server

Eles s
ao servidores concorrentes diretos entre si, entao, de certa forma, possuem
algumas caractersticas convergentes e outras divergentes. Cada um possui suas
fraquezas e forcas. Ao longo desta sec
ao, ser
ao feitas as principais comparac
oes
entre os dois servidores.
Origens
O Apache HTTP Server, em sua primeira vers ao, foi baseado no UNIX httpd
Server. Este desenvolvimento ocorreu durante a primeira gerac ao da Web. Por
muitos anos, este servidor esteve bastante atrelado ` a plataforma UNIX. A vers ao
1.3, que ainda e bastante utilizada, foi a u ltima vers
ao que assumia que o sis-
tema operacional fosse UNIX ou UNIX-LIKE (Linux, OpenBSD, FreeBSD, Sun
Solaris, etc.). Sua vers

ao 2.0 foi reprojetada para abstrair o sistema operacional
utilizado, passando a ser, portanto, um SISTEMA MULTIPLATAFORMA.
Isto e feito utilizando-se basicamente do Apache Portable Runtime (APR) e
do Multi-Processing Modules (MPMs). Os MPMs s ao especficos para cada
plataforma. Por exemplo, para a plataforma Windows, este m odulo e baseado
fortemente no conceito de threads, pois Windows favoresse esse tipo de aplica-
tivo. Ja no caso da plataforma Linux, seu desenvolvimento e baseado fortemente
em forking process. Sua vers ao atual e a 2.2.
A Microsoft iniciou a distribuic

ao do IIS a partir do Windows NT 3.51.
Desde ent
ao, este servidor sempre esteve disponvel (n
ao como padr
ao de in-
456
stalac
ao). Seu desenvolvimento sempre foi e continua sendo focado, u nico
e exclusivamente, na plataforma Windows. Portanto, ele NAO E MULTI-
PLATAFORMA. Um benefcio direto desta abordagem e a vantagem de se poder
implementar uma forte cooperac ao entre o IIS e o pr
oprio kernel do Windows,
o que influencia e muito em sua performance. IIS e na verdade uma colec ao de
servicos, incluindo servidores para: Web, FTP, SMTP e Network News Transfer
Protocol (NNTP). Sua vers ao atual e a 6.0, mas a Microsoft incluir
a a vers
ao
7.0 do IIS em sua nova plataforma chamada Windows Longhorn Server.
Licen
cas
O Apache HTTP Server sempre teve e continua tendo seu c odigo aberto. Sua
licenca permite seu desenvolvimento e seu uso de forma irrestrita.
Embora o IIS n ao tenha seu c

odigo aberto, ele possui uma licenca liberal
que garante seu desenvolvimento e uso.
Aplica
coes Web
O Apache usa por padr ao a Common Gateway Interface (CGI) para suportar
aplicac
oes web. Foram criados tambem diversos m
odulos para suportar outras
linguagens de programacao. Portanto, o Apache suporta diversas linguagens,
tais como: PHP, ASP, Perl, Python, Ruby, C++, etc. Vale ressaltar que devido
a sua natureza modular, o Apache pode suportar novas linguagens se necess
ario.
O IIS suporta por padr ao o Active Server Pages (ASP). Pouco se comenta,
mas e possvel habilitar no IIS a utilizac
ao de outras linguagens como Perl ou
PHP. Isto se deve ao fato do ASP ser a linguagem preferida pela Microsoft. De-
pois do lancamento da plataforma .NET em 2002 o IIS ganhou tambem a func ao
de gerenciar o ASP.NET. Alem disso, o IIS passou a suportar novos servicos,
como Universal Description, Discovery, and Integration (UDDI) Services, Simple
Object Access Protocol (SOAP) e Web Services Description Language (WSDL).
De qualquer forma, as opc oes de linguagens suportadas pelo IIS s ao menores
que as suportadas pelo Apache.
UDDI e uma especificacao que define um servico de registro para Web

Services. Um servico de registro UDDI e um Web Service que gerencia in-
formacao sobre provedores, implementac oes e metadados de servicos. Prove-
dores de servicos podem utilizar UDDI para publicar os servicos que eles ofere-
cem. Usu arios de servicos podem usar UDDI para descobrir servicos que lhes in-
teressem e obter os metadados necess arios para utilizar esses servicos. A especi-
ficac
ao UDDI define: APIs SOAP utilizadas para publicar e obter informac oes
de um registro UDDI; Esquemas XML do modelo de dados do registro e do
formato das mensagens SOAP; Definic oes WSDL das APIs SOAP; Definic oes
de registro UDDI (modelos tecnicos - tModels) de diversos sistemas de identi-
ficac
ao e categorizac
ao, que podem ser utilizados para identificar e categorizar
registros UDDI.
WSDL e uma linguagem baseada em XML utilizada para descrever Web

Services. Na verdade, trata-se de um documento escrito em XML que alem
457
de descrever o servico, especifica como acess

a-lo e quais s
ao as operac
oes ou
metodos disponveis.
SOAP e um protocolo para troca de informac oes estruturadas em uma

plataforma descentralizada e distribuda, utilizando tecnologias baseadas em
XML. Sua especificac
ao define uma framework que prove maneiras para se con-
struir mensagens que podem trafegar atraves de diversos protocolos e que foi
especificado de forma a ser independente de qualquer modelo de programac ao
ou outra implementacao especfica.
Performance
Muitos estudos sobre performance tem sido feitos, contudo, seus resultados n
ao
apontam com clareza qual servidor tem maior performance. Na verdade, tem-se
mostrado que o que mais influencia na performance e a qualidade da imple-
mentac
ao da aplicac
ao Web, indiferentemente se esta sendo executada no IIS
ou Apache. Ambos os servidores oferecem alguns recursos importantes para o
quesito performance, a saber:
Uso extensivo de cache (o Apache exige um m

odulo `
a parte para isso);
Suporte ao GNU zip (gzip), o que reduz significativamente a largura de
banda necess
aria entre o servidor e o usu
ario final;
Suporte a filtros, o que anula em partes a reduc

ao da performance devido
ao fato do uso de linguagens interpretadas como ASP, PHP ou Perl;
Uso de kernel-level listener para aumentar a performance e escalabilidade.

Por padrao, o IIS utiliza-se do HTTP.sys que e executado em modo su-
per usu
ario. De forma an aloga, contudo n
ao por padr
ao e sim de forma
opcional, o Apache utiliza-se do phhttpd no intuito de obter uma maior
performance.
Seguran
ca
Com relac
ao ao canal de comunicac ao, ambos os servidores utilizam o HTTPS
(HTTP over SSL) para a realizac ao da encriptac
ao dos dados. Portanto, n ao
existem grandes diferencas entre os dois servidores com relac
ao `
a seguranca no
canal de comunicac
ao.
Um outro aspecto da seguranca que deve ser analisado e a vulnerabilidade do

pr
oprio host e do Web server. Como o Apache e um sistema multiplataforma,
sua analise quanto `
a seguranca n ao e t
ao trivial. Esta responsabilidade fica
muito mais associada ao sistema operacional que propriamente ao servidor Web.
O Apache geralmente e utilizado com os SO UNIX-LIKE, que praticamente em
todos os casos executam o servidor Web em modo usu ario. Desta forma, falhas
de seguranca no servidor Web acabam n ao sendo t ao significativas ao sistema
como um todo. Por outro lado, o IIS s o pode ser utilizado com o Windows,
que desde suas primeiras versoes e bastante conhecido pelas suas falhas de se-
guranca. Mesmo em suas vers oes mais atuais, devido ` a forte colaborac
ao entre
o Windows e o IIS, via HTTP.sys, seu hist orico de vulnerabilidade e bastante
458
consider
avel.
Um terceiro aspecto da seguranca a ser analisado e o controle de acesso a

conteudo. Com relac ao a este aspecto, ambos os servidores s ao eficientes. O
Apache tipicamente utiliza o HTTP Basic Authentication (geralmente sobre o
SSL) para a realizac ao das autenticac possvel tambem este controle ser
oes. E
gerido pelo pr oprio administrador local via arquivos de usernames/password,
o que n ao seria nada modular. Como o Apache e altamente modular, uma
alternativa a isto e a sua integrac
ao com o LDAP ou Active Directory (AD). J a
o IIS, que e altamente integrado ao Windows, oferece autenticac ao e autorizac
ao
tipicamente via AD. Autorizac oes para URLs especificas tipicamente ocorrem
sobre o sistema ACLs. Cabe ressaltar que em sites din amicos, a realizac
ao de
autorizac
ao e autenticacao pode se tornar extremante oneroso. Sendo assim,
geralmente esta responsabilidade e passada para a aplicac ao.
Administra
cao
Sem duvida a maior diferenca entre os dois servidores e com relac
ao aos seus
recursos de configurac
ao e administrac
ao.
A configurac
ao do Apache e geralmente feita na mao, editando arquivos em
formato texto. Isto e feito tanto em pequenos servidores quanto grandes. A
principal vantagem existente e a possibilidade de se utilizar de templates que
automatizam o processo de configurac ao em v arios servidores em uma Web
Farm. Por outro lado, a configurac
ao manual pode se tornar difcil se estiverem
sendo configurados m ultiplos Web sites. Uma alternativa e a utilizac
ao de fer-
ramentas (Web-based ou GUI-based). Webmin e um exemplo quando se estiver
utilizando sistemas UNIX-LIKE.
Com relac
ao ao IIS, a administrac
ao e sempre feita via console (GUI-based
Microsoft Management Console snap-in). Este console prove um ambiente co-
mum para a administrac ao tanto do IIS quando dos diversos servidores (Web,
FTP, SMTP e NNTP) que o comp oem.
54.4.2 Principais Componentes do IIS

O IIS tem muitos subcomponentes que podem ser adicionados ou removidos a
qualquer momento. A saber:
Common Files: instala arquivos comuns requeridos pelo programas IIS;

Documentation: instala a documentacao que contempla administrac
ao do
servidor e publicac
ao de conte
udos;
File Transfer Protocol (FTP) Server: instala o FTP;
FrontPage 2000 Server Extensions: instala extens
oes que possibilitam ad-
ministrac
ao de Web sites usando o FrontPage e o Microsoft Visual Inter-
Dev;
Internet Information Services Snap-In: instala a ferramenta de adminis-
trac
ao principal;
459
Internet Services Manager: instala uma versao baseada em browser da

ferramenta de administrac
ao. Por padr
ao, o acesso a este site e somente
local;
NNTP Service: instala o Network News Transfer Protocol (NNTP). Este
servico e utilizado na criac
ao e manutenc
ao de newsgroups;
SMTP Service: instala o SMTP;
Visual InterDev RAD Remote Deployment Support: permite que aplicac
oes
sema distribudas remotamente;
World Wide Web Server: instala o servidor Web.
54.4.3 Principais Recursos do IIS

Um servico que n ao faz parte do IIS, mas que est ao altamente relacionados e
o INDEXING SERVICE. Este servidor e utilizado na criac ao de cat
alogos de
documentos que podem ser buscados dentro de um sistema. Quando este servico
e adicionando a um Web site, usu arios s
ao capazes de fazer buscas por t
opicos
de interesse via formularios do pr
oprio HTML.
Exclusivamente com relac

ao ao IIS, os principais recursos disponibilizados
s
ao:
HTTP 1.1 and HTTP Compression;

Host Headers: permite que diversos Web sites possam ser hospedados em
um mesmo servidor. O IIS usa o host name passado no cabecalho HTTP
para determinar o site (pasta no servidor) que o usu
ario est
a acessando;
FTP Restart: permite que downloads via FTP possam ser restabelecidos,
em caso de uma eventual desconex
ao, a partir do ponto anterior;
Active Server Pages (ASP): utilizada juntamente com HTML e Compo-
nent Object Model (COM) para criacao de aplicac
oes din
amicas e intera-
tivas baseadas em Web;
Application Protection: permite que aplicacoes ASP sejam executadas em
espacos separados de mem oria. Existem tres nveis de protec
ao: BAIXA

(in-process), MEDIA (pooled out-of-process) e ALTA (out-of-process);
Process Accounting and Throttling: Process Accounting prove informac
oes
sobre como certo Web site usa a CPU. Process Throttling permite que o
uso da CPU;
WebDAV: possibilita que usu arios remotos possam publicar, trancar e
administrar recursos usando uma conexao HTTP;
SSL 3.0 and TLS: provem metodos seguros de troca de informac
oes entre
cliente e servidor;
Digest Authentication: um dos muitos mecanismos de autenticac
ao supor-
tados pelo IIS. Ele e o mecanismo que trabalha melhor entre servidores
proxy e firewalls.
460
54.4.4 Principais Diferencas entre IIS4, IIS5 e IIS6
IIS4 IIS5 IIS6

Plataforma Windows NT 4.0 Windows 2000 Windows Server
2003
Arquitetura 32-bit 32-bit 32-bit e 64-bit
Metabase config- Binary Binary XML
uration
Seguranca Windows authen- Windows authen- Windows au-
tication; SSL tication; SSL; thentication;
Kerberos SSL; Kerberos;
Passport support
Administrac
ao HTMLA HTMLA; Termi- Remote Ad-
remota nal Services ministration Tool
(HTML); Remote
Desktop
Suporte a Mail SMTP SMTP SMTP e POP3
Suporte a IP IPv4 IPv4 IPv4 e IPv6
Tabela 54.1: Principais Diferencas entre IIS4, IIS5 e IIS6
54.5 Terminal Services

Um SERVIDOR configurado para funcionar como terminal services pode suprir
diversas necessidades em uma rede de uma organizac ao. Os benefcios de se ter
um terminal services ser ao descritos na proxima subsec
ao. Fundamentalmente,
o princpio de funcionamento e o seguinte. Diversos CLIENTES estabelecem
conex oes simult
aneas com o TERMINAL SERVICES e a partir da enviam so-
mente sinais de teclado e mouse. O terminal services e respons avel por todo o
processamento de aplicac oes Windows e por enviar ao cliente, via rede, o sinal
de vdeo que permitira a visualizac
ao dos resultados do processamento.
Como consequencia dessa configurac

ao, n
ao h
a necessidade dos clientes exe-
cutarem o mesmo sistema operacional utilizado no terminal services (Windows).
Ou seja, CLIENTES podem estar executando qualquer SO, inclusive os n ao
baseados em Windows. J a o terminal services pode ser instalado basicamente
em Windows NT e Windows 2000/2003 Server (Standard Server, Enterprise

Server, e Datacenter Server). Somente o Windows 2000/2003 Web Server n ao
pode ser configurado como SERVIDOR DE APLICAC
AO, mas pode ser con-
figurado para ADMINISTRAC REMOTA.
AO
Durante a instalac
ao do sistema operacional no servidor que funcionar
a como
SERVIDOR DE APLICAC
AO, e fortemente recomendado a utilizac
ao do sis-
tema de arquivo NTFS. Este sistema prove basicamente os seguintes benefcios:
estabelecimento de cotas para usu arios; compress
ao de partic
oes e arquivos;
controle de acesso em nvel de diretorio e/ou arquivo.
461
As configurac
oes do terminal services com relac
ao aos par
ametros de co-
municac
ao podem ser realizadas em quatro nveis hierarquicos (descendente):
Group Policies (GPO); Terminal Services configuration; User configuration;
Client configuration.
Cabe tambem ressaltar que esta tecnologia n ao e somente utilizada pela

Microsoft. Por exemplo, o Linux Terminal Server Project trabalha exatamente
na quest
ao de possibilitar servidores Linux funcionarem como terminal services.
54.5.1 Principais Benefcios

importante notar que, na realidade, esta tecnologia pode ser aplicada e uti-
E
lizada tanto em clientes quanto em servidores. A seguir, s ao sintetizados os
mais relevantes benefcios ao se utilizar esta tecnologia. Alguns t
opicos dizem
respeito `
a utilizac
ao em servidores e outros em clientes.
Administracao Remota versus Servidor de Aplicac ao. O terminal server

(SERVIDOR) pode funcionar nestes dois modos (simultaneamente ou n ao).
No primeiro modo, ser a possvel acesso remoto ao servidor (simular ao Re-
mote Desktop usado em clientes). O segundo modo permite que aplicac oes
sejam executadas no servidor e que diversos clientes acessem essa aplicacao
de forma simult anea atraves da rede (este modo e instalado como um
modulo a parte do SO). Este recurso e especialmente interessante para
compartilhamento de aplicac oes em uma intranet. Uma observac ao impor-
tante: algumas aplicacoes instaladas antes da configuracao e ativac
ao do
servidor como servidor de aplicac ao podem nao funcionar corretamente.
Isto ocorre devido ao fato de aplicac oes multiusuarios terem requisitos
diferentes de configuracoes;
Construcao de redes com clientes sem SO pr oprio. Geralmente estes

clientes s
ao equipamentos pobres, em relac ao ao hardware. S ao geral-
mente computadores reaproveitados. Eles tambem s ao chamados de thin
clients, pois suas configurac
oes sao basicamente: HD AUSENTE, um
mnimo de RAM, uma placa gr afica simples, uma placa de rede simples
e interfaces de entrada/sada (teclado, mouse e monitor). Como estes
equipamentos n ao possuem HD, eles utilizam via rede um u nico SO, o do
terminal services. S
ao estabelecidas ligac
oes necess arias para criac
oes de
sess
oes de trabalho no servidor que s ao visveis e control
aveis pelos thin
clients;
Esta tecnologia tambem pode ser utilizada para redirecionamento de diver-

sos recursos de clientes, tais como: drives de CD, disquete, etc.; clipboard;
portas COM; portas LPT; impressoras; sada de audio; etc.;
Terminal Server Client. Disponvel para Windows XP Home Edition e

Professional Edition instalados em clientes. O Remote Desktop Proto-
col (RDP) permite acesso a terminal services. Em ambos os SOs, h a
disponvel tambem o Remote Assistance, que possibilita um usu ario so-
licitar ajuda a um especialista, que pode assumir o controle da m aquina
cliente. Para o Windows XP Professional, h a um m odulo adicional, o Re-
mote Desktop, que possibilita o uso de m
aquinas clientes de forma remota.
462
54.5.2 Protocolos de Comunicac

ao
A tecnologia terminal services suporta diversos protocolos de COMUNICAC
AO
e protocolos de TRANSPOTE. Protocolos podem ser instalados ou desinstala-
dos a qualquer momento.
Os protocolos de transporte sao aqueles que implementam funcionalidades

das quatro camadas inferiores do modelo OSI (fsica, enlace, rede e transporte).
Os principais protocolos suportados s
ao: TCP/IP; NWLink; IPX/SPX; Net-
BEUI.
Os protocolos de comunicac
ao s
ao aqueles que implementam funcionalidades
da camada de aplicac ao do modelo OSI. Algumas dessas funcionalidades s ao
providas pelos processos de comunicac ao. Os processos de comunicacao su-
portados pelo terminal services sao: named pipes; mail slots; Windows sock-
ets; remote procedure calls; NetBIOS; NetDDE, server message blocks, DCOM
(COM+); SOAP.
Um protocolo de comunicac ao muito importante para a tecnologia terminal

services e o Remote Desktop Protocol (RDP). Ele regulamenta as conex oes entre
terminal services e clientes utilizando como protocolo de transporte somente o
TCP/IP. Como o terminal services trabalha de forma flexvel, ou seja, se comu-
nicando atraves de diversas versoes de protocolos com clientes que utilizam mais
variados SOs, se faz necessario uma troca previa de parametros que caracteriza
o cliente. Esta troca ocorre no incio da conex ao e os parametros descrevem
as capacidades do cliente. Estas capacidades s ao divididas em grupos: General
Abilities (plataforma e SO do cliente; versao do protocolo; compress ao de dados
suportada); Bitmaps (tamanho da tela; qualidade da cor; compress ao bitmap);
Character Commands; Bitmap Cache; Color Table; Panel Activation; Remote
Control (habilita a possibilidade do cliente ser controlado remotamente); Cursor
(define propriedades de cor do cursor do mouse). A tabela a seguir resume a
evoluc
ao deste protocolo.
RDP 5.0 RDP 5.1 RDP 5.2

Surgiu com: Windows 2000 Windows XP Windows Server
2003
Caractersticas 256 cores (8 bits); 640 x 480 ate Todas as pro-
Monitoramento Re- 1600 x 1200 pixels priedades an-
moto de clientes; (24 bits); Trans- teriores com
Criptografia; com missao de audio; poucas adic

oes,
56 ou 128 bits; Su- Redirecionamento como reconex ao
porte a compress ao de portas COM; autom atica; trans-
e caching (reduz o Suporte a Smart missao de Windows
tr
afico); Conex ao Cards; Adminis- key (ALT+TAB,
com impressoras e trac
ao Remota do etc.)
clipboard no cliente servidor
Tabela 54.2: Evoluc

ao do RDP
Atualmente, existem dois aplicativos que utilizam o protocolo RDP, o Re-
463
mote Desktop Connection (RDC) e o Remote Desktop MMC Snap-in. O RDC,

aplicativo padrao para usuarios, substituiu o Windows 2000 Terminal Services
client e tambem o Client Connection Manager. O Remote Desktop MMC Snap-
in nao e um aplicativo para usuario convencionais e sim uma ferramenta para
administradores (login de administrador necess ario). Esta ferramenta geral-
mente e utilizada para manter e administrar diversas conex oes com multiplos
servidores.
54.5.3 Licen
cas
Para que um servidor funcione corretamente no modo servidor de aplicac
ao,
algumas licencas devem ser adquiridas. S
ao elas:
Server License: necessaria para a instalac

ao do sistema operacional do
servidor;
Client Access License (CAL): necess aria para que clientes possam se conec-
tar ao servidor e utilizarem servicos como: compartilhamento de arquivos
e impressoras; e outros servicos de redes. Essa licenca pode ser obtida
por usuario ou por dispositivo, o que for mais vantajoso para quem estiver
comprando as licencas;
Terminal Server Client Access License (TS-CAL): necess aria para que
clientes possam se conectar ao servidor e utilizarem aplicativos Windows.
Essa licenca tambem pode ser obtida por usu ario ou por dispositivo.
Lembrando que a cada conex ao, e verificado se o usu ario ou dispositivo

em quest ao tem sua licenca ou n
ao. Esta verificacao e feita por um servidor
de licencas, que pode ser instalado no pr oprio equipamento que funcionar a o
servidor de aplicac
ao ou outros equipamentos da organizac ao, por exemplo,
controladores de domnio (DCs).
464
Parte XI
Banco de Dados
465
Captulo 55
Conceitos B
asicos
Um sistema de gerencia de banco de dados (SGBD) e uma colec ao de arquivos e

programas inter-relacionados que permitem ao usu ario o acesso para consultas
e alterac
oes desses dados. O maior benefcio do banco de dados e proporcionar
ao usuario uma vis ao abstrata dos dados.
A abstrac ao de dados se da em tres nveis: nvel canceitual, nvel l

ogico e
nvel fsico e ser
ao explicados abaixo.
A capacidade de modificar a definic ao dos esquemas em determinado nvel

sem afetar o esquema do nvel superior, e chamado independencia dos dados. A
independencia de dados l
ogica (alterac
ao no nvel l
ogico) e mais difcil de ser al-
cancada que a independencia fsica, uma vez que os programas de aplicac ao s
ao
mais fortemente dependentes da estrutura l ogica dos dados do que de seu acesso.
Como o modelo E-R, explicado com mais detalhes, ` a frente, o modelo ori-
entado a objetos tem por base um conjunto de objetos. Aqui, utilizamos os
conceitos de classes, metodos, etc. Ao contr
ario do modelo E-R, cada objeto,
possui uma unica identidade, independente dos valores neles contidos.
Existem tres modelos l

ogicos com base em registros:
Modelo Relacional: Usa um conjunto de tabelas para representar tanto os

dados como a relac
ao entre eles;
Modelo de Rede: Os dados do modelo de rede s ao representados por um

conjunto de registros e as relacoes entre estes registros s
ao representadas
por links (ligac
oes), as quais podem ser vistas pelos ponteiros. Os registros
s
ao organizados no banco de dados por um conjunto arbitr ario de grafos;
Modelo Hier similar ao modelo de rede, pois os dados e suas

arquico: E
relac
oes s
ao representados, respectivamente, por registros e links. A diferenca
e que no modelo hier arquico, os registros est
ao organizados em arvores.
Uma transacao e uma colec

ao de operacoes que desempenha uma func
ao
l
ogica u
nica dentro de uma aplicacao do sistema de banco de dados. Exigimos
que as transac
oes n
ao violem nenhumas das regras de consistencia do sistema
466
de banco de dados. E necess

ario aceitar inconsistencias tempor arias para que as
transac
oes possam ocorrer sem problemas, mas dever a ser possvel retornar caso
ocorra uma falha, por isso todo SGDB deve conter um sistema de recuperac ao.
O arquivo de dados armazena o pr

oprio banco de dados, o dicion
ario de da-
dos armazena os metadados relativos `
a estrutura do banco de dados. E muito
usado, portanto uma implementac
ao eficiente e importante.
Um projeto de banco de dados envolve as seguintes etapas:
Analise de Requisitos: Processo informal que envolve discuss

oes entre gru-
pos de usu arios;
Projeto Conceitual: Descric

ao de alto nvel dos dados a serem armazena-
dos no BD (modelo ER);
Projeto L
ogico: Escolher um SGDB e converter o projeto conceitual em
um esquema do modelo de dados do SGDB, exemplo: modelo relacional;
Refinamento do esquema: Identificar potenciais problemas, usando teorias

como a normalizac
ao;
Projeto Fsico: Garantir criterios de desempenho, envolve, por exemplo,

a construc
ao de ndices para tabelas;
Projeto de Seguranca: Identificar grupos de usu

arios e regras entre esses
grupos e seus acessos `
as tabelas.
467
Captulo 56
Abordagem Relacional
56.1 Conceitos
O abordage relacional apresenta basicamente cinco conceitos que s
ao:
Domnio: Conjunto de valores permitidos para um dado;

Atributo: Um item de dado do BD (possui um nome e um domnio);
Tupla: Um conjunto de pares (atributo, valor). Exemplo: (idade, 34);
Relac
ao: E um conjunto de tuplas. Composto por um cabecalho e um
corpo. O cabecalho possui um n umero fixo de atributos n ao-ambguos
(grau da relac
ao). Corpo e um n
umero variavel de tuplas (cardinalidade
da relac
ao) em que a ordem nao relevante.
Chave: Conjunto de um ou mais atributos de uma relac

ao;
56.2 Esquemas e Restri

coes de Integridade
O esquema de um BD relacional e um conjunto de esquemas de relac ao, S =
R1 , ..., Rm . Uma inst
ancia de S e um conjunto de relac
oes BD = r1 , ..., rm , onde
cada ri e uma inst ancia do esquema de relac
ao Ri .
A restric
ao de domnio e a condic
ao em que os atributos devem ser aceitos
somente dentro de um conjunto especificado, por exemplo: um valor maior que
quatro ou um valor diferente de nulo.
A restric
ao de integridade referencial e a condic
ao em que desejamos garantir
que um valor que aparece em uma relac ao para um dado conjunto de atributos
tambem apareca para um certo conjunto de atributos de outra relac ao. Um
conjunto de atributos FK no esquema da relac ao R1 e uma chave estrangeira
de R1 que referencia R2 se:
1. os atributos em FK possuem os mesmos domnios que os atributos da

chave prim aria PK de R2 ; diz-se que os atributos FK fazem referencia `
a
relac
ao R2 .
468
2. para qualquer tupla t1 de r1 (R1 ), ou existe uma tupla t2 emr2 (R2 ) tal que
t1 [F K] = t2 [P K], ou t1 [F K] e nulo.
Violac
oes de restric
oes que podem ocorrer:
1. inserir(v1,...,vn) pode causar:

violac
ao de integridade de identidade (chave prim. nula);
violac
ao de restric
ao de chave;
violac
ao de integridade referencial.
2. excluir(PK) pode causa violac

ao de integridade refencial. Podemos lidar
com isso das seguintes maneiras:
rejeitar;
propagar a exclus
ao; .
modificar os valores dos atributos referenciados para nulo.
ao(PK, atributo, novo valor): podem causar as mesmas violac

3. atualizac oes
vistas anteriormente quando ou a chave primaria ou chave estrangeira s
ao
atualizadas.
Uma assercao e um predicado que expressa uma condic ao que desejamos que
seja sempre satisfeita no banco de dados. Restric oes de domnio e de integri-
dade sao casos particulares de asserc
oes. Asserc
oes complexas podem prejudicar
o desempenho do banco de dados.
Um gatilho(trigger) e um comando que e executado pelo sistema automati-

camente, em consequencia de uma modificac
ao no banco de dados. O padrao
SQL-92 nao disp
oe da gatilhos.
A noc
ao de dependencia funcional generaliza o conceito de superchave. Quando
dizemos que uma determinada relac ao possui a dependencia funcional
queremos dizer que para todos os pares de tuplas t1 e t2 , se t1 [] = t2 [] ent
ao
t1 [] = t2 []. Ou seja, se duas tuplas assumem os mesmos valores para o con-
junto de atributos ent ao tambem deve assumir os mesmos valores para o
conjunto de atributos . A clausura do conjunto dependencias funcionais F e
denotada por F + e inclui as dependencias funcionais logicamente implcitas.
469
Captulo 57
Modelagem Entidade
Relacionamento
57.1 Conceitos
Nesta etapa, nos movemos de uma descric
ao informal do que os usu
arios desejam
para uma descric
ao formal. Os conceitos mais importantes sao:
Entidade: Objeto do mundo real disting

uvel de outros objetos, e descrita
utilizando um conjunto de atributos;
Conjunto de Entidades: Uma colec
ao de entidades similares. Exemplo:
todos os funcion
arios;
Chave
Superchave: e o conjunto de um ou mais atributos que, tomados cole-
tivamente, nos permite identificar de maneira unvoca uma entidade
em um conjunto de entidades;
Candidata: superchave em que nenhum subconjunto e superchave;
Prim aria: chave candidata definida pelo projetista do BD para iden-
tificar as entidades;
Estrangeira: atributo de um conjunto de entidades que e chave prim
aria
de outro conjunto de entidades;
Relacionamento: Associac
ao entre duas ou mais entidades;
Conjunto de Relacionamentos: Colec

ao de relacionamentos similares;
Atributo Descritivo: registram informac
ao sobre o relaciomento;
Atributo Multivalorado: quando mais de um valor pode ser inserido, por

exemplo, um funcionario pode ter v
arios dependentes e pode-se criar um
atributo multivalorado para colocar o nome de cada um desses depen-
dentes.
470
57.2 Cardinalidade
Um para um: uma entidade em A est
a associada a no m
aximo uma enti-
dade em B.
Um para muitos: uma entidade em A est

a associada a qualquer n
umero
de entidades em B.
Muitos para muitos: uma entidade em A est

umero
de entidades em B e uma entidade em B est
umero
de entidades em A.
57.3 Representa
c
ao Gr
afica
Conjunto de entidades: ret
angulos;
Atributos: elipses;
Conjunto de relacionamentes: losangos;

Atributos multivalorados: elipses duplas;
Figura 57.1: Um Diagrama Entidade Relacionamento
57.4 Recursos do Modelo Entidade Relaciona-

mento
Conjunto de Entidades Fracas: n ao possui chave prim aria, mas o iden-
tificador e composto juntamente com a chave prim aria de um conjunto

de entidades dominante (forte). Esse identificador e chamado de chave
parcial (pname). Essa relacao e feita atraves de um relacionamento iden-
tificador. Por exemplo, um pedido de compra pode possuir v arios itens,
mas cada um desses itens est a associado a somente um pedido de compra.
Poderia-se associar um identificador parcial para cada item em relac ao ao
seu pedido. A chave parcial poder a ser formada entre esse identificador
parcial e a chave prim aria do conjunto de entidades que representa o pe-
dido. O relacionamento e um para muitos e conjunto de entidades fracam
tem paticipacao total (todo item est a associado a um pedido).
471
Especializac
ao: no caso de um conjunto de entidades que possuem sub-
grupos de entidades, pode-se realizar a especializacao fazendo que esses
subconjuntos tenham os mesmos atributos do conjunto de entidades princi-
pal mais atributos especficos para o subconjunto que n
ao e compartilhado
com outros subconjuntos. E como se fosse uma heranca.
Generalizac
ao: Difere da especializac
ao no sentido de como e feito o pro-
jeto. Na generalizac
ao, o projetista procura atributos em comum para
formar um conjunto de entidades pai. A representac ao no diagrama e a
mesma (uso do losango ISA).
Agregacao: Permite-nos tratar um conjunto de relacionamento como um

conjunto de entidades com o proposito de permitir a participac
ao em out-
ros relacionamentos.
472
Captulo 58
Normaliza
cao
58.1 Aspectos desej

aveis em um bom projeto
Considere o seguinte caso: queremos fazer um relat orio que representa um pe-
dido de compra, gostaramos de obter os nomes dos produtos, seu volume, seu
peso e os seus precos e suponha que alguem tenha pensado num esquema de
item de um pedido da seguinte maneira: item(quantidade, nome do produto,
volume, peso, preco). Sabemos que um determinado produto ter a sempre o
mesmo volume e o mesmo peso. Dizemos que h a redundancia nesse caso, j
a que
poderamos criar outro esquema produto (id produto, volume, peso) e associar-
mos id produto como chaves estrangeira em item. Acabamos de realizar o que
e chamado de decomposic ao. Decomposic oes descuidadas, entretanto, podem
gerar outro tipo de projeto de m a qualidade. Podemos recuperar a relac ao de-
sejada por meio da operacao de junc
ao natural (natural join), mas pode ocorrer
que a resposta alcancada tenha mais tuplas do que realmente deveria ter, devido
a uma m a decomposicao (decomposicao com perda de juncao).
Um conjunto de esquemas de relac oes R1 , R2 , ..., Rn e uma decomposic

ao de
R se R = R1 R2 ... Rn . Assim, e sempre v alido que r r1 r2 ... rn .
Seja R um esquema de relac ao e F um conjunto de dependencias funcionais
sobre R. Sejam R1 e R2 formas de decomposic ao de R. Essa decomposic ao e
uma decomposic ao sem perda de junc ao de R se ao menos uma das seguintes
dependencias funcionais esta em F + :
R1 R 2 R 1
R1 R 2 R 2 .
Outro aspecto que desejamos para o banco de dados e a preservac ao de

dependencia. O sistema deve checar se uma atualizac ao no banco de dados
criar
a uma relac
ao ilegal (que n
ao satisfaca todas dependencias funcionais).
58.2 Forma normal de Boyce-Codd

Uma relacao do esquema R est
a na FNBC (forma normal de Boyce-Codd) com
respeito a conjunto F de dependencias funcionais se todas as dependencias fun-
473
cionais em F + da forma , em que R e R atendem ao menos uma

das exigencias abaixo:
e uma dependencia funcional trivial (isto e, ).

e uma superchave para o esquema R.
58.3 Terceira forma normal

Podemos aceitar uma forma normal mais fraca chamada teceira forma normal
(3FN). Essa forma normal permite dependencias funcionais n
ao-triviais.
Uma relacao do esquema R est a na 3F N com respeito a conjunto F de

dependencias funcionais se todas as dependencias funcionais em F + da forma
, em que R e R atendem ao menos uma das exigencias abaixo:
e uma dependencia funcional trivial.
e uma superchave para o esquema R.

Cada atributo de A em est
a contido em uma chave candidata de R.
Todo esquema F N BC e tambem 3F N . Nem todo FNBC preserva as de-

pendencias funcionais, j
a em um projeto 3F N e sempre possvel garatir as de-
pendencias funcionais e que as decomposicoes s
ao sem perda de juncao. Entre-
tanto, na 3F N pode haver repeticao de informacao e uso de valores nulos para
representarmos um relacionamento entre itens de dados, mas mesmo assim e
menos pior do que n ao garantir a preservac
ao de dependencia.
474
Captulo 59
Transformac
ao do Modelo
Conceitual
Conjunto de entidades fortes: uma coluna para cada um de seus atributos;
Conjunto de entidades fracas: uma columa para cada um de seus atrib-

utos mais as colunas que compreendem os atributos que formam a chave
primaria do conjunto de entidades dominantes;
Conjunto de Relacionamentos: Formado pelos seus atributos descritivos e

pelas chaves prim
arias de cada uma das entidades participantes;
Um conjunto de Relacionamento que possui a cardinalidade muitos para um

ou um para um e n ao possui atributos descritivos n
ao precisa ser representado
em tabela. Por exemplo, no caso de um relacionamento entre um conjunto de
entidades fraca e um conjunto de entidades forte, a chave prim aria do conjunto
de entidades forte funciona como um atributo no conjunto de entidades fraca
(chave estrangeira).
475
Captulo 60
Linguagem SQL
60.1 Criac
ao de tabela
Uma nova tabela pode ser criada especificando o seu nome juntamente com os
nomes das colunas e seus tipos de dado:
CREATE TABLE clima (

cidade varchar(80),
temp_min int, -- temperatura mnima
temp_max int, -- temperatura maxima
prcp real, -- precipita
c~ao
data date
);
O comando INSERT e utilizado para carregar as linhas da tabela:
INSERT INTO clima VALUES (S~

ao Francisco, 46, 50, 0.25, 1994-11-27);
A sintaxe usada anteriormente requer que seja lembrada a ordem das colunas.
Uma sintaxe alternativa permite declarar as colunas explicitamente:
INSERT INTO clima (cidade, temp_min, temp_max, prcp, data)

VALUES (S~
ao Francisco, 43, 57, 0.0, 1994-11-29);
60.2 Consultas
Para ver os dados de uma tabela, a tabela deve ser consultada. O comando
SELECT do SQL e utilizado para esta func
ao. Por exemplo, para ver todas as
linhas da tabela clima digite:
SELECT * FROM clima
Pode ser especificada qualquer express

ao arbitr
aria na lista de selec
ao. Por
exemplo, pode ser escrito
SELECT cidade, (temp_max+temp_min)/2 AS temp_media, data FROM clima
476
Operadores booleanos arbitr

arios (AND, OR e NOT) s
ao permitidos na qual-
ificac
ao da consulta. Por exemplo, o comando abaixo obtem o clima de Sao
Francisco nos dias de chuva:
SELECT * FROM clima

WHERE cidade = S~
ao Francisco
AND prcp > 0.0;
Pode ser desejado que os resultados da selec

ao retornem em uma determi-
nada ordem, ou com as linhas duplicadas removidas:
SELECT DISTINCT cidade

FROM clima
ORDER BY cidade;
A consulta da forma:
SELECT clima.cidade, clima.temp_min, clima.temp_max,
clima.prcp, clima.data, cidades.localizacao
FROM clima, cidades
WHERE cidades.nome = clima.cidade;
Pode ser escrita na forma alternativa:
SELECT *
FROM clima INNER JOIN cidades
ON (clima.cidade = cidades.nome);
Desejamos fazer a varredura da tabela clima e, para cada uma de suas linhas,
encontrar a linha correspondente em cidades. Se nenhuma linha for encontrada,
desejamos que algum valor vazioseja colocado nas colunas da tabela cidades.
Este tipo de consulta e chamado de juncao externa (outer join). As consultas
vistas anteriormente sao junc
oes internas (inner join). O comando ent ao fica
assim:
SELECT *
FROM clima LEFT OUTER JOIN cidades
ON (clima.cidade = cidades.nome);
Tambem e possvel fazer a junc

ao da tabela consigo mesmo. Isto e chamado
de autojunc
ao (self join).
60.3 Func
oes de agrega
cao
Existem funcoes de agregac
ao para contar (count), somar (sum), calcular a
media (avg), o valor m
aximo (max) e o valor mnimo (min) para um conjunto
de linhas.
Como exemplo, podemos obter a maior temperatura mnima ocorrida em
qualquer lugar com
SELECT max(temp_min) FROM clima;
477
Se desejarmos saber a cidade (ou cidades) onde esta leitura ocorreu, podemos
tentar
SELECT cidade FROM clima WHERE temp_min = max(temp_min);

ERRADO!
mas nao funciona porque a func

ao de agregac
ao max nao pode ser usada na
cl
ausula WHERE (esta restric ao existe porque a clausula WHERE determina
as linhas que vao passar para o estagio de agregac
ao e, portanto, precisa ser
avaliada antes das func
oes de agregac
ao serem computadas). Entretanto, uma
forma correta e a subconsulta abaixo:
SELECT cidade FROM clima

WHERE temp_min = (SELECT max(temp_min) FROM clima);
As agregac
oes tambem s
ao muito u
teis quando combinadas com a cl
ausula
GROUP BY. Por exemplo, pode ser obtida a maior temperatura mnima obser-
vada em cada cidade com
SELECT cidade, max(temp_min)

FROM clima
GROUP BY cidade;
Cada resultado da agregacao e calculado sobre as linhas da tabela correspon-

dendo a uma cidade. Estas linhas agrupadas podem ser filtradas utilizando a
cl
ausula HAVING
SELECT cidade, max(temp_min)

FROM clima
GROUP BY cidade
HAVING max(temp_min) < 40;
importante compreender a interac
E ao entre as agregacoes e as cl
ausulas
WHERE e HAVING do SQL. A diferenca fundamental entre WHERE e HAV-
ING e esta: o WHERE seleciona as linhas de entrada antes dos grupos e
agregac
oes serem computados (portanto, controla quais linhas ir ao para o com-
puto da agregacao), enquanto o HAVING seleciona grupos de linhas ap os os
grupos e agregacoes serem computados. Portanto, a cl ausula WHERE n ao
pode conter func
oes de agregac
ao; n
ao faz sentido tentar utilizar uma agregacao
para determinar quais linhas ser ao a entrada da agregacao.
60.4 Atualizac
oes e exclus
oes
As linhas existentes podem ser atualizadas utilizando o comando UPDATE.
Suponha que foi descoberto que as leituras de temperatura est
ao todas mais
altas 2 graus ap
os 28 de novembro de 1994. Estes dados podem ser corrigidos
da seguinte maneira:
UPDATE clima
SET temp_max = temp_max - 2, temp_min = temp_min - 2
WHERE data > 1994-11-28;
478
Suponha que n
ao estamos mais interessados nos dados do clima em Hayward.
Entao precisamos excluir suas linhas da tabela. As exclus oes s
ao realizadas
utilizando o comando DELETE:
DELETE FROM clima WHERE cidade = Hayward;
60.5 Vis
oes
Suponha que a consulta combinando os registros de clima e de localizac ao das
cidades seja de particular interesse para sua aplicac
ao, mas que voce n
ao deseja
digitar esta consulta toda vez que necessitar dela. Voce pode, entao, criar uma
vis
ao baseada na consulta, atribuindo um nome a esta consulta pelo qual e
possvel referenci
a-la como se fosse uma tabela comum.
CREATE VIEW minha_visao AS

SELECT cidade, temp_min, temp_max, prcp, data, localizacao
FROM clima, cidades
WHERE cidade = nome;
60.6 Chaves estrangeiras

Desejamos ter certeza que nao ser
ao inseridas linhas na tabela clima sem que
haja uma entrada correspondente na tabela cidades. Isto e chamado de manter
a integridade referencial dos dados. As declaracoes para as tabelas ficariam
assim:
CREATE TABLE cidades (

cidade varchar(80) primary key,
localizacao point
);
CREATE TABLE clima (

cidade varchar(80) references cidades,
temp_min int,
temp_max int,
prcp real,
data date
);
479
Captulo 61
Conceitos de
Datawarehousing e
Bussiness Inteligence
61.1 Banco de Dados Multidimensionais

Os BDs Multidimensionais sao altamente otimizados para minimizar o tempo
de consulta e apresentac
ao. Os dados extrados dos sistemas fontes s
ao gravados
diversas vezes em vetores ou arraysordenadamente de forma que a realizac ao
da consulta seja implementada como uma simples varredura de uma parte de
um vetor. O BD Multidimensional tambem possui um conjunto de func oes
matem aticas que podem ser estendidas e que s ao executadas dinamicamente ` a
varredura dos registros. Com isso, o sistema trabalha com arquivos tempor arios
menores, reduzindo drasticamente o tempo de I/O.
Claro que a manutenc ao destas estruturas ordenadas s ao muito mais de-

moradas que num BD convencional. Mas como as atualizac oes s
ao realizadas
periodicamente (de mes em mes, geralmente) e o seu tempo n ao e crtico ao
nvel de aplicac
ao (n
ao importa para o usuario se a carga levou 24h, mas sim
que a consulta levou menos de 10 min), n ao existe grande preocupacao com o
tempo de atualizac ao dos dados.
Alem de j
a guardarem os dados de forma ordenada, os BDs Multidimen-
sionais, tambem se utilizam de estruturas auxiliares de consulta que guardam

o resultado de consultas anteriores armazenados em disco e apenas consultam
os registros novos que nao foram consultados na pesquisa anterior, gerando um
incremental. Exemplo: em 01/02/2001 foi realizada uma consulta que demon-
strava o n
umero de produtos vendidos por cidade e mes da venda. Para fazer esta
consulta o banco de dados teve que varrer todos os meses e todas as cidades que
tiveram vendas. Quando esta consulta e realizada novamente em 01/04/2001.
O BD em vez de varrer tudo de novo, apenas procura pelos registros de vendas
de Fevereiro e Marco e utiliza os valores gerados na consulta de 01/02/2001 que
foram armazenadas em um arquivo de consulta.
480
Outra estrutura de consulta muito utilizada e a gerac

ao de diversos nveis de
granularidade das informacoes. Isto e, quando o usu
ario faz uma consulta como
a citada no exemplo acima, o BD em vez de fazer os agrupamentos somente ao
nvel de Cidade e Mes ele dispara simultaneamente agrupamentos por Bairro,
Estado, Semana e Trimestre, supondo que a pr oxima consulta a ser disparada
pelo usu ario seja uma operac
ao de Drill Down ou Roll UP.
Varias outras estrategias de minimizar o tempo de consulta existem, mas os

dois tipos de estrategias apresentadas: consulta incremental e em v
arios nveis
de granularidade sao as mais comumente utilizadas hoje em dia.
Bancos de dados multidimensionais s

ao sistemas propriet
arios que n
ao seguem
padroes (linguagem, API) estabelecidos pela ind
ustria de banco de dados. Isto
se torna uma desvantagem para tais sistemas, uma vez que a arquitetura n ao e
aberta.
61.1.1 Modelagem Multidimensional

O modelo multidimensional visa facilitar a compreens
ao do estruturamento dos
dados armazenados tanto para desenvolvedores quanto para os usu arios do sis-
tema. Neste tipo de modelo existem tres elementos b asicos: os fatos, as di-
mens
oes e as medidas ou vari
aveis.
Fato e uma colec

ao de itens de dados compostos de dados de medidas e de
contexto. O fato reflete a evolucao dos neg
ocios do dia-a-dia e e representado
implementado em tabelas denominadas tabelas de fato
por valores numericos. E
(fact tables).
Dimensoes s
ao os elementos que participam de um fato. Elas determinam o
contexto de um assunto de neg ocios. As dimens
oes normalmente n ao possuem
valores numericos, pois s
ao somente descritivas e classificat
orias dos elemen-
tos que participam de um fato. Um Datawarehouse que analisa vendas de um
produto (fato) poderia ter as seguintes dimens
oes: tempo, localizac
ao, clientes,
vendedores.
As dimensoes podem ser compostas por membros que podem conter hierar-
quias. Membros (atributos) s ao as possveis divis
oes ou classificac
oes de uma
dimensao. A dimens ao tempo poderia ser dividida nos seguintes membros: ano,
trimestre e mes e a dimens
ao localizac
ao em: cidade, estado e pas.
As Medidas (variaveis) s
ao os atributos numericos que representam um fato
e e sobre eles que s
ao feitas as analises do neg
ocio. Sao por exemplo, o valor
em reais das vendas, o n umero de unidades vendidas, o custo da venda. Uma
medida e determinada pela combinac ao das dimensoes que participam de um
fato, e est
ao localizadas como atributos de um fato.
Para facilitar o entendimento, o modelo multidimensional e representado

pelo desenho de um cubo. Todavia, o n
umero de dimens
oes geralmente e maior
481
que tres, o que sugere um hipercubo. Como um hipercubo e algo difcil de se

representar à literatura utiliza geralmente como referencia somente o cubo. A
figura 61.1 mostra um cubo para a medida vendas.
Figura 61.1: Abordagem Dimensional representada por cubos
Utilizando a abstrac
ao da organizac
ao da informac
ao em um cubo, podemos
definir mais facilmente as quatro operacoes b
asicas OLAP:
Drill Down: consiste em detalhar o nvel dos dados, navegar do mais alto
nvel ate o dado detalhado. Exemplo: Em vez de ver as vendas anuais,
passar a ver as vendas trimestrais. Ou em vez de ver as vendas por estado,
ver por cidade;
Roll UP: operac

ao inversa da Drill Down. Navegac
ao do nvel de detalhe
para o mais alto nvel de sumarizac
ao de dados;
Slice: operac ao de corte do cubo, mantendo a mesma perspectiva de vis

ao.
A ideia e selecionar apenas algumas dimensoes ou membros de dimens oes.
Exemplo: analisar somente as vendas do Estado de S ao Paulo, no intervalo
de 1998 ate 2001;
Dice: mudanca da perspectiva de visao. Pode simplesmente ser a alterac
ao
da posic
ao das linhas pelas colunas numa tabela, ou a apresentac ao dos
dados de tras para frente (2001, 2000,1999 em vez de 1999, 2000, 2001).
Ou operacoes mais complexas que mostram a variabilidade de uma medida
ao longo das diferentes instanciac
oes de uma ou mais dimensoes.
Dois modelos multidimensionais comuns s ao: o esquema estrela e o flocos de

neve (snowflake). No esquema estrela existe uma tabela dominante no centro
do esquema. Esta e a u
nica tabela com m ultiplos relacionamentos para as out-
ras tabelas. As outras tabelas possuem um u nico relacionamento para a tabela
central. A tabela central e chamada fato (fact table) e as outras tabelas s ao
chamados de dimens ao (dimension table). A figura 61.2 ilustra o esquema es-
trela.
Como ja dissemos uma dimens ao pode conter uma ou mais hierarquias que
podem ser decompostas em tabelas separadas, gerando uma estrutura conhecida
por snowflake. A figura 61.3 ilustra uma estrutura snowflake.
482
Figura 61.2: Modelo Estrela
Figura 61.3: Modelo Snowflake
Na verdade, snowflake significa a normalizac ao da tabela. Isto elimina

redund
ancia e diminui o espaco em disco. Mas, em um datawarehouse, re-
dund
ancia nao e importante porque nao e um ambiente transacional, operacoes
de update nao ocorrem com freq uencia. Espaco fsico tambem e irrelevante
porque a tabela de fato e que ocupar
a a maior parte deste espaco.
Para uma boa performance do esquema estrela, e importante determinar o

nvel de consolidac
ao, ou a granularidade, dos fatos. O fato pode estar no nvel
de transacao, por exemplo, a venda individual de determinado produto, ou o
fato pode ser armazenado com uma consolidac ao maior, como por exemplo, a
venda de determinada linha de produtos em um dia. Armazenando o fato ao
nvel de transac
ao faz com que o tamanho da tabela fato se torne excessivo e,
alem disso, este nvel de detalhamento pode ser de pouca utilidade.
61.2 Datawarehousing
Um datawarehouse (ou armazem de dados, ou dep osito de dados) e um sistema

de computacao utilizado para armazenar informac oes relativas `
as atividades de
uma organizac ao em bancos de dados, de forma consolidada. O desenho da
base de dados favorece os relat orios, a analise de grandes volumes de dados e
a obtenc
ao de informac
oes estrategicas que podem facilitar a tomada de decisao.
O datawarehouse possibilita a an
alise de grandes volumes de dados, coleta-
dos dos sistemas transacionais (OLTP). Sao as chamadas series hist
oricas que
possibilitam uma melhor analise de eventos passados, oferecendo suporte ` as
483
tomadas de decis oes presentes e a previsao de eventos futuros. Por definic

ao, os
dados em um datawarehouse n ao s
ao vol
ateis, ou seja, eles n
ao mudam, salvo
quando e necessario fazer correc
oes de dados previamente carregados. Os dados
est
ao disponveis somente para leitura e n ao podem ser alterados. A ferramenta
mais popular para explorac ao de um datawarehouse e a Online Analytical Pro-
cessing OLAP ou Processo Analtico em Tempo Real, mas muitas outras podem
ser usadas.
Os datawarehouse surgiram como conceito academico na decada de 80. Com

o amadurecimento dos sistemas de informac ao empresariais, as necessidades de
analise dos dados cresceram paralelamente. Os sistemas OLTP n ao conseguiam
cumprir a tarefa de an alise com a simples gerac
ao de relat
orios. Nesse contexto,
a implementac ao do datawarehouse passou a se tornar realidade nas grandes
corporacoes. O mercado de ferramentas de datawarehouse, que faz parte do
mercado de Business Intelligence, cresceu ent ao, e ferramentas melhores e mais
sofisticadas foram desenvolvidas para apoiar a estrutura do data warehouse e
sua utilizac
ao.
Atualmente, por sua capacidade de sumarizar a analisar grandes volumes

de dados,o datawarehouse e o n ucleo dos sistemas de informac oes gerenciais e
apoio `
a decis
ao das principais soluc
oes de business intelligence do mercado.
Um Datawarehouse e caracterizado como uma colec ao de dados orientada a

assunto, integrada, n ao-vol
atil e variante no tempo que auxiliam nas decisoes
de gerenciamento. Datawarehouses fornecem acesso aos dados para an alises
complexas, descoberta de conhecimento e tomada de decis oes. Algumas carac-
tersticas importantes dos datawarehouses s ao:
Orientada ao assunto: pois o objetivo e tomar decis

oes sobre o assunto-
tema dos dados;
Integrada: pois deve consolidar dados de diferentes origens ou fontes;
Nao vol
atil: pois as informac
oes j
a presentes no banco s
ao raramente
modificadas (sobrescrita). Os novos dados s ao absorvidos pelo banco,
integrando-se com as informacoes previamente armazenadas;
Variante no tempo: pois deve-se manter um hist

orico dos dados, per-
mitindo comparac
oes ao longo do tempo.
Tipicamente o datawarehouse e mantido separadamente dos bancos de dados

operacionais de uma organizac ao. Existem muitas raz oes para fazer isto. Um
datawarehouse suporta requerimentos funcionais e de performance para con-
sultas OLAP (abordagem dimensional para o suporte ` a decis
ao), os quais s
ao
bastante diferentes de aplicac
oes online transaction processing (OLTP) tradi-
cionalmente suportadas por banco de dados operacionais. Aplicac oes OLTP
tipicamente automatizam tarefas de processamento de dados do dia a dia tais
como ordem de entrada de produtos e transac oes bancarias que s
ao processadas
durante todo o dia, dia ap
os dia. Estas tarefas s
ao estruturadas e repetitivas, e
consistem de transac
oes curtas, at
omicas e isoladas.
484
Estas transac oes requerem detalhes, dados atualizados, leitura e atualizac

ao
de poucos (dezenas de) registros que s ao acessados tipicamente por suas chaves
primarias. Bancos de dados operacionais tendem a ter tamanho de centenas de
megabytes a gigabytes. Consistencia e capacidade de recuperac ao do banco de
dados sao crticas e a maximizac
ao da vaz
ao de transac
oes s
ao metricas chaves
de performance. Conseq uentemente, o banco de dados e projetado para refletir
a Sem antica operacional de aplicacoes conhecidas e, em particular, minimizar
conflitos de concorrencia.
Datawarehouse, em contraste, e dirigido a suporte a decis ao. Dados hist

oricos,
sumariados e consolidados s ao mais importantes que dados detalhados em reg-
istros individuais. Ja que o datawarehouse contem dados consolidados geral-
mente a partir de muitos banco de dados operacionais, sobre muitos perodos
de tempo, eles tendem a serem maiores que os banco de dados operacionais.
Datawarehouse de empresas s ao projetados para ter tamanho de centenas de gi-
gabytes a terabytes. O trabalho pesado de um datawarehouse s ao as consultas
intensivas na maioria das vezes ad hoc (consultas complexas que podem acessar
milhoes de registros e realizar muitas buscas por registros), uni oes e agregac
oes.
Vazao de consulta e tempo de resposta s ao mais importantes que vaz ao de
transac
oes. Para facilitar an alises e visualizac
oes complexas, os dados em um
datawarehouse s ao tipicamente modelados multidimensionalmente. Por exem-
plo, em um datawarehouse de vendas, tempo de vendas, lugar de vendas, vende-
dor e produto podem ser algumas dimens oes de interesse. Freq
uentemente, estas
dimens oes s
ao hier
arquicas, o tempo pode ser organizado na hierarquia dia-mes-
trimestre-ano, produto como produto-categoria-ind ustria (marca) para facilitar
e ampliar o domnio de consultas que podem ser feitas no Datawarehouse. O
modelo estrela, floco de neves s ao dois exemplos de esquemas multidimensionais
com os quais um datawarehouse pode ser modelado.
61.3 OLTP, OLAP, MOLAP, ROLAP e HOLAP

OLTP ` aE um acronimo de Online Transaction Processing ou Processamento de
transac
oes em tempo-real. Sao sistemas que se encarregam de registrar todas
as transac
oes contidas em uma determinada operac ao organizacional, ou seja, e
uma aplicacao que tem como caracterstica principal muitas atualizac
oes em da-
dos operacionais. Por exemplo: sistema de transac oes bancarias registra todas
as operac
oes efetuadas em um banco. Os ERPs (Enteprise Resource Planning)
s
ao sistemas que se enquadram nessa categoria.
OLAP ` aE um acronimo de Online Analitical Processing ou Processamento

analtico em tempo-real. E a categoria de tecnologia de software que capacita
os analistas, gerentes e executivos a conseguir obter discernimento nos dados
atraves de um acesso r apido, consistente e interativo, para uma larga variedade
de possibilidades de vis oes da informacao que vem a ser transformada a par-
tir de dados cruspara refletir o real dimensionamento da corporac ao como
entendido pelo usu ario. A funcionalidade OLAP e caracterizada pela an alise
dinamica multidimensional dos dados consolidados da corporac ao, dando su-
porte ` as atividades de analise e navegac
ao do usu ario final. A funcionalidade
485
OLAP e implementada em um modo cliente/servidor multi-usu ario, e oferece

consistentemente r apidas respostas para consultas, apesar do tamanho e com-
plexidade do banco de dados. Ela ajuda o usu ario a sintetizar as informacoes da
corporacao atraves de vis
oes comparativas e personalizadas, assim como atraves
de analises de hist
oricos e projec
oes de dados em v arios modelos de cen arios do
tipo what-if. Alguns exemplos de consultas tpicas de OLAP s ao: Quais os
produtos mais bem vendidos no mes passado? Quais os 10 piores vendedores
do departamento X? Qual a media salarial dos funcion arios de inform atica na
regi
ao sul nos ultimos 5 anos? dentre outras.
Caractersticas OLTP OLAP

Operac
ao Tpica Transac
ao Analise
Granularidade At
omico Agregado
Idade dos Dados Presente Hist
orico, Atual e Projetado
Recuperac ao Poucos Registros Muitos Registros
Orientac
ao Registro Arrays
Modelagem Processo Assunto
Usuarios Muitos Poucos
Tabela 61.1: OLTP vs. OLAP
Quanto `
a localizac
ao dos dados a serem utilizados na an
alise, atualmente
existem duas abordagens:
Um banco de dados multidimensional especializado;
Um datawarehouse implementado com a tecnologia de banco de dados

relacional, mas otimizado para a tarefa de an
alise.
Sistemas OLAP que implementam a primeira abordagem s

ao chamados de
MOLAP (Multidimensional OLAP) e aqueles que implementam a segunda s
ao
chamados ROLAP (Relational OLAP).
ROLAP ` a OLAP Relacional. Sistemas ROLAP fornecem an alise multidi-

mensional de dados armazenados em uma base de dados relacional. Atualmente
existem duas maneiras de se fazer este trabalho:
Fazer todo o processamento dos dados no servidor da base de dados; o

servidor OLAP gera os comandos SQL em m ultiplos passos e as tabelas

temporarias necess
arias para o devido processamento das consultas;
Executar comandos SQL para recuperar os dados, mas fazer todo o pro-
cessamento (incluindo joins e agregac
oes) no servidor OLAP.
Alem das caractersticas b

asicas de sistemas OLAP, servidores ROLAP de-
vem tambem:
Utilizar metadados para descrever o modelo dos dados e para auxiliar na

construc
ao das consultas. Desta maneira um analista pode executar suas
an
alises utilizando seus pr
oprios termos;
486
Criar comandos SQL otimizados para os bancos de dados com o qual

trabalha.
A principal vantagem de se adotar uma soluc ao ROLAP reside na utilizac ao

de uma tecnologia estabelecida, de arquitetura aberta e padronizada como e a
relacional, beneficiando-se da diversidade de plataformas, escalabilidade e par-
alelismo de hardware (SMP e MPP). Quanto ` as limitac
oes, pode-se citar o pobre
conjunto de funcoes para an
alise, a inadequacao do esquema estrela para atu-
alizac
ao dos dados e as solucoes propriet
arias para metadados que acaba por
anular muitas das vantagens do uso da tecnologia relacional.
MOLAP ` a OLAP multidimensional. MOLAP e uma classe de sistemas que

permite a execucao de analises bastante sofisticadas usando como gerenciador
de dados um banco de dados multidimensional. Em um banco de dados MO-
LAP, os dados s ao mantidos em arranjos e indexados de maneira a prover um
otimo desempenho no acesso a qualquer elemento. A indexac
ao, a antecipac
ao
da maneira como os dados ser ao acessados e o alto grau de agregac
ao dos dados
fazem com que sistemas MOLAP tenham um excelente desempenho. Alem de
serem r
apidos, outra grande vantagem desses sistemas e o rico e complexo con-
junto de func
oes de an
alise que oferecem.
HOLAP ` a O armazenamento HOLAP (OLAP Hbrido) e uma combinacao

dos tipos de armazenamento MOLAP e ROLAP. Os dados de agregac ao s
ao
armazenados em MOLAP, enquanto os dados de base s
ao deixados no banco de
dados relacional.
61.4 Outros conceitos importantes

Data Mart: e um subconjunto de um data warehouse. E um repositorio
de dados extrados das fontes operacionais ou de um data warehouse que e
projetado para servir as necessidades particulares de um grupo especfico.
Na pratica, o data ware house e data mart pode trabalhar juntos. O data
warehouse atende as necessidades estrategicas da organizac
ao, enquanto
o data mart atende as necessidades gerenciais mais a nvel operacional.
Quando os data mart atualiza seus dados atraves do data warehouse, ele
e considerado de dependente. Quando ele atualiza os dados atraves das
fontes operacionais, ele e considerado independente;
Agregacoes: Grande parte dos usuarios n

ao est
a interessada em realizar
uma consulta que retorne uma grande quantidade de linhas de uma tabela
de fatos, mas sim em sumarizar os resultados usando operacoes de soma ou
media por exemplo. Para evitar que as mesmas operacoes sejam realizadas
a cada vez que um usu ario execute uma consulta, e importante realizar
um levantamento das agregac oes e sumarios nos quais os usu arios est
ao
interessados;
Funcionamento (Fluxo de dados). Os dados para serem usados para fins

analticos devem ser transformados e carregados dos sistemas OLTP para
487
o Data Warehouse. Durante essas transformac oes (realizadas pelas fer-

ramentas ETL Extrair, Transformar e Carregar) s ao criados resumos e
agregacoes entre esses dados, transformando-os em informac oes de mais
alto nvel e mais signifitivas para os analistas, gerentes e executivos;
Metadados: s ao os chamados dados sobre os dados. E um mapeamento

dos dados do modo como foram extrados das fontes operacionais e como
est
ao inseridos no data warehouse. Os metadados definem e descrevem
os dados de negocio (valor aos dados) e os tipos de dados (definic
oes de
tabelas, atributos, domnio e relac
oes). Os metadados sao geralmente
armazenados em reposit orios separados ao alcance dos usu
arios;
Granularidade: e o nvel de detalhe contido nas unidades de dados ex-

istentes no data warehouse. A granularidade e importante porque pode
diminui o tempo de acesso aos dados que realmente interessam e dimin-
uem a quantidade de discos r apidos e caros necess
arios para armazenar
uma grande quantidade de dados hist oricos.
488
Parte XII
Administra
cao de Bancos
de Dados Relacionais
489
Captulo 62
Ger
encia de Transa
coes
Uma transac ao e a unidade l

ogica de processamento, e pode incluir uma ou mais
operac
oes sobre o Banco de Dados. Para garantir a correc ao, uma transac
ao
deve ser executada ate o final. As duas operac oes basicas fornecidas por um
banco de dados s ao READ e WRITE. As fronteiras de uma transac ao podem
ser definidas explicitamente na aplicacao atraves das chamadas BEGIN TRANS-
ACTION e END TRANSACTION.
Entende-se por transac

oes concorrentes aquelas que s
ao executadas ao mesmo
tempo e pelo menos uma operac ao de WRITE e executada por alguma das
transac
oes. A possibilidade de existir transac
oes sendo executadas de forma
concorrente faz com que o SGBD utilize tecnicas para realizar o controle de
concorrencia. Uma vez iniciado o processamento da transac ao, o SGBD deve
garantir que ela ser
a executada ate o final e os resultados serao armazenados
de forma permanete. No entanto, durante a execuc ao de uma transac ao podem
ocorrer falhas como crash do sistema, falhas no disco, catastrofes. Isso faz com
que o SGBD tenha que utilizar tecnicas de Recuperac ao em caso de falhas.
Para efeitos e recuperac

ao s
ao utilizadas as seguintes operac
oes sobre as
transac
oes:
BEGIN TRANSACTION - Marca o incio da transac

ao;
READ/WRITE - Executa operac

oes como parte da transac
ao;
END TRANSACTION - Especifica o fim das operac
oes de leitura e escrita;
COMMIT TRANSACTION - Confirma o succeso da transac

ao;
ROLLBACK - Indica que ocorreram problemas com a transac

ao.
Alterac
oes devem ser desfeitas. As transac
ao podem ainda se encontrar em
cinco estados que s
ao: (1)Ativa; (2)Parcialmente Confirmada; (3)Confirmada;
(4)Falha; (5)Terminada.
As propriedades desej
aveis de uma transac
ao devem ser:
490
Atomicidade: Garantir que ser

ao executadas ate o fim;
Consistencia - Devem levar o Banco de Dados de um estado consistente
para outro tambem consistente;
Isolamento - A execucao de uma transac

ao n
ao deve ser prejudicada por
transac
oes concorrentes;
Durabilidade - As alterac
oes realizadas por uma transac
ao confirmada
devem ser persistitas no Banco de Dados.
Estas quatro propriedades s

ao usualmente referenciadas como ACID.
Quando v arias transac

oes s
ao executas simultaneamente, as instrucoes de
cada transacao podem ser intercaladas. A atribuic
ao da ordem dessas instruc
oes
e conhecido como escala de execuc responsabilidade do SGDB escolher uma
ao. E
escala que deixe o banco de dados em estado inconsistente. As u nicas operacoes
significativas de uma transacao, do ponto de vista da escala de execucao, sao
suas instruc
oes de leitura e escrita.
Considere uma escala de execuc ao com duas instruc oes sucessivas Ii e Ij ,

das transac
oes Ti e Tj , respectivamente. Se Ii e Ij referem-se a itens de dados
diferentes, ent
ao podemos alternar Ii e Ij sem afetar os resultados de qualquer
instruc
ao da escala. J
a quando se referem aos mesmos dados temos os seguintes
casos:
1. Ii = read(Q), Ij = read(Q): a seq

uencia n
ao importa;
2. Ii = read(Q), Ij = write(Q): a ordem importa, pois se Ii vier depois de

Ij , Ii ir
a ler o valor escrito por Ij ;
3. Ii = write(Q), Ij = read(Q): a ordem importa, por raz

oes semelhantes a
anterior;
4. Ii = write(Q), Ij = write(Q): a ordem importa, n ao afeta as transac
oes
Ti e Tj , entretanto, o valor obtido pela pr
oxima instruc
ao de leitura sobre
Q sera afetado.
Dizemos que Ii e Ij entram em conflito caso a ordem importe. Se uma escala

de execucao puder ser transformada em outra por uma serie de trocas de in-
struc
oes n
ao-conflitantes, dizemos que essas escalas de execuc
ao s
ao equivalentes
em conflito. Dizemos que uma escala e conflito serializ avel se ela e equivalente
em conflito à uma escala seq uencial (uma escala que contem as instruc oes de
cada transacao agrupadas). E possvel ter duas escalas de execucao que pro-
duzam o mesmo resultado, mas que n ao sejam equivalentes em conflito.
491
Captulo 63
Controle de Concorr
encia
Entende-se por transacoes concorrentes aquelas que desejam executar ao mesmo

tempo e pelo menos uma operac ao de WRITE precisa ser realizada. O SGBD
e respons
avel por garantir o acesso mutuamente exclusivo a um item de dados
qualquer. Em outras palavras, enquanto uma transac ao acessa um item de dado,
nenhuma outra poder a modifica-lo. A forma mais simples de se implementar
o controle de concorrencia e a utilizac
ao de mecanismos de bloqueio baseados
em locks bin
arios, atraves das operac oes b
asicas lock e unlock, que devem ser
aplicadas antes e depois da realizac ao de uma operac ao qualquer (READ ou
WRITE) sobre qualquer item de dados.
Os locks bin arios tem o incoveniente de n ao permitir que duas ou mais

transac
oes que desejem realizar operac oes apenas de leitura acessem o item si-
multaneamente. Isso diminui o desempenho do sistema, uma vez que muitas
transac
oes tem que aguardar na fila de espera por acesso a um item de da-
dos. Para contornar esse problema, um outro mecanismo de lock baseado em 3
operac
oes foi criado. Quando um transac ao deseja aenas ler um item, ela realiza
uma operac ao read lock, permitindo que outras transac oes que desejem apenas
ler o mesmo item tambem possam executar simultaneamente. Se uma operac ao
deseja escrever, deve primeiro executar uma operac ao do tipo write lock. Nen-
huma operac ao de leitura ou escrita pode ser realizada por outra transac
ao sobre
um item que esteja bloqueado para escrita. A operac ao unlock deve ser aplicada
apos o termino das operac oes de leitura ou escrita por parte das transac
oes que
detem o lock de um item.
E comum que uma transac ao deseje mudar o tipo de lock que possui so-
bre um determinado item. Esta operac ao e chamada de convers ao de lock. Se
apenas uma transac
ao possuir o read lock, ela pode atualiz
a-lo para write lock.
Uma transac
ao que possua um write lock pode converte-lo para read lock ap os
terminar suas operac
oes de escria. Essa operac
oes s
ao tambem chamadas up-
grade e downgrade.
Os locks bin
arios e os locks read/write embora garantam a exclusividade
mutua, n
ao podem garantir a serializac
ao na execuc
ao de transac
oes concor-
rentes. Um outro protocolo que visa solucionar os dois problemas e o chamado
Two-Phase Locking (2PL). As fases sao: (i) Crescimento (Growning) e (ii) En-
492
colhimento (Shrinking). Todos os read lock, write lock e upgrdrades ocorrem na

primeira fase, enquanto unlock e downgrade ocorrem na segunda.
Um problema dos protocolos de bloqueio e a possibilidade de ocorrencia

de deadlocks. Um protocolo de prevenc ao de deadlocks e baseado em times-
tamps, que s ao identificadores unicos associados a cada transacao. Outras duas
tecnicas para identificac
ao e prevenc
ao de deadlocks s
ao timeouts e grafos (Wait-
For Graphs). Protocolos baseados em timestamps tambem podem ser utilizados
para controle de concorrencia. Os valores do timestamp para um dado item X
sao: readTS(X ) e writeTS(X). Eles indicam a u ltima leitura e escrita realizadas
sobre o item X respectivamente.
Uma outra tecnica para controle de Concorrencia basea-se em guardar val-

ores antigos de um determinado item. Procolos que se utilizam dessa tecnica
s
ao chamados Multiversao. Operac
oes de leitura que antes em outros protocolos
n
ao seriam permitidas, podem ser realizadas fornecendo-se a vers ao antiga de
um item de dado. O principal encoveniente desta tecnica e a necessidade de
mais espaco em disco.
A granularidade de um item de dado tambem exerce grande influencia no de-

sempenho de operac oes de controle de concorrencia. Por exemplo, uma transac
ao
que deseja realizar operac
oes sobre um resgistro, pode tornar ineficiente o con-
trole de transac
oes se bloquear inadequadamente um bloco fsico inteiro. Pro-
tocolos que determinam tipo de bloqueio de acordo com a granularidade s ao
chamados Multiple Granularity Lockig (MGL).
493
Captulo 64
Ger
encia de Desempenho
O Design fsico do Banco de Dados e o processo de escolha das estruturas de

armazenamento e metodos de acesso de forma que um bom desempenho possa
ser atingido pelas diversas aplicac
oes. Cada SGBD oferece uma diversidade de
opc
oes de organizac
ao de arquivos e metodos de acessos especiais como ndices,
clustering de registros relacionados, encadeamento de registros relacionados us-
ando ponteiros, e funcoes hash. Os criterios utilizados que guiam a escolha das
opc
oes de design fsico s
ao o Tempo de Rsposta, a Utilizac ao do Espaco e o
Throughput de Transac oes. O desempenho das estruturas e metodos de acesso
depende fundamentalmente do tamanho dos arquivos, portanto durante a fase
de design devem ser realizadas estimativas de crescimento dos arquivos. O
crescimento pode se dar tanto no tamanho dos registros assim como no n umero
de registros por arquivo.
A maioria dos SGBDs possuem ferramentas de monitorac ao que coletam es-

tatsticas de desempenho, que s ao mantidas no Cat alogo do Sistema (System
Catalog). As informac oes dizem respeito, por exemplo, ` a n
umero de chamadas
de transacoes ou queries, atividade de I/O por arquivo, numero de p aginas por
arquivo, n umero de regsitros por ndice e frequencia de utilizac
ao dos ndices.
Assim que os requisitos do sistema mudam, pode se tornar necess ario adicionar
ou remover tabelas, reorganizar aquivos (mudar metodo de acesso prim ario),
dropar ndices antigos e criar novos.
Exemplos de atividades importantes no design fsico de um Banco de Da-

dos: (i)An alise de Transac
oes de de Queries - Envolve determinar arquivos en-
volvidos, atributos mais acessados, atributos utilizados em operac oes de JOIN,

e determinac ao de operacoes predominantes (SELECT, UPDATE, INSERT,
DELETE); (ii)Estimativa da Frequencia das Chamadas de Transac oes e Queries
- Geralmente para um grande volume de processamento, e v alida a regra infor-
mal que diz que 80% do processamento e gasto com 20% das transac oes e queries;
(iii)Restric
oes de Tempo - Identificar das restric
oes de tempo de transac oes e
queries; (iv)Restric oes de Unicidade de Atributos - Devem ser estabelecidos
metodos de acesso para todas as chaves candidatas ou conjunto de chaves candi-
datas (ex: PK ou UNIQUE), tendo por objetivo otimizar os testes de unicidade.
Os indces primarios e de clustering est

ao diretamente relacionados com a
494
ordenacao fsica dos registros no disco. Portanto, pode ser definido no m aximo
um ndice deste tipo. Embora o desempenho das operac oes de consulta seja
otimizado com a utilizac ao de ndices, e importante ressaltar que a existencia
de ndices representa um overhead significativo nas operac oes de inserc
ao, atu-
alizac
ao e exclus ao. Para consultas baseadas em multiplos campos, podem ser
definidos ndices m ultiplos, ou seja, baseado em 2 ou mais campos. Indices do
tipo clustering s ao especialemte u teis em consultas envolvendo intervalo (range
queries). Os ndices baseados em B+Trees s ao u
teis para pesquisas em inter-
valos e testes de igualdade, enquanto os ndices baseados em func oes hash s ao
extremamente eficientes para testes de igualdade, podendo otimizar bastante
operacoes de JOIN.
Uma outra estrategia utilizada para otimizac ao em Bancos de Dados e a

Desnormalizac ao. Essa tecnica consiste em armazenar o banco de dados em uma
forma normal mais fraca como a 1NF ou 2NF, introduzindo algumas depedencias
funcionais que nao existiriam nas formas BCNF ou 4NF. Essa tecnica se baseia
em eliminar a necessidade de operac oes de JOIN, de forma que consultas pos-
sam ser respondidas acessando o menor n umero de arquivos possveis. Outras
duas tecnicas que podem ser utilizadas s ao o Particionamento Vertical, que con-
siste na divis
ao de um tabela e m ultiplas tabelas de colunas iguais, porem com
um n umero menor de linhas por tabela, e o Particionamento Horizontal, que
consiste em transformar uma relac ao R(K, A, B, C, D, ...) em m ultiplas relac
oes
R1 (K, A, B), R2 (K, C, D), R3 (K, ...). As tecnicas de particionamento s ao inter-
ressantes pois nao sacrificam a forma normal da relac ao original.
Alguns cuidados adicionais podem ser tomados para garantir o bom desem-
penho do sistema. A utilizacao da operac
ao DISTINCT causa uma operacao de
ordenac
ao, e portanto e muito custosa. Cl
ausulas DISTINC redundantes devem
ser eliminadas. Deve-se ter cuidado com a utilizac ao de tabelas tempor
arias,
porem em casos especias elas podem ser u teis.
SELECT SSN FROM EMPLOYEE E

WHERE SALARY = SELECT MAX (SALARY) FROM EMPLOYEE AS M
WHERE M.DNO = E.DNO
No caso acima, a utilizacao de uma tabela tempor

aria pode impedir que
o c
alculo do sal
ario m
aximo por departamento seja realizado para todos os
empregados da tabela E.
SELECT MAX (SALARY) AS HIGHSALARY, DNO INTO TEMP

FROM EMPLOYEE GROUP BY DNO
SELECT SSN FROM EMPLOYEE E, TEMP T

WHERE E.SALARY = T.HIGHSALARY AND E.DNO = T.DNO
Alguns otimizadores de consulta n ao sao capazes de determinar em qual

ordem as tabelas que aparecem na cl
ausula FROM devem ser varridas, e utilizam
na execuc
ao a ordem em que elas aparecem na cl ausula. Portanto e importante
que se organize as tabelas de forma que as tabelas menores sejam varridas
enquanto as tabelas maiores sejam indexadas de forma adequada. Condic oes
OR na clausula where podem inibir a utilizac
ao de ndices, portanto a estrategia
495
ser tomada e separar a querie em duas, forcando a utilizac

ao do ndice, e realizar
uma operacao UNION na sequencia. As operac oes IN, =ALL, =ANY, =SOME
devem ser substitudas por operac
oes do tipo JOIN sempre que possvel.
Processamento de consultas s ao atividades envolvidas em extrair dados de
um banco de dados. O custo do processamento de uma consulta e principalmente
determinado pelo acesso ao disco. Os passos envolvidos no processamento de
consultas s
ao:
1. An
alise sint
atica e traduc
ao;
2. Otimizac
ao;
3. Avaliac
ao.
O processo de traducao e semelhante `

a tarefa de um analisador sintatico em
um compilador. A otimizac ao, geralmente, fica a cargo do SGDB, no caso do
modelo relacional. J a para os modelos de rede e hier arquico, a otimizac
ao fica
a cargo do programador. Um plano de execuc ao de consulta e um conjunto de
operac
oes primitivas que sao usadas para avaliar uma consulta. Os diferentes
planos de execucao podem possuir diferentes custos. A otimizac ao de consultas
e o processo de selecionar o plano de execuc ao mais eficiente para uma con-
sulta. Um aspectos de otimizac ao envolve a procura de expressao mais eficiente
no nvel de
algebra relacional, mas diversas outras estrategias sao importantes
como a escolha de um algoritmo para ser usado na execuc ao de uma operac ao
e a escolha de ndices a usar.
Para escolher diferentes planos de execucao, o otimizador deve estimar o

custo de cada plano de avaliac
ao. Os otimizadores de consulta usam informac
oes
estatsticas armazenadas em um cat alogo e incluem:
N
umero de tuplas de cada relac
ao;
N
umero de blocos que contem as tuplas de cada relac
ao;
N
umero de bytes de uma tupla para uma certa relac
ao;
N
umero de valores distintos que aparecem numa relac
ao para um deter-
minado atributo;
N
umero medio de registros que satisfazem uma condic
ao de igualdade para
um determinado atributo.
Podemos processar consultas que envolvem selec oes simples por meio da ex-
ecuc
ao de uma varredura linear, de uma procura bin aria ou do uso de ndices.
Podemos tratar as selecoes complexas computando uni oes e intersecc
oes dos re-
sultados de selec
oes simples. Podemos ordenar relacoes maiores que a mem oria
usando o algoritmo do merge-sort externo. Uma junc ao pode ser calculada por
diversos algoritmos e o sistema deve ser sagaz para escolher a melhor alternativa
para cada caso.
496
Parte XIII
Oracle e Microsoft SQL

Server
497
Captulo 65
Administra
c
ao de Bancos
de Dados Oracle
65.1 Arquitetura de um Servidor Oracle

65.1.1 Estruturas em mem
oria
Para operar, uma inst
ancia Oracle aloca uma serie de
areas de cache em mem
oria
para armazenar tres estruturas que s
ao o SGA (System Global Area), o PGA
(Program Global Area) e as Sort Areas. O SGA e uma area unica de mem
oria
compartilhada composta por tres componentes principais que s ao:
Database Buffer Cache (DBBC): o DBBC e uma area de mem oria que
armazena os blocos de dados lidos do disco. Quando um processo necessita
de acessar dados do banco ele primeiro consulta essa area de mem oria.
Todas as operacoes sobre os dados do banco s ao realizadas nessa area
antes de serem persistidas em disco. No Oracle, a poltica de substituic
ao
de blocos utilizada e a LRU (Last Recently Used );
Shared Pool: o shared pool e uma area compartilhada que armazena in-
formac
oes sobre as instruc
oes SQL enviadas pelos processos usu ario (texto
do comando, planos de execuc ao etc.) e informac
oes sobre o dicion
ario de
dados (nome das tabelas, colunas, tipos, privilegios etc.);
Redo Log Buffer: buffer circular que contem informac oes sobre as modi-
ficac
oes efetuadas no banco de dados. O redo log buffer e uma das estrturas
utilizadas para realizar a recuperacao do banco de dados. E importante
ressaltar que o redo log buffer e utilizado apenas para recuperacao e nao
para operac oes de rollback;
Ja o PGA, em um sistema single-threaded, e uma area de mem oria n

ao com-
partilhada utlizada par guardar informac
oes de controle para um u nico processo.
O PGA armazena informac oes como arrays, estado de cursores e informacoes so-
bre ses
oes de usuarios. Quando trata-se de um sistema multi-threaded (MTS),
as informac
oes sobre sessoes de usuarios s
ao guardadas em uma outra area
chamada UGA (User Global Area), que e alocada no shared pool.
498
A Sort Area e uma area de mem oria compartilhada alocada especialmente

para realizac
ao de operac
oes que exigem ordenac
ao, como SORT BY, GROUP
BY e DISTINCT. Quando o tamanho da Sort Area n ao e suficiente, a operac
ao
de ordenac
ao e realizada em disco, em uma tablespace chamada TEMP.
Duas outras estruturas de mem oria tambem tem muita importancia na ar-
quitetura Oracle. A primeira delas e o Java Pool, que define a quantidade de
mem oria que pode ser alocada pela JVM (Java Virtual Machine). A segunda
dela e o Large Pool, que e utilizada para operacoes de backup, recuperac
ao,
entre outras. Em alguns casos, pode ser utilizada para operac
oes de ordenac
ao.
65.1.2 Processos server

Os processos server s ao recebem as requisic
oes dos processos user, realizam o
parse das instruc
oes SQL, verificam as permiss oes de acesso do usu
ario, traz os
dados do disco para o DBBC, caso necess ario, e retorna os dados para o usu
ario.
Um processo server pode ser dedicado para um processo user (dedicated server
process) ou compartilhado entre m ultipos processos user (shared server process).
Os processos server compartilhados so s
ao possveis em sistemas multi-threaded.
65.1.3 Processos user

As func
oes desempenhadas pelos processos user sao se conectar com os processos
server, enviar instruc
oes SQL e receber os resultados. Caso o servidor suporte
processos server compartilhados, diversos processos server podem ser atendidos
por um mesmo processo server.
65.1.4 Processos em Background

Ao contrario dos processos server, os processo em background n ao realizam
nenhuma comunicac ao com os processos user. Os processos em backgound s ao
respons
aveis pelas tarefas de apoio para garantir o funcionamento do sistema
de gerenciamento de banco de dados como um todo. Um sistema Oracle tem
in
umeros processos em background, porem apenas 4 deles s ao obrigat
orios que
s
ao:
Process Monitor (PMON): Realiza a recuperac ao quando algum processo

falha, alem de liberar o cache, locks e demais recursos que o processo
estava utilizando;
System Monitor (SMON): Realiza o processo de recuperac ao da inst

ancia
durante o processo de inicializac
ao, limpa segmentos tempor arios que n
ao
est
ao mais em uso, recupera transac oes terminadas de forma anormal e
realiza desfragmentac
ao nos arquivos de dados para facilitar a alocac
ao;
Database Writer (DBWR): A func ao principal do DBWR e escreve os

blocos de dados modificados (dirty) do DBBC para o disco. Isso e feito
nas seguintes situac
oes: (i) quando a lista de blocos modificados atinge um
tamanho configurado; (ii) quando o processo percorre um quantidade con-
figurada de blocos e nao encontra nenhum bloco livre; (iii) quando ocorre
499
um timeout; (iv) quando ocorre um checkpoint ou (v) quando o DBWR re-

cebe um sinal do processo LGWR. Dessa forma, o processo DBWR alem
de garantir que as alerac
oes feitas em buffer ser
ao persistidas, tambem
gerencia o espaco em buffer para melhorar o desempenho do banco;
Log Writer (LGWR): E o respons avel por copiar as informac

oes do redo log
buffer para o o redo log file (arquivo de log com a mesma estrutura do redo
log buffer). O LGWR tambem e respos avel por atualizar os headers dos
arquivos de dados quando ocorre um checkpoint. O LGWR e disparado
nas seguintes situac
oes: (i) quando ocorre um commit; (ii) quando ocorre
um checkpoint; (iii) quando ocorre um timeout ou (iv) quando o redo log
buffer atinge um terco de sua capacidade.
Alem desses quatro, o Oracle possui uma serie de outros processos em back-
ground que sao de instalac
ao e uso opcionais. Os mais importantes s ao os
seguintes:
CKPT: Atualiza os headers dos arquivos de dados quando ocorre um

checkpoint. A utilizac
ao desse processo pode ajudar a melhorar o desem-
penho do sistema permitindo que o processo LGWR se concentre apenas
na c
opia do redo log buffer para o disco;
RECO: Respons avel pela recuperac

ao de falhas envolvendo transac
oes dis-
tribudas. Esse processo e necessario quando o Oracle est a rodando de
forma distribuda;
ARCH: E o respons
avel por copiar o redo log file (que e um buffer circular)
para um dispositivos de armazenamento offline para que os logs n ao sejam
perdidos;
o processo respons
Pnnn: E avel pela execuc
ao de consultas paralelas;
SNPn: Controla a replicac

ao de objetos dos banco de dados em outro site.
Essas c
opias s
ao cahamadas snapshots. Esse processo pode ser escalonado
para executar periodicamente;
LCKn: Realiza o controle de locks entre m

ultiplas inst
ancias;
Dnnn: Esse processo funciona como um dispatcher quando o sistema est a

utilizando processos server compartilhados. E necess
ario um dispatcher
para cada protocolo de comunicac
ao utilizado.
65.1.5 Arquivos
Em conjunto, O SGA e os processos em background formam uma int ancia Or-
acle. O banco de dados propriamente dito e formado por tres tipos de arquivos
que sao:
Datafiles: Armazenam as tabelas e ndices do banco;
Redo Log Files: Armazenam os logs do sistema. Esse arquivo consiste de

um buffer circular assim como o redo log buffer. O processo LGWR e o
respons
avel por copiar os logs em memoria para este arquivo;
500
Control Files: Este e um arquivo binario que descreve a estrutura e o

status do banco de dados. Contem a identificac
ao dos arquivos de log e de
dados, o nome do banco e informacoes de sincronismo entre os arquivos
que o compoe.
Embora na arquitetura do Oracle o banco de dados seja composto somente

por esses tres arquivos, uma serie de outros arquivos s
ao importantes para colo-
car uma int ancia no ar. Exemplos desses arquivos s ao:
Parameter File: Arquivo texto que contem todos os par

ametros necess
arios
para colocar uma inst
ancia do Oracle no ar, por exemplo, quantidade de
memoria alocada para o SGA, nome e localizac
ao de arquivos de controle,
tamanho de buffers e de blocos etc;
Alert File: Arquivo de log onde s ao registrados os erros ocorridos (pro-
cesso, blocos corrompidos, deadlock etc.), tarefas administrativas alem dos
valores de parametros de incializac
ao no momento que a inst ancia e posta
no ar;
Trace File: Arquivo de log onde s
ao armazenadas informacoes delatalhadas
sobre os problemas ocorridos. A utilizac
ao desse arquivo e opcional;
65.2 Arquitetura Oracle de Armazenamento de

Dados
Um banco de dados e composto por uma ou mais tablespaces. Uma tablespace
contem um ou mais arquivos no nvel de sistema operacional. Cada tablespace
pode ter um ou mais segmentos. Um segmento e adicionado na tablespace
quando uma tabela ou um ndice e criado, ou seja, um segmento e associado a
cada objeto de banco de dados. E possvel que um objeto seja atribudo a mais
de um segmento, mas, para isso, o usu ario devera particionar explicitamente o
objeto. V arias tabelas ou ndices podem ser includos em um mesmo segmento
atraves da criac
ao de um objeto conhecido como cluster.
A medida que um objeto de banco de dados necessita de mais espaco, e
necessario que o segmento aloque mais dados. O banco de dados procura, nos
arquivos do tablespace, areas contguas de tamanho pre-determinado para o
armazenamento de novos dados. Essa area contgua e conhecida como extensao
(extent), que por sua vez e formada por diversos blocos de banco de dados. Cada
bloco de banco de dados possui um tamanho fixo determinado nos par ametros
de configuracao, esse tamanho fixo deve ser multiplo do tamanho de um bloco do

nvel do sistema operacional. O tamanho extent tambem pode ser configurado
pelo usu ario ou determinado automaticamente pelo Oracle.
65.3 Tratamento de Transa

coes no Oracle
65.3.1 Gerenciamento do Redo Log
O Redo Log e a estrutura mais crucial para as operac
oes de recuperac
ao. Cada
inst
ancia possui um Redo Log para protege-la em caso de falha. Como expli-
cado anteriormente, o processo LGWR e respons avel por copiar para o disco o
501
conteudo do redo log buffer em determinadas situac oes, como em um COMMIT

por exemplo. Essa escrita e feita de maneira circular. Quando n ao houver mais
espaco para escreve no arquivo de Redo Log atual, o LGWR comeca a escrever
no proximo arquivo. Caso esteja no u ltimo arquivo do buffer, o LGWR voltar a
a escrever no primeiro arquivo. E possvel configurar o banco de dados para
arquivar as informacoes escritas nos arquivos de redo. Com essa configuracao,
o processo ARCH ser a ativado.
Um log switch e o ponto quando o banco de dados para de escrever em um
arquivo de Redo Log e comeca a escrever em outro. Um log switch tambem
pode ser forcado pelo DBA e pode ser configurado para ocorrer em intervalos
regulares. O Oracle atribui, para cada arquivo de Redo Log, um log sequence
number toda vez que um log switch ocorre. A ordem atribuda pelos log sequence
numbers e utilizada na recuperacao do banco de dados em caso de falha.
65.3.2 Checkpoints
A um tempo especfico, todos os dados do database buffer cache modificados s
ao
escritos em disco pelo processo DBWR; este evento e chamado de checkpoint. O
processo CKPT e respons avel para informar ao processo DBWR o momento de
gravar os dados em disco. O DBWR tambem atualiza os arquivos de controle
do banco de dados para indicar o mais recente checkpoint. O processo CKPT
e opcional; se ele n
ao estiver presente, o LGWR assume sua responsabilidade.
No momento do checkpoint a falta de sincronismo entre o DBBC e os arquivos
de redo e eliminada. Os eventos em que um checkpoint ocorre s ao:
A cada log switch.
Ap
os ocorrido um certo tempo desde o u
ltimo checkpoint (LOG CHECK-
POINT TIMEOUT).
Quando a inst
ancia sofre um shutdown, a menos que ela seja abortada.
Quando forcada pelo DBA. (ALTER SYSTEM CHECKPOINT)
Quando uma tablespace e colocada offline com pelo menos um arquivo
(datafile) online.
65.3.3 Segmentos de rollback

Um segmento de rollback e uma porc ao de um banco de dados que registra as
ac
oes das transac
oes dos usuarios nos dados para que possam ser desfeitas sob
certas circunstancias.
Um segmento de rollback e usado para permitir a consistencia da leitura, re-
cuperar um comando quando ocorre o dead-lock, recuperar uma transac ao ate
uma certa marca identificada por um SAVEPOINT (marcador para instruc oes
nao confirmadas), recuperar uma transac ao terminada por uma falha de pro-
cesso de um usu ario e desfazer todas as transacoes pendentes durante a recu-
perac
ao de uma inst ancia.
Todas as operac
oes de atualizac
ao de dados em um banco de dados envolvem
os segmentos de rollback para permitir a consistencia da leitura, a recuperacao
das informacoes e permitir que uma transac ao ou um comando sejam descon-
siderados ou desfeitos.
502
65.3.4 Consist
encia de leitura
O Database Buffer Cache e organizado em duas listas: a dirty list e a least
recently used list (LRU). A dirty list e uma lista que contem os blocos alterados
que ainda n ao foram escritos em disco. A LRU e uma lista que contem blocos
do ORACLE que foram alterados pelos comandos dos usu arios mas ainda nao
foram gravados em disco. Contem ainda blocos livres e blocos em uso. Assim,
quando um processo servidor precisa ler um bloco de dados do disco para a
mem oria, ele:
1. Pesquisa nas listas LRU e dirty list pelo bloco de dados desejado.
2. Caso esse bloco de dados n
ao seja localizado, o processo servidor pesquisa
a lista LRU em busca de um bloco livre.
3. Em seguida, o processo servidor move os blocos alterados encontrados na
lista LRU para a dirty list, ou seja, movimenta-os para a lista de blocos
alterados ainda n ao gravados nos arquivos de dados, de acordo com a
localizac
ao de cada um deles, durante o processo de pesquisa de um bloco
livre.
4. Finalmente, o processo servidor efetua uma c
opia do bloco de dados do
disco para um bloco livre.
5. Esse procedimento termina quando o processo servidor localiza um bloco
livre ou se um n
umero especfico de blocos forem pesquisados sem encon-
trar um unico bloco livre.
Se nenhum bloco foi encontrado, o ORACLE deve gravar os blocos alterados
da dirty list para os arquivos em disco, para liberar espaco em mem
oria para
os novos blocos de dados que precisam ser manipulados pelos comandos dos
usu
arios.
65.4 Configurac
ao do Servidor
A criac
ao de um banco de dados pode ser realizada atraves de uma ferramenta
gr
afica conhecida como Database Configuration Assistant. Com essa ferramenta
tambem e possvel configurar opc
oes de um banco de dados existente, deletar
um banco de dados e gerenciar gabaritos de banco de dados. As etapas s ao as
seguintes:
Etapa 1 Em uma tela, ser a possvel escolher se e desejado criar um banco de

dados, configurar ou deletar um j a existente ou gerenciar gabaritos. Nesse
caso, ser
a criado um banco de dados.
Etapa 2 Ser
a possvel escolher sobre qual gabarito se deseja basear o banco
de dados a ser criado. H a como escolher gabaritos otimizados para data
warehouse, processamento de transacoes ou para uso geral.
Etapa 3 Ser a atribudo o Nome do Banco de Dados Global, pelo qual o banco
de dados e identificado exclusivamente. Alem disso, ser
a necess
ario iden-
tificar o nome de uma inst ancia para o banco de dados que est a sendo
criado.
503
Etapa 4 Sera necess

ario selecionar se deseja que o banco esteja em Modo Servi-
dor Dedicado ou em Modo de Servidor Compartilhado. No primeiro caso,
cada conex ao cliente e atendida um processo servidor para atender so-
mente a esse cliente. No segundo caso, ser a possvel para um processo
servidor atender mais de uma conex ao cliente.
Etapa 5 Nessa etapa, os par ametros de inicializac
ao relacionados `
a mem
oria, `
a
localizac
ao dos arquivos de configurac
ao e ao conjunto de caracteres ser
ao
configurados.
Etapa 6 Sera configurado o armazenamento do banco de dados, atraves de uma

tela ser
a possvel configurar arquivos de controle, tablespaces, arquivos de
dados, segmentos de rollback e grupos de redo logs.
Etapa 7 Na u
ltima etapa, haver a a opc
ao de criar o banco de dados ou, sim-
plesmente, utiliz
a-lo como gabarito.
65.5 Tipos de Usu

arios Oracle
Os tipos de usu
arios (papeis) variam de acordo com o lugar, mas podem ser di-
vididos em administadores de banco de dados, respons aveis pela seguranca, ad-
ministradores de rede, desenvolvedores de aplicac
ao, administradores de aplicac
ao
e usu
arios do banco de dados.
65.5.1 Administradores de banco de dados

Cada banco de dados requer no mnimo um DBA (database administrator ). As
suas responsabilidades incluem:
Instalac
ao e atualizac
ao dos servidores de banco de dados Oracle e das
ferramentas de aplicacao.
Alocac
ao de espaco para o sistema e planejamento de futuras necessidades.
Criac
ao de estruturas de armazenamento prim
arias do banco de dados
(tablespaces).
Criac
ao e alterac
ao de objetos prim
arios: tabelas, vis
oes etc. ap
os os
desenvolvedores terem projetado a aplicac
ao.
Administrac
ao de usu
arios, controle de acesso e seguranca do sistema.
Garantia do atendimento aos termos da licenca Oracle e contato direto

com o suporte tecnico da Oracle.
Monitorac
ao e otimizacao do desempenho do banco de dados.
Planejamento e execuc
ao de backup e de restaurac
ao das informac
oes do
banco de dados.
504
65.5.2 Outros p
apeis
Responsavel pela seguran ca E um papel que existe somente em alguns ca-
sos. Pode assumir as responsabilidades de administrac ao de usu
arios,
controle de acesso e seguranca do sistema.
Administradores de redes Respons aveis em administar os produtos de rede
da Oracle como os servicos de rede da Oracle.
Desenvolvedores de aplica cao Entre as atividades desse papel, pode-se destacar:

o projeto e desenvolvimento da aplicac
ao e o projeto da estrutura do banco
de dados bem como os requisitos necess arios em relac
ao ao espaco de ar-
mazenamento necess ario.
Administradores de aplica c
ao Cada aplicac ao deve ter um administrador
de aplicac
ao, que ser
a respons
avel por ela.
Usu
arios do banco de dados Respons aveis pela criac
ao, modificac
ao e delec
ao
de dados quando permitidos, alem da obtenc
ao de realatorios atraves do
dados.
505
Captulo 66
Administra
c
ao de Bancos
de Dados SQL Server
66.1 Arquitetura de um Servidor SQL Server

Um banco de dados no SQL Server 2005 se refere a um grupamento fsico de
um conjunto de objetos de esquema de um banco de dados em um ou mais
arquivos fsicos. Os bancos de dados podem ser classificados como bancos de
dados de sistemas e bancos de dados dos usu arios. Os banco de dados de sistema
armazenam dados do sistema e tambem controlam o armazenamento tempor ario
requerido para os dados de aplicac ao.
Cada instancia do SQL Server pode suportar v arios bancos de dados. Alem
disso, pode haver v arias inst
ancias em um mesmo computador. Cada banco de
dados pode suportar grupos de arquivos (filegroups), que proveem a funcionali-
dade de distribuir os dados fisicamente. Um banco de dados pode possuir v arios
filegroups, mas o contrario nao e possvel. Ap
os a criac
ao do banco de dados, os
filegroups do banco de dados podem ser adicionados.
Por padrao, o SQL Server instala os seguintes bancos de dados:
Modelo um template para os outros banco de dados.
Tempdb para armazenamento tempor

ario, como as operac
oes de or-
denac
ao.
Msdb suporta o agente do SQL Server, com tarefas agendadas, alertas

e informac
oes sobre replicac
ao.
Adventure Works e AdventureWorksDW opcionais, s

ao banco de dados
de exemplos.
66.1.1 Cat
alogos de sistema
Cada banco de dados Oracle executa em cat alogo de sistema centralizado, ou
dicion
ario de dados, que reside na tablespace SYSTEM. No caso do SQL Server
2005, cada banco de dados mantem seu cat alogo de sistema, que possui in-
formac
oes relacionadas, por exemplo, ` a: objetos do banco de dados (tabelas,
506
ndices, procedimentos, vis oes, triggers etc.), restric

oes, usu
arios, permiss
oes e
Tipos de dados definidos pelo usu ario.
As informac oes relativas ao nvel do sistema s ao armazenadas no Master
Database (Msdb). Essas informac oes incluem, por exemplo: contas de login,
valores de configurac
ao, mensagens do sistema, nomes dos bancos de dados e a
localizac
ao dos arquivos primarios de cada banco de dados.
Atenc ao, no SQL Server 2005, os objetos do sistema n ao s
ao armazenados
no Msdb, mas em um banco de dados oculto conhecido como resource database.
66.1.2 Processos em background

O SQL Server possui diversos processos em background. Um exemplo s ao os
checkpoints. O SQL Server periodicamente gera checkpoints automaticamente
em cada banco de dados.
Outro processo em background importante e o Lazywriter que e u nico para
cada inst
ancia. O lazywriter adormece um intervalo de tempo e ent ao acorda
para checar o espaco livre na lista do buffer. Caso esse espaco livre esteja abaixo
de um certo ponto (dependente do tamanho do cache), o processo lazywriter
procura paginas nao utilizadas no buffer cache e escreve as p aginas com write
dirty que n
ao foram recentemente referenciadas em disco.
Um processo conhecido como ResourceMonitor e utilizado para controlar o
restante do caches, pois o lazywriter s o controla as p
aginas de dados.
66.2 Arquitetura SQL Server de Armazenamento

de Dados
O SQL Server utiliza a unidade b asica de IO fixo (p agina) em 8KB. Para or-
ganizar melhor os dados, essas p aginas s
ao agrupadas em uma quantidade de
oito contguas entre si formando as chamadas extens oes (extents). O espaco e
gerenciado em termos de extens oes. Cada p agina pertence a um objeto de um
tipo (dado, ndice etc), mas uma extens ao pode pertencer a v arios objetos.
Uma extens ao em que as oito p aginas pertencem ao mesmo objeto e consid-
erada uma extens ao uniforme, caso contr ario, trata-se de uma extens ao mista.
O SQL Server utiliza os filegroups para controlar a alocacao das tabelas e dos
ndices. Os dados contidos em filegroup s ao proporcionalmente distribudos entre
os arquivos do filegroup. Se os filegroups n ao estiverem definidos, os objetos do
banco de dados ser ao armazenados em um filegroup padr ao que e implicitamente
definido durante a criacao do banco de dados.
Os segmentos utilizados no Oracle n ao sao necess

arios no SQL Server. Em
vez disso, o SQL Server distribui os dados atraves de RAID suportado em hard-
ware ou software (soluc ao presente no Windows ou em outro software).
66.3 Tratamento de Transa

coes no SQL Server
O Oracle executa recuperacao automatica toda vez que e iniciado. Ele checa
se os arquivos do tablespace est
ao sincronizados com o conte udo dos arquivo
de redo log. Caso n
ao estejam, o Oracle aplica o conte
udo do arquivo de redo
log no caso das transac
oes comitadas e remove as transac oes nao comitadas
507
Figura 66.1: Comparac

ao gr
afica entre os esquemas de armazenamento do Or-
acle e do SQL Server
com o auxlio dos segmentos de rollback. Se o Oracle n ao possui a informacao

requerida, ele consulta os arquivos redo log arquivados pelo processo ARCH.
O SQL Server tambem executa recuperac ao automatica atraves da checagem
de cada banco de dados. Primeiramentem o SQL Server checa o Msdb e ent ao
inicia threads para recuperacao autpmatica em todos os bancos de dados. Para
cada banco de dados, o mecanismo de recuperac ao automatica checa o transac-
tion log. O tratamento e o mesmo do Oracle para transac oes comitadas e n ao
comitadas.
Cada transaction log combina as funcionalidades de um segmento de rollback
e de um redo log do Oracle. Cada banco de dados possui seu transaction log que
armazena todas as alterac oes do banco de dados e e compartilhado com todos
os usuarios do banco de dados.
Internamente, os transaction logs s ao quebrados em pedacoes menores con-
hecidos como virtual log files (VLFs). Quando um VLF n ao possui mais registros
de logs para transac
oes ativas, entao o VLF pode ser dividido. O crescimento
dos VLFs pode ser configurado para se ocorrer de forma autom atica e assim
como no Oracle s ao preenchidos em forma circular.
508
Parte XIV
ITIL
509
Captulo 67
Suporte a Servi
cos
67.1 Service Desk

67.1.1 Objetivos
Atuar como ponto u
nico de contato entre o usu
ario e o Gerenciamento de
Servicos de TI;
Tratar incidentes e requisic

ao de servicos;
Ser a principal interface operacional entre a TI e seus usu

arios;
Promover a retenc
ao e a satisfac
ao do usu
ario;
Aumentar o percentual de resoluc

ao de chamados no primeiro ponto de
contato.
67.1.2 Responsabilidades
Receber, registrar, priorizar e rastrear chamadas de servico;
Prover uma avaliac

ao inicial de todos os incidentes reportados pelos usu
arios;
Resolver incidentes com base em soluc oes j

a conhecidas ou identificar
soluc
oes de contorno para o reestabelecimento dos servicos;
Escalar chamado para suporte em nvel adequado;

Monitorar e acompanhar as chamadas com base nos acordos de nvel de

servicos;
Manter usu
arios informados;
Produzir informac
oes gerenciais;
Fechar incidentes e confirmar com o cliente / usu

ario.
510
67.1.3 V
arios Tipos de Central
Central de Atendimento Call Center. Apenas registra e encaminha para
outras
areas da organizac
ao.
Central de Suporte Call Center. Gerencia, coordena e resolve incidentes o
mais r
apido possvel. Utiliza o gerenciamento de comunicac
ao e ferramen-
tas de suporte ao conhecimento como tecnologia de apoio. Normalmente,
trata apenas incidentes.
Central de Servi cos Service Desk. N ao trata somente incidentes, problemas

e d
uvidas, mas tambem fornece uma interface para outras atividades como
requisic
oes de mudanca do usu
ario, contratos de manutenc
ao, licencas de
software, gerenciamento de nvel de servico etc.
67.2 Gerenciamento de Incidentes

67.2.1 Objetivos
Um incidente e qualquer evento que n ao faz parte do servico combinado. A
indisponibilidade de um servico ou a diminuic
ao de sua qualidade tambem pode
ser considerado um incidente. Exemplos de incidente em um ambiente de TI
s
ao, por exemplo, uma aplicac ao com erro, um usu ario que esqueceu a senha
ou a indisponibilidade de um servidor, mesmo que os usu arios n
ao tenham sido
impactados.
O objetivo do processo de gerenciamento de incidentes e restaurar a operac

ao
normal de um servico minimizando o impacto no neg ocio. E importante enfati-
zar que o gerenciamento de incidentes trata o efeito e n
ao a causa. A porta de
entrada para o tratamento de incidentes e o Service Desk.
Os incidentes podem ser detectados pelos usu arios ou por algum processo de
monitoracao, alem de poderem surgir de d uvidas, manifestac
oes ou requisic
oes
de servico. As sadas do processo de gerenciamento de incidentes podem ser
o reestabelecimento do servico, o esclarecimento da d uvida, a atendimento da
requisic
ao de servico, a identificac
ao de uma necessidade de mudanca, ou ainda,
o registro de um problema.
67.2.2 Atividades do Processo

Identificac
ao e Registro do Incidente: Registro dos incidentes seja qual
for a fonte de abertura, reportando sintomas, diagn
ostico b
asico, itens de
configuracao envolvidos, perfil do usu
ario etc;
Analise e Classificac
ao: Especifica melhor os sintomas do incidente para
determinar a solucao;
Priorizac
ao: Combina os fatores impacto e urgencia para definir a prior-
idade do incidente em relac
ao ao demais (Matriz Impacto x Urgencia).
Tambem e levado em considerac
ao o acordo de nvel de servico (ANS ou
SLA);
511
Suporte Inicial: Caso exista uma soluc ao previamente identificada na

base de soluc
oes (BDS), o analista devera aplic
a-la. Caso contr
ario, uma
soluc
ao dever
a ser implementada. Dependendo da complexidade, o reg-
istro pode ser escalado para nveis mais especializados;
Investigac
ao e Diagn
ostico: Caso n
ao seja encontrada uma soluc
ao defini-
tiva, uma soluc
ao de contorno pode ser especificada. Nesse caso, deve ser
aberto um registro de problema;
Estrategia de Recuperac
ao: Ap
os definida a soluc
ao, esta deve ser imple-
mentada. Em algumas situac oes pode ser necessario abrir uma requisic
ao
de mudanca (RDM);
Fechamento: Garantir que o incidente foi devidamente tratado. Em alguns
casos, isso significa checar se a RDM foi implementada. A validac
ao do
cliente tambem e importante para o fechamento;
Informac
ao e Comunicac ao: O Service Desk deve manter o hist orico com-
pleto do registro e garantir que o usu
ario tenha acesso `
as informac
oes seja
qual for o status de atendimento do incidente ou requisicao.
67.2.3 Pap
Gestor de Incidentes: Avaliar e garantir a eficiencia e qualidade do servico,
auditar base de incidentes, garantir a avaliac
ao da satisfac
ao dos usu
arios,
produzir relat
orios gerenciais e realizar an
alise crtica do processo;
1o Nvel de atendimento: Receber, categorizar e priorizar as requisic oes
dos usuarios. Realizar investigac
ao inicial e aplicar soluc
oes de contorno
conhecidas. Caso necess ario, encaminhar os incidentes para o nvel ade-
quado de atendimento;
2o Nvel de atendimento: Desenvolver, quando possvel, uma soluc
ao de
contorno ou definitiva. Caso necess
ario, encaminhar incidente para o ter-
ceiro nvel;
3o Nvel de atendimento: Nvel mais alto de atendimento de incidentes.
Deve obrigatoriamente desenvolver uma solucao de contorno;
Equipes Especializadas: Atende ` as solicitac
oes de servico, esclarecimento
de d
uvidas e manifestacoes dos usuarios encaminhadas pelo primeiro nvel.
Deve executar os servicos segundo procedimentos pre-definidos.
Os tres nveis de atendimento e as equipes especializadas devem, quando

necess
ario, emitir uma RDM, verificar as divergencias encontradas na banco
de dados de soluc oes e na banco de dados de gerenciamento de configurac
ao
(BDGC).
67.3 Gerenciamento de Problemas

67.3.1 Objetivos
Eliminar erros na infra-estrutura de TI, identificando e removendo a causa raiz,
evitando assim, a recorrencia de incidentes e problemas no ambiente operacional.
512
67.3.2 Defini
coes Importantes
SC Soluc
oes de Contorno. Eliminam o sintoma ou reduzem o impacto de um
erro, sem eliminar as suas causas.
Problemas e Erros Conhecidos Um problema e a causa subjacente descon-
hecida de um ou mais Incidentes. Um Problema passa a Erro Conhecido
quando a causa-raiz for conhecida e for identificada uma soluc
ao de con-
torno ou uma alternativa definitiva.
BDP Base de Dados de Problemas. Base de Dados que contem todos os reg-
istros de problemas.
BDS Base de Dados de Problemas. Base de Dados que contem informac oes
referente aos Erros Conhecidos, suas respectivas Soluc
oes de Contorno e
demais soluc
oes definitivas.

Controle de Problemas
Identificac
ao e registro do Problema
Classificaca
o do Problema
Investigacao e diagnostico do Problema
Controle de Erros
Identificac
ao e registro do Erro
Avaliac
ao do Erro
Registro da resolucao do Erro
Fechamento do Erro
Monitoramento da resoluc ao do Erro
Apoio no tratamento de Incidentes Graves
Prevenc
ao pro ativa de Problemas
Analise de tendencias
Direcionamento das ac oes de suporte
Fornecimento de informac oes para a organizac
ao
Obtenc
ao de Informac
oes gerenciais a partir dos dados de Problemas
Completar as revis
oes dos principais Problemas
67.3.4 Pap
Gestor de Problemas Analisar e garantir a eficiencia do processo atraves da
auditoria e da revisao. Respons
avel tambem pela produc
ao de relat orios
gerenciais, alocac
ao dos Responsaveis Tecnicos e pela identificac
ao de
tendencias.
Responsavel T ecnico pelo Problema Identificar, registrar, categorizar e pri-
orizar. Investigar e diagnosticar a causa do Problema.
513
67.4 Gerenciamento de Configura

c
ao
67.4.1 Objetivos
O objetivo do processo de gerenciamento de configurac ao e prover informacoes
confi
aveis sobre as configurac
oes e documentac oes relativas a infra-estrutura de
TI de forma suportar os demais processos de gerenciamento de servicos. O pro-
cesso de gerenciamento de configuracao e o principal respons avel pela construc
ao
e manutencao do banco de dados de gerenciamento de configurac ao (BDGC),
considerado o coracao do modelo de gerenciamento de servicos do ITIL. Essa
base de dados deve conter informac oes sobre todos os itens de configurac ao
(ICs) do ambiente e os seus respectivos relacionamentos.
Um item de configurac ao e um componente que faz parte ou est a associado

a infra-estrutura, fazendo-se necessario para a prestac
ao de um servico. (Exem-
plo: servidor, software, procedimento etc.) Cada IC e composto por atributos
como identificador u nico, nome, tipo etc.
O BDGC e fundamental para o gerenciamento de nvel de servico, uma vez

que a partir dele e possvel identificar todos os itens de configurac
ao que fazem
parte de um servico especfico. Alem disso, o BDGC permite identificar se inci-
dentes, problemas e mudancas em um determinado IC ir ao impactar nos demais.
O BDGC s o pode ser alterado mediante uma requisic ao de mudanca (RDM).
Uma baseline e o estado do BDGC em determinado instante do tempo. Ela

serve como referencia para auditorias e tambem para estipular uma base de
retorno ap
os mudancas mal sucedidas, por exemplo.
67.4.2 Atividades
Planejamento: Identificac
ao do escopo, granularidade, objetivos, polticas
e procedimentos para o processo de gerenciamento de configurac ao;
Identificac
ao e Denominacao: Selec
ao e identificac
ao dos ICs, definindo
seus atributos, inter-relacionamento e identificacao;
Controle: Garante a autorizac ao e identificac

ao dos ICs nos processos
de inclus
ao, alterac
ao e descarte, alem de n ao permitir alterac
oes sem
documentacao de controle sejam feitas no BDGC;
Registro e Hist
orico da Situac
ao: Realiza a atualizac
ao no BDGC seguindo
procedimentos pre-definidos, de forma n ao perder o controle do ciclo de
vida dos ICs e vinculacao `
as RDMs;
Descric
ao da Situac
ao: Gerac
ao de relat
orios sobre status e ciclo de vida
dos ICs, permitindo a localizac
ao de mudancas;
Verificac
ao e Auditoria: Verificar a consistencia entre a situac
ao real e o
BDGC e demais bibliotecas controladas.
514
67.4.3 Pap
Gestor de Configurac ao: Implementar polticas de gerenciamento de con-
figurac
ao e assegurar sua disseminac
ao e utilizac
ao por toda organizac
ao.
Elaborar relat orios com indicadores do processo e an alises de impacto.
Deve ser membro do Grupo de Aconselhamento de Mudancas (GAMA);
Administrador de Configurac ao: Administrar o BDGC, assegurando sua
atualizac
ao a cada mudanca. Deve ainda auditar o BDGC, garantindo sua
consistencia com o invent
ario fsico.
67.5 Gerenciamento de Mudan

cas
67.5.1 Objetivos
Garantir a aplicac
ao de metodos e procedimentos padronizados a fim de lidar
eficientemente com todas as mudancas no ambiente operacional, minimizando
os impactos na qualidade dos servicos e prevenindo a ocorrencia de incidente
provenientes das mudancas realizadas.
Controle das alterac
oes em todos os Ices;
Levantamento e registro das mudancas;
Avaliac
ao de impacto, custo, benefcio e risco associado `
as mudancas;
Justificativa da mudanca perante o neg
ocio e obtenc
ao de aprovac
ao para
as mudancas;
Gerencia e coordenac
ao da implementac
ao de mudancas;
Monitoramento e informes sobre a implementac
ao;
Revis
ao e fechamento das RDM (requisic
oes de mudancas).
67.5.3 Defini
coes Importantes
Mudan
ca Padrao E a mudanca bem conhecida, rotineira e que comprovada-
mente n
ao causa alto impacto.
Mudan
ca Normal Planejada E a mudanca planejada e programada respei-
tando o cronograma de atividades e o acordo com os clientes.

Mudanca Emergencial E a mudanca executada para recuperar servicos a fim
de evitar danos `
a imagem do negocio, perdas financeiras e conseq
uencias
legais.
RDM Requisicao de mudanca. RFC - Requests for Change. Documento que
formaliza a necessidade da mudanca e define detalhes de como ela acon-
tecera. Inclui identificac
ao numerica, descric
ao e identificac
ao dos ICs,
motivo da mudanca, efeito da n ao implementac ao da mudanca, nome do
solicitante da mudanca, data proposta para a mudanca, grau de priori-
dade, assinatura, plano de implementac ao, plano de retorno etc.
515
Gestor de Mudan ca Change Manager E responsavel pelas mudancas que

ocorrer
ao no ambiente de TI. Ele n
ao detem o poder de autorizar qualquer
mudanca, isso cabe ao GAM.
GAM Grupo de Aconselhamento de Mudancas. CAB - Change Advisory Board.

Tem a responsabilidade de planejar, avaliar e aprovar mudancas de medio
e alto impacto. O grupo e multidisciplinar, pode ter representantes do
Service Desk, desenvolvedores,
area de relacionamento com o cliente etc.
GAM/CE Grupo de Aconselhamento de Mudancas/Comite Emergencial. CAB/EC

- Change Advisory Board/Emergency Committee. Tem a mesma func ao
do GAM, porem para mudanca emergenciais de alto e medio impacto.
Envolve nveis hier
arquicos mais altos da TI.
Agenda de Mudan cas (AM) Contem detalhes de todas as mudancas aprovadas

e suas datas de implementac usada para que todos os grupos afetados
ao. E
por uma mudanca possam se planejar.
Proje
cao de Indisponibilidade PSA - Projected Services Availability. Contem
detalhes das mudancas e sua interferencia nos Acordos de Nvel de Servicos
e na disponibilidade de servicos.
Revis
ao P
os-Implementa c
ao Revis ao da Mudanca realizada ap
os a imple-
mentac
ao. Tem por objetivo avaliar se a mudanca atingiu e se houve
imprevistos ou efeitos colaterais.
Prioriza
cao de Mudan cas A priorizacao das mudancas e realizada de acordo
com o seu impacto e a sua urgencia.
67.6 Gerenciamento de Libera

cao
67.6.1 Objetivo
Gerenciar a liberac
ao de componentes de software, hardware e documentos nas
implementacoes e modificac
oes dos servicos, garantindo liberac
oes compatveis,
licenciadas e apropriadas para o ambiente de produc ao. Opera como interface
entre o Gerenciamento de Mudancas e o Gerenciamento de Configurac oes.

Planejar e administrar um implementac
ao bem sucedida de hardware e
software.
Projetar e implementar procedimentos eficientes para a distribuic

ao e in-
stalac
ao de mudancas.
Garantir a localizac
ao do HW e do SW e assegurar que apenas as vers
oes
corretas sejam instaladas.
Gerenciar as expectativas dos clientes durante o planejamento e imple-

mentac
ao (rollout) de novas liberac
oes.
Acordar o plano de implementac
ao com o Gerenciamento de Mudancas.
516
Testar o Plano de Retorno (fallback).

Implementar as liberac
oes no ambiente operacional, atualizando os ICs
necess
arios.
Garantir que as copias originais de todos os softwares est

ao seguras em
uma Biblioteca de Software Definitiva (BSD) e que o BDCG reflita as
informac
oes do BSD e das liberac
oes realizadas no ambiente.
Garantir a acur
acia do DHD (Dep osito de Hardware Definitivo) e que todo
IC retirado para ser utilizado no ambiente operacional seja reposto.
Garantir que todo o hardware a ser implantado ou alterado esteja prote-

gido e seja localiz
avel, utilizando os servicos de Gerenciamento de Con-
figurac
ao.
67.6.3 Defini
coes Importantes
BSD Biblioteca de Software Definitiva. DSL - Definitive Software Library.
Colec
ao de itens de configurac
ao de software e documentac
ao guardados
em local seguro. Todas versoes liberadas devem estar salvas na BSD.
DHD Deposito de Hardware Definitivo. DHS - Definitive Hardware Store.

Deposito de componentes de reposicao no mesmo nvel dos sistemas cor-
respondentes no ambiente de produc ao. Uma vez encerrada a utilizacao
dos componentes, devem retornar ao DHD, ou adquirir substitutos. As-
sim como a BSD, o DHD e um reposit orio e quem contem as informac
oes
sobre os atributos dos itens e o BDGC.
Liberac
ao completa Todos os componentes s
ao construdos, testados, dis-
tribudos em conjunto.
Libera
cao Delta S
ao includos os ICs alterados desde a u
ltima alterac
ao.
Libera
cao Pacote Liberac oes completas, deltas ou as duas s
ao agrupadas em
pacote para liberac
ao.
67.6.4 Pap
Gestor de Libera
c
oes Garantir que o processo seja seguido. Efetua auditoria
no BSD e no DHD. Autoriza a liberac
ao para o ambiente de produc
ao.
Responsavel T ecnico pela Libera cao Desenvolver o projeto, construcao e

configurac
ao da liberacao. Realizar testes. Realizar a instalac
ao e dis-
tribuic
ao de SW e HD. Armazenar o software na BSD.
517
Captulo 68
Entrega de Servi
cos
68.1 Gerenciamento do Nvel de Servi

co
68.1.1 Objetivos
O gerenciamento do nvel de servico visa a melhoria da qualidade dos servicos
de TI atraves de um ciclo contnuo de negociac ao e monitoracao, promovendo
ac
oes para eliminar nveis de servico inaceit
aveis. A essencia do processo em
questao e o Acordo de Nvel de Servico (ANS) (Service Level Agreement - SLA),
que funciona como um contrato entre a TI e os clientes. O ANS deve descr-
ever em detalhes os servicos fornecidos, alem especific
a-los quanto a qualidade,
quantidade, desempenho e disponibilidade. Os principais objetivos do processo
de gerenciamento de nvel de servico s ao:
Melhorar a especificac
ao dos servicos;
Reduzir demandas imprevistas;
Avaliar o custo dos servicos;
Controlar o nvel de servico;
Promover a melhoria da qualidade do servico;

Manter alinhamento com o neg
ocio.
Para alcancar tais objetivos, o processo de gerenciamento de nvel de servico

tem as seguintes responsabilidades:
Catalogo de Servicos: Define, do ponto de vista do cliente, os servicos

fornecidos;
Acordo de Nvel de Servico (ANS): Acordos formais entre a TI e seus
clientes, onde s
ao definidas as metas e as responsabilidades de ambas
as partes. Um ANS deve conter informac oes como descric
ao do servico,
agenda (24x7,5x8), suporte (sobreaviso, prorrogac
ao, tempo de reparo),
procedimentos para mudancas, metas para disponibilidade, confiabilidade,
seguranca, capacidade etc;
518
Requisicoes de Nvel de Servico: Documentos para fornecer vis

ao de-
talhada das necessidades do cliente, usados para ajustar ou criar novos
servicos (Service Level Request - SLR);
Acordo de Nvel Operacional (ANO): Formalizacao de acordos com fornece-
dores internos da organizacao, sobre manutenc
ao de servicos ou compo-
nentes de servicos (Operational Level Agreement - OLA);
Contratos de Apoio: Contratos de apoio com fornecedores externos (Un-
derpinning Contract - UC);
Programa de Aperfeicoamento de Servicos (PAS): Identificar e implemen-
tar ac
oes necess
arias para superar dificuldades e restabelecer a qualidade
do servico;
Gerenciamento do Relacionamento com o Cliente: Administrar o rela-
cionamento com os clientes visando a sustentac
ao dos acordos de nvel de
servico e nivelamento das expectativas;
Monitorac
ao, Revis
ao e Informac
ao: Garantir o andamento do processo e
o cumprimento das metas estabelecidas nos acordos.
68.2 Gerenciamento Financeiro

68.2.1 Objetivos
Administrar os recursos monet arios, garantindo o planejamento e execucao dos
objetivos de negocio. Identificar, calcular e gerenciar os custos de entrega de
servico. Fornecer dados de previsao orcament
aria para a administrac
ao.
Otimizar os recursos financeiros.
Apoiar decis
oes de investimentos.
Atribuir valores dos servicos e rateio dos custos por cliente.
Influenciar o comportamento do cliente.
Melhorar o controle dos contratos Externos/Fornecedores.

Dentro de uma organizac
ao de TI existem tres disciplinas principais para o
Gerenciamento Financeiro:
Or
camento
Processo de previs
ao e controle dos gastos em dinheiro. As suas responsabili-
dades compreendem:
Previsao do orcamento necess
ario para a realizac
ao de servicos de TI no
perodo acordado.
519
Garantia que a despesa real possa ser comparada com a despesa prevista
a qualquer momento do perodo.
Reduc
ao do risco de gastar alem do orcado.
Garantir a disponibilizac
ao de verba para cobrir despesas extras.
Garantia que as receitas estar

ao disponveis para cobrir despesas previstas.
Contabilidade
Conjunto de processos que permite a organizac ao de TI prestar contas de como
o dinheiro foi gasto em um determinado perodo de tempo, sendo capaz de iden-
tificar custo por clientes, servicos ou atividades. Deve ter focos nos custos para
justificar investimentos e lucro zero para que a organizac ao possa contabilizar
as despesas de TI. As responsabilidades da disciplina compreendem:
Contabilizac
ao do dinheiro gasto para provis
ao dos servicos de TI.
Calculo do custo de provimento dos servicos de TI para clientes externos

e internos.
An
alise Custo x Benefcio ou o retorno do investimento (ROI).
Identificac
ao do custo de mudancas.
Cobran
ca
Conjunto de processos necess arios para faturar um Cliente (Oops...) pelos
servicos prestados, otimizando a relac
ao custo/benefcio do ponto de vista do
negocio. As responsabilidades da disciplina compreendem:
Recuperac
ao dos custos dos servicos de TI dos clientes dos servicos.
Rateio dos custo entre os clientes da TI.
Influencia do comportamento do Cliente.

Precificar os servicos.
68.2.4 Elementos de Custo

Os elementos de custo tpicos s ao: hardware, software, pessoal, acomodac oes,
servico externo e transferencia de custo (cobrados por outros centros de custo

da empresa). Os elementos de custo podem ser classificados em fixos, vari aveis,
diretos, indiretos (que devem ser divididos entre v arios clientes), de capital e
operacional (do dia-a-dia).
520
68.3 Gerenciamento da Capacidade

68.3.1 Objetivos
O gerenciamento de capacidade visa garantir o atendimento das necessidades
futuras do neg
ocio estabelecendo sempre um equilbrio entre demanda e cus-
tos. O principal produto do processo A principal sada desse processo e um
documento chamado Plano de Capacidade. Nele s ao reportadas as previsoes
de carga, hardware e software necess arios, custos e outras recomendacoes. Os
principais modelos para elaborac
ao de um plano de capacidade s ao os seguintes:
Modelagem por Referencia: Modelagem a partir de um modelo v

alido
pre-existente;
An
alise de Tendencias: Projec
oes futuras com base em dados hist
oricos;
Modelagem Analtica: Validac

ao de um modelo matem
atico com a situac
ao
real;
Modelagem por Simulac ao: Utilizac
ao de dados fictcios para dimension-
amento de novas aplicac
oes;
Testes de Laborat
orio: Testes como dados reais em um ambiente real.
O gerenciamento da demanda tem por objetivo influenciar a demanda, dire-

cionando o seu comportamento. Para isso pode ser necess ario realizar cobranca
diferencial de acordo com o hor
ario, limitar tempo de uso em hor arios de pico etc.
A tarefa de monitoracao de desempenho dos recursos e servicos para garantir o
estabelecido no plano de capacidade e chamada gerenciamento de performance.
No contexto de gerenciamento de capacidade outra atividade muito importante
e a modelagem e dimensionamento de aplicac oes (Sizing de Aplicac
oes).
Um elemento importante no processo de gerenciamento de capacidade e o

BDC (Banco de Dados de Capacidade), que armazena dados do neg ocio, dos
servicos, financeiros e de utilizac
ao, sendo, portanto, base para elaborac
ao de
relat
orios relacionados a quest ao de capacidade atuais e futuras.
68.3.2 Atividades
Gerenciamento de Capacidade do Neg ocio: Garante que as capacidades
futuras do neg
ocio sejam consideradas e planejadas em tempo certo. Re-
quer conhecimento do Plano de Negocio da organizac

ao e tecnicas de mod-
elagem;
Gerenciamento da Capacidade do Servico: Monitorac

ao do desempenho
dos servicos de TI;
Gerenciamento da Capacidade dos Recursos: Gerencia os componentes de

infra-estrutura de TI para garantir que desempenho e demanda est
ao de
acordo com o planejado.
521
68.4 Gerenciamento de Disponibilidade

68.4.1 Objetivos
O processo de gerenciamento de disponibilidade visa garantir que os servicos de
TI estarao disponveis sempre que os clientes necessitarem deles, de acordo com
os nveis de disponibilidade acordados. Os principais elementos de disponibili-
dade de um servico s ao:
Disponibilidade: Tempo durante o qual o servico estar

a disponvel;
Confiabilidade: Capacidade de se manter operacional dentro de um deter-
minado perodo de tempo;
Sustentabilidade: Capacidade de retorno ao estado normal ap

os algum
incidente;
Resiliencia: Capacidade de se manter operacional mesmo na falta de um

ou mais componentes;
Oficiosidade: Obrigac
oes contratuais com terceiros (Contratos de Apoio);
Seguranca: Confidencialidade, Integridade e Seguranca.
Dizemos que um servico esta disponvel quando o cliente o recebe dentro das
condic
oes do acordo de nvel de servico. Portanto, a taxa de disponibilidade e
dada pela seguinte f
ormula:
Disponibilidade = 100((T SA T F )/T SA))
onde T SA e o tempo de servico acordado e T F e o tempo durante o qual

o servico ficou indisponvel. Exemplo: Se um servico tem T SA 24x7 (precisa
estar disponvel 24 horas 7 dias por semana) e ficou indisponvel por um total de
10 horas durante um mes, ent ao a taxa de disponibilidade do servico no perodo
foi de 100x(((30x24x7)-10)/(30x24x7)), ou seja, 99,8015873%.
68.4.2 Ciclo de vida do incidente

Suponhamos que um incidente ocorrido no instante t1 tenha ocasionado a in-
terrupc
ao de um servico. No instante t2 o servico foi restabelecido, e em um
instante posterior t3, um outro incidente voltou a interromper o servico. A
partir dos valores de t1, t2 e t3 podemos definir as seguintes metricas:
TMPR (Tempo Medio para Reparo) = t2 t1;
TMEF (Tempo Medio Entre as Falhas) = t3 t2;
TMEIS (Tempo Medio entre Incidentes de Sistema) = t3 t1.
522
68.5 Gerenciamento de Continuidade

68.5.1 Objetivos
O processo de gerenciamento de continuidade tem como principal objetivo a
continuidade operacional dos servicos de TI em ocasi
oes de desastre, a fim de
suportar os requisitos mnimos do neg
ocio. O principal produto desse processo
e um documento chamado Plano de Continuidade dos Neg ocios (Business Con-
tinuity Plan - BCP). Os principais componentes de um plano de continuidade
s
ao:
Administrac
ao: Quando e como invocar o plano;
Infra-Estrutura de TI: Quais os itens envolvidos;
Procedimentos Operacionais: Instruc
oes de trabalho;
Pessoal: Respons
aveis, contatos e substitutos;
Site de Contingencia: Localizac
ao, contato e transporte;
Retorno ao normal: Como, onde e quanto tempo para o retorno.
Algumas metricas importantes de retorno a normalidade s

ao o RTO (Re-
covery Time Objective) e o RPO (Recovery point Objective). O RTO indica o
u
ltimo instante no tempo a partir do qual a operac
ao deve ser restabelecida
apos um desastre. O RPO, por sua vez, determina o ponto a partir do qual os
dados devem ser recuperados apos um desastre.
No processo de gerenciamento de continuidade s ao realizadas an alises de-

talhadas de risco e impacto, utilizando metodologias de an alise de risco como
CRAMM (CTTA Risk Analysis and Management Methodology), OCTAVE (Op-
erationally Critical Threat, Asset, and Vulnerability Evaluation), CORAS etc.
Todas essas metodologias s ao baseadas na norma ISO 27001. Uma elaborac ao
de uma an alise de risco e impacto, geralmente, se baseia na identificac
ao de tres
elementos que s ao: Ativos, Ameacas e Vulnerabilidades.
E a sopa de letrinhas n ao tem fim. Algumas outras siglas que podem ser
u
teis na hora da prova s
ao: BIA (Business Impact Analysis), OCP (Operational
Continuity Plan), DRP (Disaster Recovery Plan). Todas essas an alises e planos,
na verdade, fazem parte do Plano de Continuidade de Neg ocios.
68.5.2 Est
agios
Incio: Obtencao do aval gerencial e levantamento dos servicos de TI
crticos para o neg
ocio;
Requisitos Estrategicos: Analise de Risco e de Impacto e elaborac
ao da
estrategia de continuidade;
Implementac ao: Planejamento e implementac ao das instalac
oes para re-
cuperacao, elaborac
ao do plano de continuidade, medidas para reduc
ao de
riscos e realizac
ao de testes iniciais;
523
Gerenciamento Operacional: Educac

ao, revis
ao, auditoria, testes, treina-
mento e gerenciamento de mudancas.
68.5.3 Tipos de Continuidade

Soluc
oes de contorno manuais: Medidas tempor
arias ate que os servicos
sejam restabelecidos;
Acordos de reciprocidade: Organizac

oes concordam auxiliar uma a outra
em caso de desastres;
Recuperac
ao Gradual (Cold Standby): Ambiente computacional vazio, ex-
ceto por energia e telecomunicac
oes. Mnimo de 72 horas para reestab-
elecimento dos servicos;
Recuperacao Intermedi
aria (Warm Standby): Ambiente com equipamen-
tos para recuperac
ao dos servicos mais crticos entre 24 e 72 horas;
Recuperac
ao Imediata (Hot Standby): Instalac
ao alternativa com espel-
hamento contnuo de equipamentos e dados.
524
Parte XV
Ger
encia de Projetos
segundo PMBOK
525
Captulo 69
Gerenciamento de Escopo
A primeira
area de conhecimento definida pelo PMBOK e a de Gerenciamento
de Escopo. Os principais processos respectivas atividades desta
area s
ao:
1. Iniciac
ao: declarac
ao formal do incio do projeto, com a elaborac
ao do
Project Charter ;
2. Planejamento: declarac ao do escopo, indicando justificativas para o pro-
jeto, alem dos principais produtos, subprodutos e objetivos do projeto;
3. Detalhamento: elaboracao da Estrutura Analtica do Projeto (EAP ), tambem
conhecida como Work Breakdown Structure (WBS ), que tem por objetivo
identificar fases, atividades e pacotes de trabalho. A WBS e de grande
import ancia para realizac
ao de estimativas de tempo e custo;
4. Verificac
ao: trata da aceitac
ao do escopo;
5. Controle de Mudancas: identifica as mudancas de escopo assim como seus
motivos e impactos, alem de tratar dos ajustes necess
arios.
69.1 WBS e Defini

cao do Escopo
No processo de Definic
ao do Escopo, as entregas s ao subdivididas em com-
ponentes menores e gerenci aveis, para permitir o planejamento de tarefas e
atividades. As ferramentas e tecnicas desse processo s
ao a decomposic
ao e os
modelos da estrutura analtica do projeto (EAP ou WBS - Work Breakdown
Structure).
Segundo o PMBOK, a EAP e um conjunto de componentes do projeto, estru-

turados com base nas entregas, que organiza e define o escopo total do projeto;
o trabalho nao includo na EAP est a fora do escopo do projeto. Assim, com a
declarac
ao de escopo, a EAP equivale a um acordo b asico entre os stakeholders
e os integrantes da equipe com relac
ao ao escopo do projeto. Enfim, a EAP deve
especificar o escopo completo do trabalho necess ario para concluir o projeto.
A decomposicao e uma das ferramentas usadas na preparac

ao da EAP, e
envolve a subdivis
ao das entregas em componentes distintos o suficiente para
526
facilitar a realizac
ao das estimativas, a definic
ao de baseline para controle de
desempenho e a atribuic ao clara de responsabilidades. A estrutura mais comum
usada para representar essa decomposic ao e
arvore. O nvel 1 (raiz) e consid-
erado o pr oprio projeto, seguido pelas entregas, que podem ser seguidas por
outras entregas, seguidas por atividades e assim por diante. Cada elemento de
cada nvel da EAP deve receber um identificador exclusivo.
Figura 69.1: WBS - Work Breakdown Structure
O gerente de projeto pode determinar ` a vontade o numero de nveis na EAP,

com base na complexidade do projeto. Independentemente do n umero de nveis
da EAP, o nvel mais baixo de cada estrutura e denominado pacote de trabalho.
Pacotes de trabalho s ao as atividades ou componentes que podem ser facilmente
atribudos a uma pessoa ou grupo, que assumir ao a clara responsabilidade pelo
seu cumprimento. E no nvel de pacotes de trabalho que se fazem as estimativas
de tempo, custos e recursos. Cabe ressaltar que n ao existe nenhuma regra no
PMBOK determinando a presenca de atividades na EAP. Entretanto, quando
possvel, considera-se uma boa pr atica.
Finalmente, o Dicion ario da EAP contem uma descric ao do nvel dos pa-
cotes de trabalho e os detalhes relativos às atividades dentro de cada pacote.
Nele se encontram informac oes como custos, orcamentos, prazos, distribuic
ao de
recursos e descric
ao das atividades. Outro conceito importante s ao os marcos
de projeto (milestones). Os marcos s ao realizac
oes significativas do projeto que
ajudam a verificar o andamento dos trabalhos.
527
Captulo 70
Gerenciamento de Recursos
Humanos
A fase de Gerenciamento de Recursos Humanos engloba os seguintes processos:
1. Planejamento Organizacional : definic ao de equipes, perfis e responsabili-

dades, alem do formato da equipe (ex: democr atica descentralizada, con-
trolada centralizada, controlada descentralizada). Deve levar em consid-
erac
ao as caractersticas da organizac
ao (matricial forte ou fraca, orientada
a projetos,etc);
2. Montagem de Equipe: alocac

ao de pessoas ou equipes aos papeis definidos;
3. Desenvolvimento da Equipe: estrategias para aumentar capacidade das
pessoas e equipes, gerenciar conflitos (ex: negociac
ao,panos quentes,retirada,forca,etc).
Principais te
oricos: McGregor (Teoria XY ), Maslow (Pir amide de Neces-
sidades), Hezberg (Fatores Motivacionais).
70.1 Estruturas Organizacionais

70.1.1 Organiza
cao Funcional
As organizacoes funcionais giram em torno de especialidades e s ao agrupadas
por func
ao - da o nome organizacao funcional. Nela pode haver, por exemplo,
um departamento de recursos humanos, outro de marketing e etc. O trabalho
executado nesses departamentos e especializado e requer que os funcion arios

tenham aptid oes especficas e experiencia nas func
oes para cumprir as respons-
abilidades. Esse tipo de organizac ao e configurado de maneira hier arquica, ou
seja, cada funcion ario responde a um u nico gerente e, em u
ltima inst
ancia, existe
um u nico respons avel no topo. Cada departamento ou grupo e administrado
separadamente e tem um ambito de controle limitado. A seguir s ao apresen-
tadas as vantagens e desvantagens dessa organizac ao.
As principais vantagens e desvantagens dessa organizac

ao s
ao:
Vantagens:
528

ao Funcional
Estrutura organizacional duradoura;

Carreira profissional transparente;
Cadeia de comando explcita.
Desvantagens:
O gerente de projeto tem pouca ou nenhuma autoridade oficial;
V
arios projetos disputam recursos limitados e prioridades;
Os integrantes do projeto s
ao leais ao gerente funcional.
70.1.2 Organiza
c
ao por Projeto
As organizacoes por projeto sao praticamente o oposto das organizac oes fun-
cionais. O enfoque e o proprio projeto, assim cultiva-se a lealdade ao projeto e
n ao a um gerente funcional. Os gerentes de projeto tem total autoridade sobre
o projeto e respondem diretamente ao CEO. As equipes s ao formadas e seus
membros com freq uencia s
ao co-alocados, ou seja, trabalham no mesmo local
fsico.

ao por Projeto
As principais vantagens e desvantagens dessa organizac

ao s
ao:
Vantagens:
O gerente de projeto e a autoridade m

axima;
529
O enfoque da organizac
ao e o projeto;
Os recursos da organizac
ao s
ao destinados ao projeto;
Lealdade ao gerente do projeto;
Comunicac
ao efetiva.
Desvantagens:
Quando o projeto e finalizado a equipe e desalocada;
Uso dos recursos pode n
ao ser eficiente;
Duplicac
ao de func
oes.
70.1.3 Organiza
cao Matricial
As organizac oes matriciais surgiram para minimizar as diferencas entre os pontos
fortes e fracos das organizacoes funcionais e das estruturadas por projeto.e mel-
hor explor a-los. Assim, os objetivos s ao atendidos, tecnicas eficientes de geren-
ciamento de projetos s ao aplicadas, ao mesmo tempo que tambem se mantem a
estrutura hier arquica da organizacao.

ao Matricial
Os funcion arios de uma organizac

ao matricial se reportam ao gerente fun-
cional e a, no mnimo, um gerente de projeto - podendo ser subordinados a v arios
gerentes de projeto, caso trabalhem em v arios projetos simultaneos. O gerente
funcional responde por incumbencias administrativas e aloca funcion arios para
os projetos, alem de monitorar o trabalho de seus funcion arios nos diversos pro-
jetos. O gerente de projeto, por sua vez, e responsavel pela execuc
ao do projeto
e distribuic
ao das tarefas de acordo com as atividades previstas. Ambos divi-
dem as responsabilidades pela avaliacao de desempenho dos funcion arios.
Como se pode perceber, h a muita comunicac

ao e negociac
ao entre os gerentes
de projeto e funcional. Isso requer um equilbrio de poder entre os dois. Desse
modo, sao tres os tipos de organizac
ao matricial:
Matricial forte: gerente de projeto tem prioridade sobre gerente funcional;

Matricial fraca: gerente funcional tem prioridade sobre gerente de projeto;
Matricial Equilibrada: h
a negociac
ao entre gerente funcional e gerente de
projeto.
530
Em todo o caso, as vantagens e desvantagens s

ao:
Vantagens:
Quando o projeto e finalizado, a equipe e alocada em outras ativi-
dades na empresa;
A disseminac
ao de informac
oes ocorre na vertical e horizontal;
Os recursos escassos s
ao bem utilizados.
Desvantagens:
Mais de um gerente para a equipe do projeto se reportar;
Grande probabilidade de conflitos;
Precisa de pessoal administrativo extra para cumprir as necessidades
dos projetos.
70.2 Planejamento Organizacional

O objetivo desse processo e documentar as func oes e responsabildiades de in-
divduos e grupos para cada elemento do projeto e, em seguida, registrar as
relac
oes de subordinac ao de cada um. Neste momento devem ser definidas to-
das as equipes que estar ao envolvidas no projeto. Dessa forma, Marilyn Mantei
prop oe tres tipos de estruturas para equipes:
Democratica Descentralizada: nessa estrutura n

ao h
a um lder ou gerente
permanente. As decis oes s
ao tomadas por consenso. Na pr atica, n
ao
funciona muito bem para projetos;
Controlada Descentralizada: nessa estrutura h a um gerente geral para o
projeto e gerentes secundarios ou lderes locais. As decis
oes de problemas
do projeto sao tomadas por consenso entre o gerente do projeto e os ger-
entes secund arios. A execucao das ac
oes sao controladas pelos gerentes
secundarios. H a comunicac
ao horizontal e vertical. Essa estrutura e co-
mum em projetos que possuem v arios m odulos, principalmente, se estes
s
ao desenvolvidos em paralelo;
Controlada Centralizada: nessa estrutura ha um gerente geral para o pro-
jeto e os demais membros estao diretamente ligados a ele. N
ao h
a lderes
secundarios. S
o h
a comunicac
ao vertical.
70.3 Desenvolvimento da Equipe

O desenvolvimento da equipe implica criar um ambiente franco e estimulante
para que os stakeholders contribuam, e transformar a equipe num grupo coor-
denado, funcional e eficiente. Nesse aspecto e desej
avel manter a equipe sempre
motivada. Sao v
arias as teorias sobre a motivacao. As principais s
ao:
Hierarquia de necessidades de Maslow;
531
Teoria da Higiene ou teoria Motivac

ao-Higiene;
Teoria das Expectativas;
Teoria da Realizac
ao.
Maslow defendia a hip otese de que os seres humanos possuem cinco necessi-
dades basicas, distribudas em ordem hierarquica. Eis um resumo de cada uma
delas, do nvel mais alto ate o mais baixo:
Realizac
ao pessoal - Trabalhar no seu potencial m
aximo;
Necessidade de auto-estima - Realizac

ao, respeito por si mesmo, cpacitac
ao;
Necessidades sociais - Senso de pertencimento, amor, aceitac

ao, amizade;
Necessidade de protec
ao e seguranca - Seu bem-estar fsico e seus per-
tences.
Quando todas as necessidades fsicas, de protec

ao. Sociais e de auto-estima
forem atendidas, a pessoa alcancara um estado de independencia em que con-
seguir
a se expressar e realizar ao m
aximo, e far
a um bom trabalho apenas pelo
fato de fazer um bom trabalho.
Herzberg desenvolveu a teoria da Higiene que postula a existencia de duas

categorias de fatores que contribuem para a motivac ao: fatores de higiene e
motivadores. Os primeiros tratam de quest oes relacionadas ao ambiente de tra-
balho: evitam a insatisfac ao: sal
ario, benefcios, as condic
oes de ambiente de
trabalho. Os motivadores dizem respeito ` a substancia do trabalho em si e com
a satisfac
ao do sujeito ao exercer as func
oes do cargo: conduzem a satisfacao.
Segundo a Teoria das expectativas, e a perspectiva de um resultado positivo

que aciona a motivacao: as pessoas v
ao apresentar um determinado comporta-
mento de acharem que receber ao uma boa recompensa para isso. Alem disso,
a forca da expectativa influi no comportamento. A teoria alega ainda que as
pessoas se tornam o que se esperam delas.
Segundo a Teoria da Realizac ao somos motivados por tres necessidades: re-

alizac
ao, poder e afiliac
ao. A motivac
ao da realizac
ao e a necessidade de triunfar
ou atingir um dado objetivo. A motivac ao do poder refere-se ao desejo de in-
fluenciar os comportamentos alheios. E a necessidade de afiliac ao diz respeito a

relacionamentos.
Ao lado das teorias motivacionais est ao as teorias de sobre a lideranca.

Destacam-se as teorias X e Y e a teoria da contingencia.
McGregor estabeleceu dois modelos de comportamento dos trabalhadores, a

Teoria X e a Teoria Y, que procuram explicar como cada gerente lida com os
integrantes de suas equipes. Os gerentes adeptos da Teoria X acreditam que a
maioria das pessoas nao gosta de trabalhar, tem pouca ou nenhuma ambic ao,
precisam de supervisao constante n
ao cumprir ao suas obrigac
oes, a menos que
532
ameacadas. Em raz ao disso, agem como ditadores e imp oem ao seu pessoal
controles muito rgidos. J
a os gerentes partid
arios da Teoria Y entendem que as
pessoas vao se interessar por dar o melhor de si, se tiverem a motivac ao certa
e as expectativas adequadas. Assim, proporcionam apoio ` as suas respectivas
equipes, preocupam-se com seus membros e s ao bons ouvintes.
A teoria da contingencia resulta de uma combinacao entre as Teorias Y

e da Higiene; em suma, argumenta que somos motivados a atingir nveis de
competencia e continuaremos motivados por essa necessidade mesmo depois de
atingir a competencia.
533
Captulo 71
Gerenciamento do Tempo
Os processos da
area de Gerenciamento do Tempo segundo o PMBOK s
ao:
1. Definic
ao das Atividades: definir as atividades e respectivos respons
aveis.
2. Sequenciamento das atividades: estabelecer relac
oes de precedencia entre
as atividades (Diagramas de Precedencia);
3. Estimativas de Durac ao: estimar a durac
ao do projeto utilizando alguma
abordagem (TopDown, BottomUp). As principais tecnicas utilizadas para
realizac
ao de estimativas s
ao Modelos Matem aticos, Analogias e Consul-
toria de Especialistas;
4. Desenvolvimento do Cronograma : utilizac ao de alguma tecnica matematica
como PERT, CPM (Critical Path Method ) para formalizar o cronograma.
Tecnicas de Nivelamento de Recursos leva a alocac ao dos recursos em
conta no estabelecimento de precedencias das atividades. Para comprimir
o cronograma as tecnicas mais comuns s ao Crashing (adicao de recursos)
e Fast-Tracking (antecipac
ao de inicio de atividade);
5. Controle do Cronograma: comparar, analisar e revisar o cronograma para
permitir administrar desvios ao longo do projeto.
71.1 T
ecnicas de Desenvolvimento do Cronograma
Consiste em formalizar o cronograma, identificando suas datas, caminhos crticos
e registrando os marcos e pontos de controle identificados. H
a seis ferramentas
e tecnicas usadas no Desenvolvimento de Cronograma:
An
alise Matem
atica;
Compress
ao de cronograma;
Simulac
ao;
Heurstica de nivelamento de recursos;
Software de gerenciamento de projeto;
Estrutura de Codificac
ao.
534
71.1.1 An
alise Matem
atica
A an alise matem
atica consiste no c
alculo das datas de incio mais cedo e de
termino mais tarde das atividades do projeto - sem levar em conta as limitac
oes
dos recursos, o que acaba gerando prazos te
oricos. A an
alise matem
atica abrange
tres tecnicas:
Metodo do caminho crtico (CPM - Critical Path Method);

Tecnica de An
alise e Avaliac
ao Gr
afica (GERT - Graphical Evaluation
and Review Technique);
Tecnica de An
alise e Avaliac
ao de Programa (PERT - Program Evaluation
and Review Technique).
O metodo CPM calcula as datas de incio mais cedo, de fim mais cedo, de
incio mais tarde e de fim mais tarde de cada atividade. Para isso, baseia-se
em redes seq uenciais (em que uma atividade acontece depois da outra) e numa
estimativa unica de durac ao para cada atividade. O caminho crtico de todo
o projeto e o caminho mais longo. Toda atividade com folga igual a zero e
considerada uma tarefa do caminho crtico. Assim, para calcular a durac ao do
caminho crtico basta somar a durac ao de cada atividade com folha igual a zero.
Existem dois tipos de folga: folga total e folga livre. A primeira e o tempo to-
tal pelo qual e possvel atrasar o incio da tarefa sem prorrogar o termino do
projeto. Ja a folga livre e o tempo durante o qual e possvel atrasar o incio da
tarefa sem prorrogar o incio de uma tarefa subseq uente.
O que e preciso saber sobre a tecnica GERT e que ela aceita desvio condi-
cional, looping e tratamento probabilstico. Por exemplo, um o projeto de um
software pode exigir o teste de modulos individuais antes da verificac
ao do pro-
grama como um todo, a cada m odulo precisa ser aprovado em seu teste ` a parte.
Cada teste constitui uma execucao no laco.
A tecnica PERT usa o valor esperado para definir a durac ao do projeto, por-
tanto se baseia em ferramentas estatsticas para isso. As tecnicas com e PERT
s
ao muito parecidas, entretanto CPM usa a durac ao mais prov avel e PERT o
valor esperado (ou media ponderada).
71.1.2 Compress
ao do Cronograma
Trata-se de uma condensac ao do cronograma de modo a finalizar todas as ativi-

dades antes do estimado. Duas tecnicas s ao usadas; compress ao propriamente
dita (crashing) e paralelismo (fast tracking). A compress ao e uma tecnica que
leva em conta a relacao entre custo e cronograma. Uma das possibilidades e
adicionar recursos às tarefas do caminho crtico, j
a que estas atividades pos-
suem folga zero. Podem-se tambem limitar ou reduzir os requisitos do projeto.
Nem sempre produz os resultados esperados e geralmente acaba aumentando
os custos. O paralelismo consiste em iniciar ao mesmo tempo duas atividades
que a princpio estavam programadas para serem seq uenciais. A tecnica pode
aumentar os riscos do projeto e acarretar retrabalho.
535
71.1.3 Simula
cao
Na simulacao parte-se de diferentes conjuntos de premissas para chegar a diver-
sas durac
oes par ao projeto. O principal representante e a Simulac
ao de Monte
Carlo que mostra a probabilidade de todas as possveis datas de termino do pro-
jeto. Outra tecnica chamada what-if (an alise de hip
oteses) permite examinar o
cronograma sob diversas circunst ancias.
71.1.4 Heurstica do nivelamento de recursos

A analise matematica n ao leva em considerac
ao a disponibilidade de recursos.
Entretanto, com freq uencia o cronograma inicial tem perodos de tempo com
mais atividades do que recursos disponveis para elas e que nem sempre e possvel
alocar `
as tarefas 100 % do tempo dos membros da equipe. Nesse contexto, o
nivelamento de recursos - tambem chamado metodo baseado em recursos - visa
a aplainar a distribuic
ao de recursos para que as tarefas sejam concludas sem
sobrecarregar ninguem, ao mesmo tempo procurando manter o projeto dentro
do cronograma.
71.1.5 Estrutura de Codificac

ao
A estrurura de codificac
ao e uma ferramenta e tecnica relacionada `
a possibil-
idade de ordenar atividades com base em caractersticas que lhes podem ser
atribudas - como por exemplo classificac
oes da EAP, fases do projeto, tipo de
atividades e etc.
536
Captulo 72
Gerenciamento de Custo
Os processos englobados pela

area de Gerenciamento de Custo s
ao:
1. Planejamento dos Recursos: determinar quais recursos ser

ao necess
arios
e em que quantidade;
2. Estimativa dos Custos: associar custo aos recursos enumerados;
3. Orcamentac
ao dos Custos: alocacao das estimativas globais de custo s
ao
utilizadas para formalizar o orcamento;
4. Controle dos Custos: revisar o orcamento, identificar e administrar desvios.
72.1 T
ecnicas de Estimativas de Custos
As estimativas de custos emprega cinco ferramentas e tecnicas para gerar esti-
mativas:
Estimativa An
aloga
Modelagem Parametrica
Estimativas bottom-up
Ferramentas computadorizadas
72.1.1 Estimativas An
alogas
As estimativas an alogas, tambem chamadas de estimativas top-down, s ao uma

forma de opini ao especializada. Nessa tecnica usa-se a duracao real de uma
atividade similar realizada num projeto anterior para projetar a durac ao da
atividade atual. Essa tecnica e muito u til quando as atividades anteriores de
referencia s
ao realmente pr oximas com a atividade que est
ao sendo avaliada. E
particularmente u til quando nao ha informac
oes minuciosas sobre o projeto -
como ocorre em suas fases iniciais, por exemplo.
537
72.1.2 Modelagem Param

etrica
um modelo matem
E atico que usa par ametros - ou caractersticas do projeto -
para prever custos. A ideia e descobrir um ou varios parametros que se mod-
ifiquem paralelamente aos custos do projeto, incorporando-os ao modelo para
chegar a um custo total. Para utilizar essa tecnica e preciso haver um padr ao
no trabalho, de modo que possamos usar uma estimativa desse elemento para
gerar a estimativa total do projeto. A modelagem parametrica e semelhante ` a
estimativa an
aloga, na medida em que preve o custo do projeto inteiro de cima
para baixo.
72.1.3 Estimativa bottom-up

Esta tecnica e oposta `
a top-down, pois estima-se cada atividade ou item de tra-
balho separadamente para depois reuni-las ou agreg a-las numa estimativa total
do projeto. Trata-se de um metodo de estimac ao muito preciso, entretanto e
muito demorada, j a que o pacote de trabalho deve ser avaliado e estimado com
exatidao para ser includo no c
alculo. Essa n
ao e uma alternativa adequada para
fazer uma estimativa de custo na fase inicial do projeto, dada a inexistencia de
dados suficientes nessa etapa.
538
Captulo 73
Gerenciamento de Riscos
Aarea de gerenciamento de riscos e responsavel por minimizar a probabilidade

de ocorrencia de desvios ao longo do ciclo de vida do projeto. Os processos do
Gerenciamento de Riscos s ao:
1. Planejamento: definir qual ser

a a abordagem aos riscos;
2. Identificac
ao: identificar, descrever e classificar os riscos;
3. Analise Qualitativa: associar probabilidades e graus de impacto aos riscos
atraves de tecnicas como Matriz de Graduac ao, Matriz Probabilidade x
Impacto;
4. An
alise Quantitativa: associar probabilidades e graus de impacto de forma
numerica utilizando tecnicas como An
alise de Sensibilidade, Arvore de
Decis
ao e Simulac
oes;
5. Planejamento de Respostas: definir qual ac ao sera tomada mediante os
riscos identificados (ex: evitar, transferir, mitigar, aceitar);
6. Controle e Monitoraca o: garantir a execuc ao do plano,identificar novos
riscos, monitorar riscos residuais e realizar ajustes necess
arios.
73.1 An
alise Qualitativa
A An alise Qualitativa de Riscos visa ` a detecc
ao do impacto dos riscos identifi-
cados sobre os objetivos do projeto e sua probabilidade de ocorrencia. Tambem
classifica os riscos por prioridade, de acordo com os efeitos sobre os objetivos do

projeto. Nesse processo, basta atribuir ao risco um valor alto, medio ou baixo
(ou alguma combinac ao similar).
As ferramentas desse processo, de uma forma geral, visam a descobrir a

probabilidade de um evento de risco e a determinar seu impacto caso venha a
ocorrer. Nesse sentido, a ferramenta e tecnica Probabilidade e Impacto do Risco
atribui probabilidades aos eventos de risco identificados e calcula seu efeito so-
bre os objetivos do projeto. Esses metodos permitem determinar que riscos
demandam o gerenciamento mais agressivo.
539
Outra ferramenta e tecnica e a Matriz de classificac

ao de riscos por probabil-
idade e impacto (PI) cujo objetivo e atribuir uma classificac ao generica a cada
um dos risos identificados do projeto, geralmente expressa como alta, media ou
baixa. Segundo o guide to PMBOK, os riscos elevados correspondem a uma
situac
ao vermelha, os medios a uma situac ao amarela e os baixos, verde. Esse
tipo de classificac
ao e denominado de escala ordinal, porque os valores s ao orde-
nados de forma descendente. Ao fim desse processo, portanto, os riscos podem
ser enumerados por ordem de prioridade. A prioridade e estabelecida por meio
da matriz PI.
A matriz de PI e determinada a partir da multiplicac ao de dois valores: o

valor da probabilidade do risco vezes o valor do seu impacto (cada qual gerado na
escala correspondente). A avaliacao da probabilidade e impacto dos riscos cos-
tuma se dar por meio de tecnicas de opini ao especializada e entrevistas. Antes
de se chagar a matriz PI, porem, sao elaboradas a escala de probabilidades e a
escala de impacto dos riscos. O objetivo dessas escalas e desenvolver medidas
predefinidas que determinem que valor atribuir a determinado evento de risco.
73.2 An
alise Quantitativa de Riscos
A An alise Quantitativa de Riscos avalia os impactos e quantifica a exposic
ao do
projeto aos riscos por meio da atribuic ao de probabilidades numericas a cada
um e aos seus impactos sobre os objetivos do projeto. Para tanto, s ao usadas
tecnicas como a simulac ao de Monte Carlo e a an alise de decis
oes. Pode-se
usar tanto a An alise Qualitativa quanto a An alise Quantitativa para avaliar os
riscos, ou usar apenas uma dos dois. Essa decis ao ser
a tomada com base na
complexidade do projeto. As ferramentas e tecnicas desse processo s ao:
Entrevistas;
An
alise de Sensibilidade;
An
alise da
arvore de decis
oes;
Simulac
ao.
An alise de Sensibilidade e um metodo de an alise do possvel impacto dos

eventos de risco sobre o projeto e determinac ao de que evento (ou eventos) de
risco tem maior impacto potencial. Tambem pode ser empregada para averiguar
os nveis de toler
ancia aos riscos por parte dos stakeholders. Ela examina a ex-
tensao a qual a incerteza de cada elemento do projeto afeta o objetivo que est a
sendo examinado quando todos os outros elementos incertos s ao mantidos em
seus valores iniciais.
A an alise da
arvore de decisoes s
ao diagramas que mostram a seq uencia de
decis
oes inter-relacionadas e os resultados esperados de acordo com a alternativa
escolhida. Em geral existe mais de uma escolha ou opc ao disponvel quando
nos deparamos com uma decis ao - ou, nesse caso, possveis consequencias de
um evento de risco. As escolhas disponveis s ao expostas em forma de arvore,
comecando ` a esquerda com a decis ao relacionada ao risco, e ramificando para a
540
direita, com as possveis conseq

uencias. Essas
arvores costumam ser usada para
os eventos de riscos associados a tempo e custo.
A simulac ao tem como principal representante a tecnica de Monte Carlo.

Ela ajuda a quantificar os riscos associados ao projeto com um todo. Os riscos
identificados e seus possveis impactos sobre os objetivos do projeto s
ao exam-
inados sob o prisma do projeto global. A tecnica e usada para determinar os
possveis resultados pr meio da simulac
ao do projeto diversas vezes seguidas.
541
Captulo 74
Gerenciamento de
Qualidade
Os processos para realizac

ao do Gerenciamento de Qualidade como definidos no
PMBOK s ao:
1. Planejamento: definic
ao dos padr
oes de qualidade relevantes ( Bench-
marking, Diagrama Espinha de Peixe (causa/efeito) e Fluxograma Pro-
cesso);
2. Garantia: verificar relev
ancia dos processos definidos;
3. Controle: analisar de padr oes est

ao sendo seguidos, identificar causas de
desvios. Ferramentas muito utilizadas s ao a Carta Controle, Diagrama de
Pareto (direcionar ac
oes corretivas).
74.1 T
ecnicas de Planejamento da Qualidade
O processo de Planejamento da Qualidade visa ao cumprimento de padr oes de
qualidade para o projeto em quest ao, elaborando, para tanto, um plano. Se-
gundo o guide to PMBOK a qualidade e planejada, n ao inspecionada. Portanto,
uma sada desse processo e o plano de gerenciamento da qualidade que especi-
fica como a poltica de qualidade ser
a implementada pela equipe de gerencia de
projeto no decorrer das atividades. Para isso, v arias ferramentas sao empre-
gadas. Os principais exemplos s ao: analise de custo/benefcio, benchmarking,
fluxograma, elaborac ao de experimentos e custo da qualidade.
74.1.1 An
alise Custo/Benefcio
Analise de custo/benefcio aborda as compensacoes no custo da qualidade. E
mais barato e eficiente prevenir problemas do que ter de perder tempo e dinheiro
para corrigi-los mais tarde. O guide to PMBOK salienta que o custo b asico do
cumprimento dos requisitos de qualidade num projeto equivale ` as despesas im-
plicadas na execucao das atividades de gerenciamento da qualidade.
542
74.1.2 Benchmarking
um processo de comparac
E ao de atividades anteriores similares ` as do projeto
atual para obter um par
ametro de referencia para a avaliac
ao do desempenho. A
comparac
ao acaba sugeringo ideias para melhorar a qualidade no projeto atual.
Por exemplo, se a impressora imprime 8 p aginas por minuto e o projeto est a
considerando comprar uma que imprima 14 p aginas por minuto, a referencia e
a impressora usada no projetos ate ent
ao.
74.1.3 Fluxograma
S
ao diagramas que mostram as etapas l ogicas a serem executadas para atingir
um objetivo. Tambem podem discriminar como se d ao as relac
oes entre os di-
versos elementos de um sistema. Os fluxogramas podem ajudar a identificar
possibilidades de ocorrencia de problemas no projeto. H a dois tipos mais co-
muns de fluxogramas: os diagramas de processo ou sistema e os diagramas de
causa e efeito.
Os diagramas de causa e feito mostram a relac

ao entre os efeitos dos prob-
lemas e suas causas, apresentando todas as possveis causas prim arias e se-
cundarias dos problemas, bem como os efeitos de cada soluc
ao sugerida. Esse
diagrama tambem e chamado de espinha de peixe ou de Ishikawa.
Figura 74.1: Diagrama Causa/Efeito
O fluxograma de sistema ou processos exibe as etapas l

ogicas necess
arias para
atingir determinado objetivo, bem como a relacao entre diferentes elementos de
um sistema. Esse e o mais conhecido; geralmente e construdo com ret angulos
e paralelogramos que, ordenados numa seq uencia l
ogica, permitem ramificacoes
baseadas em sim e n ao
74.1.4 Elabora
cao de Experimentos
uma tecnica estatstica que identifica os elementos ou vari
E aveis que surtir
ao
os efeitos mais profundos sobre os resultados globais do projeto. Ela e aplicada
com mais freq uencia ao produto do projeto, mas tambem pode ser utilizada nos
processos de gerenciamento que examinam relac oes de compensac
ao. O processo
cria e realiza experimentos para chegar à soluc
ao ideal de um problema, a partir
de um n umero limitado de exemplos.
543
74.1.5 Custo da Qualidade

O custo da qualidade diz respeito ao custo total da gerac
ao do produto ou servico
do projeto de acordo com os padr oes de qualidade, e engloba todo o trabalho
necess
ario para atender os requisitos do produto - quer tenha sido planejado ou
n
ao. Existem tres custos associados ao custo da qualidade:
Custo de Prevenc
ao;
Custo de Avaliac
ao;
Custo de falhas, divididos em custos internos e custos externos.
Os custos de prevenc
ao sao aqueles associados ao cumprimento dos requi-
sitos dos clientes por meio da geracao de produtos livres de defeitos; vem a
tona logo no comeco do processo e compreendem fatores como planejamento da
qualidade, treinamento, analise de projeto.
Os custos de avaliac
ao s
ao aqueles em que se incorre para examinar o pro-
duto ou processo e averiguar se determinados requisitos est
ao sendo atendidos.
Podem incluir custos associados a elementos como inspecoes e testes.
Custos de falhas sao aqueles que ocorrem quando as coisas n ao se passam

conforme o planejado. S ao dois tipos: internos (tambem chamado de custo de
erro) e externos (tambem chamado de custo de defeito). O primeiro se imp oe
quando os requisitos do cliente deixam de ser satisfeitos com o produto ainda
sob controle da organizac
ao. Os custos de falhas externas se dao quando o pro-
duto j
a chegou ao cliente e este entende que suas determinac
oes ainda nao foram
atendidas.
Tres te
oricos em particular s
ao respons
aveis pela expans ao do movimento
pelo gerenciamento da qualidade e das teorias a respeito do custo da quali-
dade: Crosby, Juran e Deming. Crosby criou a pr atica do zero defeito - que
significa, basicamente, acertar de primeira. A prevenc ao e a peca central da
teoria de Crosby. Juran e conhecido pelo seu princpio da adequac ao ao uso
- que significa, em termos simples, a satisfac
ao ou superac
ao das expectativas
dos stakeholders clientes. A conformidade e peca central na teoria de Juran.
Deming afirma que ate 85% do custo da qualidade s ao problemas gerenciais.
Quando a quest ao da qualidade chega `
a base, ao patamar dos oper arios, estes
tem pouco controle a exercer. Ao lado dos tres te

oricos, pode-se citar como de
importante relev ancia a Abordagem Kaizen que significa melhoria contnua.
74.2 T
ecnicas de Controle da Qualidade
O controle de qualidade preocupa-se particularmente com o monitoramento dos
resultados do trabalho, a fim de verificar se est
ao cumprindo os padroes estab-
elecidos no plano de gerenciamento da qualidade. Existem v arias ferramentas e
tecnicas nesse processo:
544
Inspec
ao;
Gr
aficos de Controle (Carta de Controle);
Diagramas de Pareto;
Diagramas de Dispers
ao;
Amostragem Estatstica;
Elaborac
ao de Fluxogramas (Diagramas de Causa e Efeito, Fluxograma
de Sistemas);
An
alise das Tendencias.
74.2.1 Gr
aficos de Controle
Medem os resultados dos processos ao longo do tempo e exibem-nos em formato
gr
afico; constituem uma maneira de mensurar variac oes a fim de averiguar se
as variac
oes dos processos estao ou nao sob controle. Os gr aficos de controle
se baseiam na mediac ao de variac
oes de amostras escolhidas e mensuradas das
quais se determinam a media e o desvio-padr ao. O controle da qualidade cos-
tuma ser mantido - ou considerado sob controle - dentro de mais ou menos tres
desvios-padrao. Em outras palavras, o Controle da Qualidade considera que o
processo encontra-se sob controle quando se sabe que 99,73% das pecas a ele
submetidas v ao recair num intervalo aceitavel da media. Caso de descubra uma
peca fora desse intervalo, deve-se averiguar a necessidade de eventuais medidas
corretivas.
Figura 74.2: Gr
afico de Controle
Existen dois tipos de gr

aficos de controle que s
ao (i) Controle por vari
aveis
e (ii) Controle por atributos.
74.2.2 Diagramas de Pareto

Baseia-se na regra 80/20 onde e afirmado que 80% dos problemas s ao causados
por um pequeno n umero de causas, 20%. Os diagramas de Pareto assumem a
forma de histogramas que classificam os fatores mais importantes (como atrasos,
custos, defeitos ou outros) conforme a freq uencia ao longo do tempo. A teoria
prega que se obtem o m aximo benefcio se for dedicado a maior parte do tempo
a correc
` ao dos problemas mais relevantes. Os problemas s ao classificados de
acordo com a freq uencia e a porcentagem de defeitos.
545
74.2.3 Diagramas de Dispers

ao
Os diagramas de dispers ao usam duas variaveis, uma denominada vari avel in-
dependente, que e entrada, e outra chamada vari avel dependente, que e uma
sada, e mostram a relac
ao entre ambas, sob a forma de pontos no grafico.
546
Captulo 75
Gerenciamento da
Comunicac
ao
Segundo o PMBOK,o Gerenciamento da Comunicac

ao e dividido nos seguintes
processos:
1. Planejamento: definicao das informac

oes necess
arias, objetos de comu-
nicac
ao e layouts de documentos;
2. Distribuic
ao das Informac
oes: disponibilizar as informac
oes necess
arias
as partes envolvidas;
`
3. Relato de Desempenho: relat

orios de situac
ao, de progresso e previs
oes;
4. Encerramento Administrativo: encerramento formal do projeto. Divulgac ao
dos resultados do projeto para patrocinadores e cliente, considerc
oes finais,
an
alise dos pontos fracos e fortes.
75.1 Um mais sobre Planejamento da Comu-

nicac
ao
Compreende a determinac ao das necessidades de comunicac ao do stakeholders
por meio da definic ao dos tipos de dados necess
arios e do formato em que ser ao
transmitidos. Dois fatores influenciam esse processo: os requisitos de comu-
nicac
ao e a tecnologia envolvida. A sada desse processo e o plano de geren-
ciamento das comunicac oes. Ele estabelece como coletar, armazenar, arquivar
e corrigir ou atualizar materiais j a divulgados. Contem tambem uma lista das
informacoes a serem distribudas, o momento de sua comunicac ao e a estrutura
de distribuic
ao, alem de descrever como os stakeholders podem ter acesso a in-
formacoes do projeto antes das datas de divulgac ao. As informac oes a serem
compartilhadas e os metodos de distribuic ao dependem das necessidades dos
stakeholders, da complexidade do projeto e das polticas organizacionais.
547
Captulo 76
Gerenciamento das
Aquisic
oes
A
area de gerenciamento de comunicac
oes e composta pelos seguintes processos:
1. Planejamento: identificacao das necessidades que ser

ao melhor atendidas
por terceiros. Elaboracao da SOW (Specification of Work );
2. Preparac
ao: elaborac
ao da documentacao para licitac
oes ou concorrencia;
3. Obtenc
ao de Propostas: selec
ao de fornecedores utilizando criterios definidos;
4. Administrac
ao de Contratos: acompanhar desempenho de fornecedores;
5. Encerramento Contrato: formalizar fim de contrato e arquivamento de
informac
oes.
76.1 Um pouco mais sobre Planejamento de Aquisi

coes
O Planejamento de Aquisic oes e um processo que identifica os bens ou servicos a
serem comprados fora da organizac ao - o que inclui confirmar se devem adquirir
os produtos ou servicos e, em caso afirmativo, quanto e quando. Duas ferra-
mentas s ao usadas com freq uencia nesse processo: an alise ?make or buy? e
selec
ao do tipo de contrato. A principal decis ao a ser tomada por medio dessa
analise e se vai ser melhor, em termos de custos para a organizac ao, comprar ou
fabricar os bens ou servicos necess arios par ao projeto. J a a outra tecnica trata
da selecao do tipo de contrato usado para aquisic ao de produto ou servico. Os
tipos de contrato s ao:
Contratos de preco fixo ou preco global: O contratado arca com a maior

parte dos riscos;
Contrato de custos reembols

aveis: O contratante arca com a maior parte
dos riscos;
+ Custo mais remunerac

ao fixa
548
+ Custo mais remunerac

ao de incentivo
Contrato por tempo e material: Tipo hbrido. As duas partes dividem os
riscos.
A principal sada desse processo e a Declarac

ao de Trabalho(DT) ou Especi-
ficac
ao de Trabalho (SOW - Especification of Work). A DT descreve o item
a ser contratado com suficiente detalhamento para permitir que os potenciais
fornecedores possam avaliar se s ao capazes de atender o edital Deve conter no
mnimo:
Os objetivos do projeto;
Uma descric
ao do trabalho do projeto;
Especificac
oes concisas do bem ou servico necess
arios;
Um cronograma do projeto.
549
Captulo 77
Gerenciamento da
Integrac
ao
Para assegurar que

areas estao bem coordenadas o PMBOK define a area de
Gerenciamento da Integrac
ao, que e composta pelos seguintes processos:
1. Desenvolvimento do Plano do Projeto: reune todas as

areas em em um
documento chamado Plano de Projeto);
2. Execuc
ao do Plano: onde e gasto maior parte Orcamento;
3. Controle Integrado de Mudancas: analisar as possveis mudancas, motivos

e respectivos impactos ao longo do projeto. Os ajustes devem ser feitos
de forma integrada.
77.1 Ferramentas de Apoio `

a Integra
cao
Duas ferramentas s ao usadas nessa area: Gerenciamento de Valor Agregado
(GVA ou EVM - Earned Value Management) e os softwares de gerenciamento
de projetos. O GVA e uma metodologia de integrac ao de projetos empregada
para integrar processos e mensurar o desempenho do projeto ao longo do ciclo
de vida do projeto. O MS Project e um exemplo de software de ap
oio `
a gerencia
de projetos. Outro exemplo e o Primavera TeamPlayer.
O GVA pode ser empregado tanto no processo de controle de custos quanto

no processo de planejamento. No u
ltimo caso, o GVA, que visa ` a mensurac
ao
e ao relato do andamento do projeto, incorpora o cronograma do projeto, seu
escopo e recursos como um todo para determinar se existem discrep ancias no
projeto. No primeiro caso, OGVA apoia o c
alculo das variac
oes de custo.
550
Captulo 78
Sobre os Ciclos do Projeto

e Processos de
Gerenciamento
Todos os projetos sao divididos em fases e, sejam grandes ou pequenos, tem um

ciclo de vida parecido. O conjunto de fases coletivas atravessadas pelo projeto
e denominado ciclo de vida do projeto. O termino de cada fase pode ser
reconhecido pela apresentacao de uma entrega especfica (ou v
arias), marcando
o final daquela etapa. Entrega e tudo o que deve ser produzido para que a
fase ou o projeto sejam encerrados; s ao elementos tangveis, que podem ser
avaliados e comprovados com facilidade. As avaliacoes empreendidas ao final de
cada estagio recebem varios nomes tais como: sadas de fase, passagem de
estagio ou pontos de encerramento.
Como mencionado anteriormente, os projetos possuem um ciclo de vida pare-

cido. Esse ciclo de vida pode ser organizado nos seguintes grupos processos:
iniciac
ao, planejamento, execuc
ao, controle e encerramento. Os cinco grupos
s
ao iterativos. A figura 78.1 apresenta os grupos de processos em um ciclo de
vida de projeto tpico.
Figura 78.1: Ciclo de Vida do Projeto
551

Arquitetura Computadores

Enviado por

Direitos autorais:

Formatos disponíveis

Arquitetura Computadores

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Arquitetura Computadores

Enviado por

Direitos autorais:

Formatos disponíveis

http://www.candidatoreal.

3.1.1 Sinal e amplitude/magnitude . . . . . . . . . . . . . . . . 39

5 Principais Processadores de Mercado 65

6.2 Conceitos fundamentais . . . . . . . . . . . . . . . . . . . . . . . 84

III Metodologia de Desenvolvimento 92

7.4 Modelo RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

8 Analise Comparativa de Processos de Desenvolvimento 102

9 Engenharia de Requisitos 109

10.2 Metricas de projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 119

14 CMM - Capability Maturity Model 149

14.1.4 Nvel 4 - Gerenciado . . . . . . . . . . . . . . . . . . . . . 152

16 Classes Essenciais 173

18 JDBC - Java Database Connectivity 199

18.5 Prepared Statements . . . . . . . . . . . . . . . . . . . . . . . . . 203

19 A plataforma J2EE 207

19.4 Um pouco mais sobre p aginas JSP . . . . . . . . . . . . . . . . . 213

V Desenvolvimento Web 220

24.8 Elemento <xsl:value-of> . . . . . . . . . . . . . . . . . . . . . . . 251

25 Gerenciador de Conte udo Web Zone/Plone 256

26 Web Services 263

28 Topologias de Redes 284

29 Arquitetura de Redes 286

30 Protocolos de Rede 287

30.6 HTTP - Hyper Text Transfer Protocol . . . . . . . . . . . . . . . 294

33 Redes Ethernet 322

34 Cabeamento Estruturado 326

35 Redes sem fio 337

35.1.1 CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . 338

36 Elementos de Interconex ao de Redes de Computadores 340

37 Redes Multimdia 344

38 Redes X.25 e Frame Relay 348

39 Redes Virtuais Locais 354

40 Redes de Circuito Virtuais 356

41 Arquitetura TCP/IP 360

43.1 Management Information Base . . . . . . . . . . . . . . . . . . . 368

44.4.2 Famlia ISO 27000 . . . . . . . . . . . . . . . . . . . . . . 375

45 Seguran ca Fsica e Logica 379

46 Backup de Dados 384

47 Vrus e Ataques 386

48 Princpios de Criptografia 390

49 Autentica cao 395

50 Seguran ca em diversas camadas 399

50.4.4 Application Gateway . . . . . . . . . . . . . . . . . . . . . 407

IX Alta Disponibilidade 411

52 Clusters de servidores 427

53 Balanceamento de Carga 436

X Sistemas Operacionais 442

54.2.2 Seguranca de Acesso . . . . . . . . . . . . . . . . . . . . . 449

XI Banco de Dados 465

56 Abordagem Relacional 468

57 Modelagem Entidade Relacionamento 470

58.2 Forma normal de Boyce-Codd . . . . . . . . . . . . . . . . . . . . 473

60 Linguagem SQL 476

60.6 Chaves estrangeiras . . . . . . . . . . . . . . . . . . . . . . . . . . 479

61 Conceitos de Datawarehousing e Bussiness Inteligence 480

XIII Oracle e Microsoft SQL Server 497

66.1 Arquitetura de um Servidor SQL Server . . . . . . . . . . . . . . 506

XIV ITIL 509