HB - Ti Concursos

http://www.candidatoreal.
com
http://www.candidatoreal.com
Sumrio a
I Fundamentos de Computao ca
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
17 17 18 20 22 24 25 26 28 29 29 30 30 31 33 34 34 36 37 37 38 38 39 39 39 39 39 40 41 41 42 43
1 Arquitetura e Organizao de Computadores ca 1.1 Conceitos Bsicos . . . . . . . . . . . . . . . . . a 1.2 Estrutura e Funcionamento da CPU . . . . . . 1.2.1 Pipelines . . . . . . . . . . . . . . . . . 1.3 Conjunto de Instrues . . . . . . . . . . . . . . co 1.4 Unidade de Controle . . . . . . . . . . . . . . . 1.5 Modos de Endereamento . . . . . . . . . . . . c 1.6 Organizao de Memria . . . . . . . . . . . . . ca o 1.7 Desempenho do computador . . . . . . . . . . . 1.7.1 Tempo de execuo de um programa . . ca 1.7.2 Desempenho da CPU . . . . . . . . . . 1.7.3 Programas para medir desempenho . . . 1.7.4 Comparando desempenho . . . . . . . . 1.7.5 Lei de Amdahl . . . . . . . . . . . . . . 2 Componentes de um Computador 2.1 Principais componentes de Hardware 2.1.1 Discos R gidos . . . . . . . . 2.1.2 Teclado . . . . . . . . . . . . 2.1.3 Mouse . . . . . . . . . . . . . 2.1.4 Placa de rede . . . . . . . . . 2.1.5 Impressora . . . . . . . . . . 2.1.6 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Aritmtica Computacional e 3.1 Nmeros Com Sinal e Nmeros Sem Sinal . . . u u 3.1.1 Sinal e amplitude/magnitude . . . . . . 3.1.2 Complemento de 1 . . . . . . . . . . . . 3.1.3 Complemento de 2 . . . . . . . . . . . . 3.1.4 Notao em excesso . . . . . . . . . . . ca 3.2 Adio e Subtrao . . . . . . . . . . . . . . . . ca ca 3.3 Operaes Lgicas . . . . . . . . . . . . . . . . co o 3.4 Construo de uma Unidade Lgica Aritmtica ca o e 3.5 Ponto Flutuante . . . . . . . . . . . . . . . . .
4 Sistemas Operacionais 4.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . ca 4.2 Conceitos Bsicos . . . . . . . . . . . . . . . . . . . a 4.2.1 Multiprogramao . . . . . . . . . . . . . . ca 4.2.2 Processo . . . . . . . . . . . . . . . . . . . . 4.2.3 Interrupes . . . . . . . . . . . . . . . . . . co 4.2.4 Threads . . . . . . . . . . . . . . . . . . . . 4.3 Escalonamento de Processos . . . . . . . . . . . . . 4.4 Entrada e Sa . . . . . . . . . . . . . . . . . . . . da 4.4.1 Camadas do subsistema de Entrada e Sa da 4.5 Gerncia de Memria . . . . . . . . . . . . . . . . . e o 4.6 Sistemas de Arquivos . . . . . . . . . . . . . . . . . 4.6.1 Conceitos bsicos sobre arquivos . . . . . . a 4.6.2 Implementaao de arquivos . . . . . . . . . c 4.6.3 Cache de Sistema de Arquivos . . . . . . . 4.6.4 Gerenciamento do espao livre . . . . . . . c 4.6.5 Diretrios . . . . . . . . . . . . . . . . . . . o 4.6.6 Implementaao de diretrios . . . . . . . . . c o 4.7 Sistemas Operacionais Distribu dos . . . . . . . . . 4.7.1 Estruturao de Sistemas Distribu ca dos . . . 5 Principais Processadores de 5.1 Processadores Intel . . . . 5.1.1 Fam Pentium . lia 5.1.2 Fam Celeron . . lia 5.1.3 Fam Core . . . lia 5.1.4 Xeon . . . . . . . . 5.1.5 Itanium . . . . . . 5.2 AMD . . . . . . . . . . . 5.2.1 Sempron . . . . . . 5.2.2 Athlon 64 . . . . . 5.2.3 Turion 64 . . . . . 5.2.4 Opteron . . . . . . Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44 44 46 46 46 47 48 49 50 51 52 54 54 56 57 58 59 61 61 63 65 65 65 68 69 71 74 75 75 76 79 81
II
Lgica de Programao o ca
. . . . . . . . . . . . . . . . . . . . . . . . orientada a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
84 84 84 90 90
6 Orientao a Objetos ca 6.1 Introduo . . . . . . . . . ca 6.2 Conceitos fundamentais . 6.3 Princ pios de programao ca 6.4 Tratamento de exceoes . c
III
Metodologia de Desenvolvimento
92
7 Ciclo de Vida 93 7.1 Modelo seqencial linear . . . . . . . . . . . . . . . . . . . . . . . 95 u 7.2 Modelo em V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.3 Modelo de prototipagem . . . . . . . . . . . . . . . . . . . . . . . 96
7.4 7.5
7.6 7.7 7.8
Modelo RAD . . . . . . . . . . . . . . . . . . . Modelos de processo de software evolucionrios a 7.5.1 Modelo incremental . . . . . . . . . . . 7.5.2 Modelo espiral . . . . . . . . . . . . . . 7.5.3 Modelo espiral ganha-ganha . . . . . . . 7.5.4 Modelo de desenvolvimento concorrente Desenvolvimento baseado em componentes . . . Modelo de mtodos formais . . . . . . . . . . . e Tcnicas de quarta gerao . . . . . . . . . . . e ca
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96 97 97 98 99 100 100 100 100 102 102 105 105 106 106 107 107 109 109 110 110 110 111 111 111 111 112 112 112 112 113 114 114 116 118 118 119 119 120 120 122 122 123 123 124 124 125
8 Anlise Comparativa de Processos de Desenvolvimento a 8.1 RUP - Rational Unied Process . . . . . . . . . . . . . . . 8.2 XP - Extreme Programming . . . . . . . . . . . . . . . . . 8.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Crystal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Feature Driven Development (FDD) . . . . . . . . . . . . 8.6 Dynamic Systems Development Method (DSDM) . . . . 8.7 Adaptive Software Development (ASD) . . . . . . . . . . 9 Engenharia de Requisitos 9.1 O Processo de Engenharia de Requisitos 9.2 Tcnicas de Levantamento de Requisitos e 9.2.1 Observao . . . . . . . . . . . . ca 9.2.2 Entrevista . . . . . . . . . . . . . 9.2.3 Anlise de Protocolo . . . . . . . a 9.2.4 JAD . . . . . . . . . . . . . . . . 9.2.5 PD . . . . . . . . . . . . . . . . . 9.2.6 QFD . . . . . . . . . . . . . . . . 9.2.7 CRC . . . . . . . . . . . . . . . . 9.2.8 Prototipao . . . . . . . . . . . ca 9.2.9 Cenrios . . . . . . . . . . . . . . a 9.2.10 FAST . . . . . . . . . . . . . . . 9.3 Anlise de Requisitos . . . . . . . . . . . a 9.3.1 Mtodos de anlise . . . . . . . . e a 9.3.2 Modelagem da anlise . . . . . . a 9.4 Gerenciamento de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 Mtricas e 10.1 Mtricas de processo e aperfeioamento de processo e c 10.2 Mtricas de projeto . . . . . . . . . . . . . . . . . . e 10.3 Medio de software . . . . . . . . . . . . . . . . . ca 10.3.1 Mtricas orientadas a tamanho . . . . . . . e 10.3.2 Mtricas orientadas a funo . . . . . . . . e ca 10.3.3 Mtricas de pontos por funao estendidas . e c 10.4 Mtricas de qualidade de software . . . . . . . . . e 10.4.1 Fatores de qualidade de McCall . . . . . . . 10.4.2 FURPS . . . . . . . . . . . . . . . . . . . . 10.4.3 ISO 9126 . . . . . . . . . . . . . . . . . . . 10.5 Estimativas . . . . . . . . . . . . . . . . . . . . . . 10.5.1 COCOMO (Constructive Cost Model) . . .
de . . . . . . . . . . . . . . . . . . . . . .
software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11 Testes 11.1 Teste de caminho bsico . . . . . . . . . . . . . . . . . . . . a 11.2 Teste de estrutura de controle . . . . . . . . . . . . . . . . . 11.2.1 Teste de condio . . . . . . . . . . . . . . . . . . . . ca 11.2.2 Teste de uxo de dados . . . . . . . . . . . . . . . . 11.2.3 Teste de ciclo . . . . . . . . . . . . . . . . . . . . . . 11.3 Teste caixa-preta . . . . . . . . . . . . . . . . . . . . . . . . 11.3.1 Mtodos de teste baseados em grafo . . . . . . . . . e 11.3.2 Particionamento de equivalncia . . . . . . . . . . . e 11.3.3 Anlise de valor limite . . . . . . . . . . . . . . . . . a 11.3.4 Teste de comparao . . . . . . . . . . . . . . . . . . ca 11.3.5 Teste de matriz ortogonal . . . . . . . . . . . . . . . 11.4 Teste de ambientes, arquiteturas e aplicaes especializadas co 11.5 Estratgia de teste de software . . . . . . . . . . . . . . . . e 12 UML 12.1 Diagrama de caso de uso . . . . . 12.1.1 Ator . . . . . . . . . . . . 12.1.2 Descrio do caso de uso . ca 12.2 Diagrama de classe . . . . . . . . 12.2.1 Associaes de classe . . . co 12.3 Diagramas de seqncia . . . . . ue 12.4 Diagramas de colaborao . . . . ca 12.5 Diagramas de estado . . . . . . . 12.6 Diagramas de atividade . . . . . 12.7 Elementos auxiliares . . . . . . . 12.8 Diagramas de componente . . . . 12.9 Diagramas de distribuio . . . . ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
127 127 129 129 130 130 131 131 131 132 132 132 133 134 136 136 136 137 137 138 140 140 141 143 144 144 144 145 146 147 147 149 150 150 150 151 152 152 152 153
13 Gerncia de Congurao e Mudanas e ca c 13.1 As Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3 Papis e Responsabilidades . . . . . . . . . . . . . . . . . . . . . e 14 CMM - Capability Maturity Model 14.1 Os n veis de maturidade no CMM . . . . . 14.1.1 N 1 - Inicial . . . . . . . . . . . . vel 14.1.2 N 2 - Repetitivo . . . . . . . . . vel 14.1.3 N 3 - Denido . . . . . . . . . . . vel 14.1.4 N 4 - Gerenciado . . . . . . . . . vel 14.1.5 N 5 - Otimizado . . . . . . . . . vel 14.2 Um pouco mais sobre KPAs . . . . . . . . 14.3 Efeitos da evoluo do n de maturidade ca vel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IV
Linguagem de Programao Java ca
155
15 Conceitos Bsicos de Java a 156 15.1 Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 15.2 Modicadores de Acesso . . . . . . . . . . . . . . . . . . . . . . . 157
15.3 Variveis . . . . . . . . . . . . . . a 15.4 Operadores . . . . . . . . . . . . 15.5 Expresses, Sentenas e Blocos . o c 15.6 Comandos de Controle de Fluxo 15.7 Classes Aninhadas . . . . . . . . 15.8 Tipos Enumerados . . . . . . . . 15.9 Anotaes . . . . . . . . . . . . . co 15.10Genricos . . . . . . . . . . . . . e 15.11Reexo . . . . . . . . . . . . . . a
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
157 158 160 161 166 167 168 169 171 173 173 173 175 176 176 177 178 178 179 180 181 181 183 185 185 188 189 190 193 195 197 199 199 200 200 201 203 203 204 205 207 208 209 209 211 212
16 Classes Essenciais 16.1 Exception e Controle de Excees . . . . . co 16.1.1 Excees t co picas . . . . . . . . . . 16.1.2 Capturando Excees . . . . . . . co 16.2 Threads e Concorrncia . . . . . . . . . . e 16.2.1 Denindo e Iniciando uma Thread 16.2.2 Pausando a execuo com sleep . . ca 16.2.3 Interrupes . . . . . . . . . . . . . co 16.2.4 Joins . . . . . . . . . . . . . . . . . 16.2.5 Sincronizao . . . . . . . . . . . . ca 16.2.6 Executores e Thread Pools . . . . 16.3 Streams e Serializao . . . . . . . . . . . ca 16.3.1 I/O Streams . . . . . . . . . . . . 16.3.2 Serializao - Streams de Objetos . ca 16.4 Classes e Operaes de I/O . . . . . . . . co 16.5 Classes para manipulao de propriedades ca 17 Colees co 17.1 Interface 17.2 Interface 17.3 Interface 17.4 Interface 17.5 Interface Collection Set . . . . List . . . Map . . . Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18 JDBC - Java Database Connectivity 18.1 Conceitos Bsicos . . . . . . . . . . . a 18.2 Carregamento de drivers . . . . . . . 18.3 Conexo . . . . . . . . . . . . . . . . a 18.4 Statements . . . . . . . . . . . . . . 18.5 Prepared Statements . . . . . . . . . 18.6 Transao . . . . . . . . . . . . . . . ca 18.7 Informaes Complementares . . . . co 18.8 Exemplo Extra . . . . . . . . . . . . 19 A plataforma J2EE 19.1 Containers J2EE . . . . . . . . . . . 19.2 Clientes J2EE . . . . . . . . . . . . . 19.3 Um pouco mais sobre Servlets . . . . 19.3.1 Ciclo de Vida dos Servlets . . 19.3.2 Mantendo o estado do cliente
19.4 Um pouco mais sobre pginas JSP a 19.4.1 JSP vs. Servlets . . . . . . 19.5 Um pouco mais sobre EJBs . . . . 19.5.1 Ciclo de Vida dos EJBs . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
213 215 216 217
Desenvolvimento Web
220
20 Usabilidade 221 20.1 Denio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 ca 20.2 Princ pios da usabilidade . . . . . . . . . . . . . . . . . . . . . . . 222 20.3 Tcnicas de avaliao de usabilidade . . . . . . . . . . . . . . . . 223 e ca 21 Acessibilidade 21.1 Denio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ca 21.2 Princ pios da acessibilidade . . . . . . . . . . . . . . . . . . . . . 21.3 Tcnicas de avaliao de acessibilidade . . . . . . . . . . . . . . . e ca 22 Padres Web W3C o 23 XML 23.1 O que XML? . . . . . . . . . . . e 23.2 Caracter sticas do XML . . . . . . 23.3 Comparao entre XML e HTML . ca 23.4 Sintaxe bsica do XML . . . . . . a 23.5 Conjunto de tags . . . . . . . . . . 23.6 NameSpaces . . . . . . . . . . . . . 23.7 Gramtica de um documento XML a 23.8 Tecnologias XML . . . . . . . . . . 23.9 Benef cios da linguagem XML . . . 23.10Ferramentas de desenvolvimento . 24 XSLT 24.1 O que uma folha de estilo? . . e 24.2 Comparao entre o CSS e XSL . ca 24.3 O que o XSL? . . . . . . . . . . e 24.4 O que o XSLT? . . . . . . . . . e 24.5 Caracter sticas do XSLT . . . . . 24.6 Declarando um documento XSL . 24.7 Elemento <xsl:template> . . . . 24.8 Elemento <xsl:value-of> . . . . . 24.9 Elemento <xsl:for-each> . . . . . 24.10Elemento <xsl:sort> . . . . . . . 24.11Elemento <xsl:if> . . . . . . . . 24.12Elemento <xsl:choose> . . . . . 24.13Elemento <xsl:apply-templates> 24.14XSL no lado Cliente . . . . . . . 24.15XSL no lado Servidor . . . . . . 24.16Processadores XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 224 224 227 229 233 233 234 234 234 236 238 239 244 245 246 247 247 247 248 248 249 249 250 251 252 252 252 253 253 254 254 255
. . . . . . . . . . . . . . . .
25 Gerenciador de Conte do Web Zone/Plone u 25.1 Gesto de Contedo . . . . . . . . . . . . . . a u 25.2 Sistema de Gesto de Contedo . . . . . . . . a u 25.3 Zope . . . . . . . . . . . . . . . . . . . . . . . 25.4 Plone . . . . . . . . . . . . . . . . . . . . . . 26 Web Services 26.1 O que Web Services? e 26.2 SOAP . . . . . . . . . 26.3 WSDL . . . . . . . . . 26.4 UDDI . . . . . . . . . 26.5 Segurana . . . . . . . c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
256 256 257 258 260 263 263 266 267 269 269
VI
Redes de Comunicao ca
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
270
271 271 272 272 273 273 274 274 275 275 275 276 276 277 279 280 281 281 281 282 283 284
27 Tcnicas Bsicas de Comunicao e a ca 27.1 Base Terica da Comunicao de Dados . . . . . . . . . o ca 27.2 Taxa Mxima de Dados em um Canal . . . . . . . . . . a 27.3 Sinais Digitais Binrios . . . . . . . . . . . . . . . . . . a 27.4 Transmisso em Banda Base . . . . . . . . . . . . . . . . a 27.5 Classicao dos Sinais . . . . . . . . . . . . . . . . . . . ca 27.6 Tcnicas de Codicao de Linha . . . . . . . . . . . . . e ca 27.6.1 Codicao NRZ . . . . . . . . . . . . . . . . . . ca 27.6.2 Codicao RZ . . . . . . . . . . . . . . . . . . . ca 27.6.3 Codicao AMI (Alternate Mark Invertion) . . ca 27.6.4 Codicao HDB-3 (High Density Bipolar with ca Maximum Tolerance) . . . . . . . . . . . . . . . 27.6.5 Codicao Manchester . . . . . . . . . . . . . . ca 27.7 Modulao . . . . . . . . . . . . . . . . . . . . . . . . . ca 27.7.1 Modulao de Onda Cont ca nua . . . . . . . . . . . 27.7.2 Modulao de Pulsos . . . . . . . . . . . . . . . . ca 27.8 Tcnicas de Multiplexao . . . . . . . . . . . . . . . . . e ca 27.8.1 FDM - Frequency Division Multiplexing . . . . . 27.8.2 TDM - Time Division Multiplexing . . . . . . . . 27.8.3 OFDM . . . . . . . . . . . . . . . . . . . . . . . 27.8.4 WDM -Wavelength Division Multiplexing . . . . 27.9 Protocolos de Acesso Mltiplo . . . . . . . . . . . . . . . u
28 Topologias de Redes
29 Arquitetura de Redes 286 29.1 Organizao em Camadas . . . . . . . . . . . . . . . . . . . . . . 286 ca 30 Protocolos de Rede 30.1 ARP - Address Resolution Protocol . . . . . . 30.2 DHCP - Dynamic Host Conguration Protocol 30.3 DNS - Domain Name System . . . . . . . . . . 30.4 TCP - Transmission Control Protocol . . . . . 30.5 UDP - User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 287 287 289 291 293
30.6 HTTP - Hyper Text Transfer Protocol . . . . . 30.7 SMTP - Simple Mail Transfer Protocol . . . . . 30.8 POP3 - Post Oce Protocol Version 3 . . . . . 30.9 IMAP - Internet Mail Access Protocol . . . . . 30.10LDAP - LightWeight Directory Access Protocol 30.11SNMP - Simple Network Management Protocol 30.12FTP - File Transfer Protocol . . . . . . . . . . 30.13IP - Internet Protocol . . . . . . . . . . . . . . 30.14TELNET - TELetype NETwork . . . . . . . . 31 O Modelo de Referncia OSI e 32 Roteamento 32.1 Link State e Distance Vector . . . . . . . . . . 32.1.1 Vetor de Distncias vs. Estado do Link a 32.2 Protocolos de Roteamento . . . . . . . . . . . . 32.2.1 RIP - Routing Information Protocol . . 32.2.2 OSPF - Open Shortest Path First . . . 32.2.3 IGRP e EIGRP . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
294 299 301 303 305 305 306 310 311 314
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
316 317 319 320 320 320 321 322 322 323 324 326 326 326 327 328 328 329 329 333 334 335 336
33 Redes Ethernet 33.1 Protocolo CSMA/CD . . . . . . . . . . . . . . . . . . . . . . . . 33.2 Fast Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.3 Gigabit Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Cabeamento Estruturado 34.1 Par Tranado . . . . . . . . . . . . . . . . . . . . . c 34.1.1 Interferncias nos Cabos de Par Tranado . e c 34.2 Categorias 5e . . . . . . . . . . . . . . . . . . . . . 34.3 Categoria 6 . . . . . . . . . . . . . . . . . . . . . . 34.4 Categoria 5e vs. Categoria 6 . . . . . . . . . . . . 34.5 Cabeao Estruturada Norma EIA/TIA 568 . . . ca 34.5.1 Sistemas de Cabeamento Estruturado . . . 34.6 Desempenho do Hardware e Meios de Transmisso a 34.6.1 Cabeamento UTP . . . . . . . . . . . . . . 34.6.2 Fibra Optica . . . . . . . . . . . . . . . . . 34.7 Cdigo de Cores para Sistemas de Cabeo UTP . o ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35 Redes sem o 337 35.1 O padro IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 337 a 35.1.1 CSMA/CA . . . . . . . . . . . . . . . . . . . . . . . . . . 338 35.1.2 Formato do Quadro 802.11 . . . . . . . . . . . . . . . . . 339 36 Elementos de Interconexo de Redes a 36.1 Repetidores . . . . . . . . . . . . . . 36.2 Hubs . . . . . . . . . . . . . . . . . . 36.3 Switches . . . . . . . . . . . . . . . . 36.4 Bridges . . . . . . . . . . . . . . . . 36.5 Roteadores . . . . . . . . . . . . . . 36.6 Gateways . . . . . . . . . . . . . . . de . . . . . . . . . . . . Computadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 340 340 341 342 342 343
37 Redes Multim dia 37.1 Qualidade de Servio . . . . . . . . . . . . . . . . . . . . . . . . . c 37.2 Servios Integrados - IntServ . . . . . . . . . . . . . . . . . . . . c 37.3 Servios Diferenciados - DiServ . . . . . . . . . . . . . . . . . . c 38 Redes X.25 e Frame Relay 38.1 X.25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38.2 Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38.2.1 Estrutura do Frame . . . . . . . . . . . . . . . . . . . . . 38.2.2 Envio de um datagrama IP de Ethernet para Frame Relay e Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . 38.3 Interligao de Redes LAN . . . . . . . . . . . . . . . . . . . . . ca 38.3.1 Voz sobre Frame Relay (VoFR) . . . . . . . . . . . . . . . 38.3.2 Interao entre Frame Relay e ATM . . . . . . . . . . . . ca 38.3.3 CIR (Taxa de Informao Comprometida) . . . . . . . . . ca
344 344 346 347 348 348 348 349 350 351 351 352 352
39 Redes Virtuais Locais 354 39.1 VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 39.1.1 Denio . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 ca 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 41.1 Viso geral . . . . . . . . . . . . . . . . . . . . a 41.2 Comparao entre a arquitetura OSI e TCP/IP ca 41.3 Camada F sica (host/rede) . . . . . . . . . . . 41.4 Camada de Inter-Rede . . . . . . . . . . . . . . 41.5 Camada de Transporte . . . . . . . . . . . . . . 41.6 Camada de Aplicao . . . . . . . . . . . . . . ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 360 360 361 361 362 362
42 Camada de Aplicao ca 364 42.1 Proxy Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
VII
Gerncia de Redes e
366
43 O protocolo SNMP 367 43.1 Management Information Base . . . . . . . . . . . . . . . . . . . 368
VIII
Segurana da Informao c ca
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
370
371 371 372 372 373 373
44 Pol ticas de Segurana de Informao c ca 44.1 Pol ticas de Segurana . . . . . . . . . c 44.2 Projeto de Segurana . . . . . . . . . . c 44.3 Plano de Segurana . . . . . . . . . . . c 44.4 Normas de Segurana . . . . . . . . . c 44.4.1 ISO/IEC 17799 . . . . . . . . . 9
44.4.2 Fam ISO 27000 . . . . . lia 44.4.3 Diferenas entre a ISO/IEC c 44.5 Procedimentos de Segurana . . . . c 44.6 Arquitetura de Segurana . . . . . c 44.7 Classicao de Informaes . . . . ca co
. . . . . . . . . . . . 17799 e a ISO 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
375 376 376 377 377
45 Segurana F c sica e Lgica o 379 45.1 Segurana F c sica . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 45.2 Segurana Lgica . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 c o 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 V rus e Ataques 386 47.1 Estratgias de combate ` pragas eletrnicas . . . . . . . . . . . . 388 e a o 47.1.1 Antiv rus . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 48 Princ pios de Criptograa 48.1 Tipos de Criptograa . . . . . . . . . . 48.2 Algoritmos de Criptograa Simtricos . e 48.3 Algoritmos de Criptograa Assimtricos e 48.4 Tcnicas de Quebra de Criptograa . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 391 392 393 394
49 Autenticao ca 49.1 Autenticao de Mensagens . . . . . . . . . . . . . ca 49.2 Protocolos de Autenticao . . . . . . . . . . . . . ca 49.2.1 Mtodos de Autenticao . . . . . . . . . . e ca 49.2.2 Autenticao baseada em uma chave secreta ca 49.3 Certicado Digital . . . . . . . . . . . . . . . . . . 50 Segurana em diversas camadas c 50.1 Secure Sockets Layer . . . . . . . . . . . 50.2 IPSec . . . . . . . . . . . . . . . . . . . 50.3 Virtual Private Network (VPN) . . . . . 50.4 Filtragem de Pacotes e Firewalls . . . . 50.4.1 Regras iptables - Exemplo 1 . . . 50.4.2 Regras iptables - Exemplo 2 . . . 50.4.3 Firewall Stateful . . . . . . . . . 50.4.4 Application Gateway . . . . . . . 50.4.5 Arquitetura de rewall e DMZ . 50.5 Sistemas de Deteco de Intruso (IDS) ca a 50.6 Segurana em Redes Wireless 802.11 . . c 50.6.1 WEP . . . . . . . . . . . . . . . 50.7 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
395 . . . . . . . . 395 . . . . . . . . 396 . . . . . . . . 396 compartilhada396 . . . . . . . . 397 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 399 400 401 403 405 405 406 407 407 409 409 409 410
10
IX
Alta Disponibilidade
411
51 Solues de Armazenamento RAID, SAN e NAS co 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 (Redundncia de P+Q) . . . . . . . . . . . . . . 419 a 51.1.8 Tipos H bridos . . . . . . . . . . . . . . . . . . . . . . . . 419 51.1.9 Comparativo de Desempenho entre as diversas conguraes co 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 52.0.1 Princ pios de um Cluster . . . . 52.0.2 Abstraes em um Cluster . . . . co 52.0.3 Arquitetura de um Cluster . . . 52.0.4 Cluster X Sistemas Distribu dos 52.0.5 Cluster de Alta Disponibilidade . 52.0.6 Cluster de Alto Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 427 428 429 430 431 433 436 436 436 437 437 438 438 439 439
53 Balanceamento de Carga 53.1 Balanceamento de armazenamento (storage) . 53.2 Balanceamento de rede . . . . . . . . . . . . . 53.2.1 NAT . . . . . . . . . . . . . . . . . . . 53.2.2 IP Tunneling . . . . . . . . . . . . . . 53.2.3 Direct Routing . . . . . . . . . . . . . 53.3 Algoritmos de balanceamento . . . . . . . . . 53.4 Balanceamento de CPU . . . . . . . . . . . . 53.4.1 Sistema de processamento distribu do
Sistemas Operacionais
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
442
443 443 443 445 445 446 446 446 447
54 Ambiente Microsoft Windows 2000/2003 54.1 DHCP - Dynamic Host Conguration Protocol . . 54.1.1 Processo de Instalao/Congurao . . . . ca ca 54.1.2 Integrao do DHCP com o DNS . . . . . . ca 54.1.3 APIPA - Automatic Private IP Addressing 54.1.4 Comandos ipcong Relacionados ao DHCP 54.1.5 Regra 80/20 . . . . . . . . . . . . . . . . 54.2 DNS - Domain Name System . . . . . . . . . . . . 54.2.1 Processo de Instalao/Congurao . . . . ca ca
11
54.2.2 54.2.3 54.2.4 54.2.5 54.2.6 54.2.7 54.3 Active 54.3.1 54.3.2
Segurana de Acesso . . . . . . . . . . . . . . . . . . . . . c Integrao do DNS com o Active Directory . . . . . . . . ca Servidor DNS somente Cache . . . . . . . . . . . . . . . . Arquivo Hosts . . . . . . . . . . . . . . . . . . . . . . . . Distribuio de Carga . . . . . . . . . . . . . . . . . . . . ca Comando ipcong/dnscmd Relacionadas ao DNS . . . . . Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . Tipos de Servidores . . . . . . . . . . . . . . . . . . . . . Denies de Floresta, Dom co nio, Site e Unidade Organizacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.3.3 Recursos do Active Directory . . . . . . . . . . . . . . . . 54.3.4 Segurana com o Active Directory . . . . . . . . . . . . . c 54.3.5 Ferramentas de Controle . . . . . . . . . . . . . . . . . . . 54.4 IIS - Internet Information Services . . . . . . . . . . . . . . . . . 54.4.1 IIS versus Apache HTTP Server . . . . . . . . . . . . . . 54.4.2 Principais Componentes do IIS . . . . . . . . . . . . . . . 54.4.3 Principais Recursos do IIS . . . . . . . . . . . . . . . . . . 54.4.4 Principais Diferenas entre IIS4, IIS5 e IIS6 . . . . . . . . c 54.5 Terminal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.5.1 Principais Benef cios . . . . . . . . . . . . . . . . . . . . . 54.5.2 Protocolos de Comunicao . . . . . . . . . . . . . . . . . ca 54.5.3 Licenas . . . . . . . . . . . . . . . . . . . . . . . . . . . . c
449 449 451 451 451 451 452 453 453 454 455 456 456 456 459 460 461 461 462 463 464
XI
Banco de Dados
465
466
55 Conceitos Bsicos a
56 Abordagem Relacional 468 56.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 56.2 Esquemas e Restries de Integridade . . . . . . . . . . . . . . . 468 co 57 Modelagem Entidade Relacionamento 57.1 Conceitos . . . . . . . . . . . . . . . . . . . . . 57.2 Cardinalidade . . . . . . . . . . . . . . . . . . . 57.3 Representao Grca . . . . . . . . . . . . . . ca a 57.4 Recursos do Modelo Entidade Relacionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 470 471 471 471
58 Normalizao ca 473 58.1 Aspectos desejveis em um bom projeto . . . . . . . . . . . . . . 473 a 58.2 Forma normal de Boyce-Codd . . . . . . . . . . . . . . . . . . . . 473 58.3 Terceira forma normal . . . . . . . . . . . . . . . . . . . . . . . . 474 59 Transformao do Modelo Conceitual ca 60 Linguagem SQL 60.1 Criao de tabela . . . . ca 60.2 Consultas . . . . . . . . 60.3 Funes de agregao . . co ca 60.4 Atualizaes e excluses co o 60.5 Vises . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 476 476 476 477 478 479
12
60.6 Chaves estrangeiras . . . . . . . . . . . . . . . . . . . . . . . . . . 479 61 Conceitos de Datawarehousing e Bussiness Inteligence 61.1 Banco de Dados Multidimensionais . . . . . . . . . . . . . 61.1.1 Modelagem Multidimensional . . . . . . . . . . . . 61.2 Datawarehousing . . . . . . . . . . . . . . . . . . . . . . . 61.3 OLTP, OLAP, MOLAP, ROLAP e HOLAP . . . . . . . . 61.4 Outros conceitos importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 480 481 483 485 487
XII
Administrao de Bancos de Dados Relacionais 489 ca

490 492 494
62 Gerncia de Transaes e co 63 Controle de Concorrncia e 64 Gerncia de Desempenho e
XIII
Oracle e Microsoft SQL Server

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
497
498 498 498 499 499 499 500 501 501 501 502 502 503 503 504 504 505 506 506 506 507 507 507
65 Administrao de Bancos de Dados Oracle ca 65.1 Arquitetura de um Servidor Oracle . . . . . . . . 65.1.1 Estruturas em memria . . . . . . . . . . o 65.1.2 Processos server . . . . . . . . . . . . . . 65.1.3 Processos user . . . . . . . . . . . . . . . 65.1.4 Processos em Background . . . . . . . . . 65.1.5 Arquivos . . . . . . . . . . . . . . . . . . 65.2 Arquitetura Oracle de Armazenamento de Dados 65.3 Tratamento de Transaes no Oracle . . . . . . . co 65.3.1 Gerenciamento do Redo Log . . . . . . . . 65.3.2 Checkpoints . . . . . . . . . . . . . . . . . 65.3.3 Segmentos de rollback . . . . . . . . . . . 65.3.4 Consistncia de leitura . . . . . . . . . . . e 65.4 Congurao do Servidor . . . . . . . . . . . . . ca 65.5 Tipos de Usurios Oracle . . . . . . . . . . . . . a 65.5.1 Administradores de banco de dados . . . 65.5.2 Outros ppeis . . . . . . . . . . . . . . . . a
66 Administrao de Bancos de Dados SQL Server ca 66.1 Arquitetura de um Servidor SQL Server . . . . . . . . 66.1.1 Catlogos de sistema . . . . . . . . . . . . . . . a 66.1.2 Processos em background . . . . . . . . . . . . 66.2 Arquitetura SQL Server de Armazenamento de Dados 66.3 Tratamento de Transaes no SQL Server . . . . . . . co
XIV
ITIL
509
67 Suporte a Servios c 510 67.1 Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
13
67.2
67.3
67.4
67.5
67.6
67.1.1 Objetivos . . . . . . . . . . 67.1.2 Responsabilidades . . . . . 67.1.3 Vrios Tipos de Central . . a Gerenciamento de Incidentes . . . 67.2.1 Objetivos . . . . . . . . . . 67.2.2 Atividades do Processo . . 67.2.3 Papis e Responsabilidades e Gerenciamento de Problemas . . . 67.3.1 Objetivos . . . . . . . . . . 67.3.2 Denies Importantes . . . co 67.3.3 Atividades do Processo . . 67.3.4 Papis e Responsabilidades e Gerenciamento de Congurao . . ca 67.4.1 Objetivos . . . . . . . . . . 67.4.2 Atividades . . . . . . . . . . 67.4.3 Papis e Responsabilidades e Gerenciamento de Mudanas . . . c 67.5.1 Objetivos . . . . . . . . . . 67.5.2 Responsabilidades . . . . . 67.5.3 Denies Importantes . . . co Gerenciamento de Liberao . . . . ca 67.6.1 Objetivo . . . . . . . . . . . 67.6.2 Atividades do Processo . . 67.6.3 Denies Importantes . . . co 67.6.4 Papis e Responsabilidades e
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
510 510 511 511 511 511 512 512 512 513 513 513 514 514 514 515 515 515 515 515 516 516 516 517 517 518 518 518 519 519 519 519 520 521 521 521 522 522 522 523 523 523 524
68 Entrega de Servios c 68.1 Gerenciamento do N de Servio vel c 68.1.1 Objetivos . . . . . . . . . . 68.2 Gerenciamento Financeiro . . . . . 68.2.1 Objetivos . . . . . . . . . . 68.2.2 Responsabilidades . . . . . 68.2.3 Atividades do Processo . . 68.2.4 Elementos de Custo . . . . 68.3 Gerenciamento da Capacidade . . 68.3.1 Objetivos . . . . . . . . . . 68.3.2 Atividades . . . . . . . . . . 68.4 Gerenciamento de Disponibilidade 68.4.1 Objetivos . . . . . . . . . . 68.4.2 Ciclo de vida do incidente . 68.5 Gerenciamento de Continuidade . . 68.5.1 Objetivos . . . . . . . . . . 68.5.2 Estgios . . . . . . . . . . . a 68.5.3 Tipos de Continuidade . . .
XV
Gerncia de Projetos segundo PMBOK e
525
69 Gerenciamento de Escopo 526 69.1 WBS e Denio do Escopo . . . . . . . . . . . . . . . . . . . . . 526 ca
14
70 Gerenciamento de Recursos Humanos 70.1 Estruturas Organizacionais . . . . . . 70.1.1 Organizao Funcional . . . . . ca 70.1.2 Organizao por Projeto . . . . ca 70.1.3 Organizao Matricial . . . . . ca 70.2 Planejamento Organizacional . . . . . 70.3 Desenvolvimento da Equipe . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
528 528 528 529 530 531 531 534 534 535 535 536 536 536 537 537 537 538 538
71 Gerenciamento do Tempo 71.1 Tcnicas de Desenvolvimento do Cronograma e 71.1.1 Anlise Matemtica . . . . . . . . . . a a 71.1.2 Compresso do Cronograma . . . . . . a 71.1.3 Simulao . . . . . . . . . . . . . . . . ca 71.1.4 Heur stica do nivelamento de recursos 71.1.5 Estrutura de Codicao . . . . . . . ca 72 Gerenciamento de Custo 72.1 Tcnicas de Estimativas de Custos e 72.1.1 Estimativas Anlogas . . . a 72.1.2 Modelagem Paramtrica . . e 72.1.3 Estimativa bottom-up . . . . . . . . . . . . . . . . . . . . . . . . . . .
73 Gerenciamento de Riscos 539 73.1 Anlise Qualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . 539 a 73.2 Anlise Quantitativa de Riscos . . . . . . . . . . . . . . . . . . . 540 a 74 Gerenciamento de Qualidade 74.1 Tcnicas de Planejamento da Qualidade e 74.1.1 Anlise Custo/Benef a cio . . . . . 74.1.2 Benchmarking . . . . . . . . . . 74.1.3 Fluxograma . . . . . . . . . . . . 74.1.4 Elaborao de Experimentos . . ca 74.1.5 Custo da Qualidade . . . . . . . 74.2 Tcnicas de Controle da Qualidade . . . e 74.2.1 Grcos de Controle . . . . . . . a 74.2.2 Diagramas de Pareto . . . . . . . 74.2.3 Diagramas de Disperso . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 542 542 543 543 543 544 544 545 545 546
75 Gerenciamento da Comunicao ca 547 75.1 Um mais sobre Planejamento da Comunicao . . . . . . . . . . 547 ca 76 Gerenciamento das Aquisies co 548 76.1 Um pouco mais sobre Planejamento de Aquisies . . . . . . . . 548 co 77 Gerenciamento da Integrao ca 550 77.1 Ferramentas de Apoio ` Integrao . . . . . . . . . . . . . . . . . 550 a ca 78 Sobre os Ciclos do Projeto e Processos de Gerenciamento 551
15
Parte I
Fundamentos de Computao ca
16
Cap tulo 1
Arquitetura e Organizao ca de Computadores

1.1 Conceitos Bsicos a
Dois conceitos fundamentais no estudo dos sistemas de computao so o de ca a Arquitetura e Organizao de computadores. O termo arquitetura refere-se aos ca atributos do ponto de vista do programador, e portanto, tm impacto direto e sobre sobre a execuo lgica de um programa. O termo organizao, refere-se ca o ca a `s unidades operacionais e suas interconexes. Desta forma, uma mesma aro quitetura pode ser implementadas por meio de diferentes organizaes. co As funes bsicas de um computador so o processamento de dados, arco a a mazenamento de dados, transferncia de dados e controle. Para desempenhar e essas funes o computador precisa executar um conjunto de instrues (proco co grama). Os computadores que conhecemos so baseados no conceito de proa grama armazenado, introduzido por Von-Neuman. As instrues do programa co e os dados so armazenados em uma memria, de forma que a alterao de um a o ca programa consiste na alteraao de um endereo de memria. c c o O ciclo de execuo de cada uma das instrues de um programa divica co e dido nos seguintes estados: (i)Calculo do Endereo de Instruo; (ii)Busca da c ca Instruo (Instruction Fetch); (iii) Decodicao da Instruo; (iv)Clculo do ca ca ca a Endereo do Operando; (v)Busca do Operando (Operand Fetch); (vi)Execuo c ca da Operao; (vii)Armazenamento do Resultado. No entanto, os computadores ca modernos utilizam o conceito de interrupo para diminuir o tempo de ociosica dade dos processadores, o ciclo de execuo das instrues ganham mais alguns ca co estados. As classes de interrupes mais comuns so interrupes de software, co a co de relgio, de E/S e de falha de hardware. o A estrutura bsica de um computador composta pelos seguintes compoa e nentes: (i)Unidade Central de Processamento(CPU); (ii)Memria Principal; o 17
(iii)Dispositivos de E/S; (iv)Sistemas de Interconexo. a Esses componentes tambm possuem suas subdivises. A CPU por exemplo e o se subdivide em: Unidade de Controle, Unidade Lgica e Aritmtica (ALU), o e Registradores e por m as Interconexes da CPU. Cada um desses componentes o er melhor descrito posteriormente. Para interconectar dois ou mais dispositivos a em um sistema so utilizados os chamados barramentos. Os barramentos so a a compostos por linhas que podem ser de Dados, Endereo ou Controle. Os c barramentos de controle podem ser utilizados por exemplo para controlar direito de leitura ou escrita em memria ou E/S, interrupes, conrmaes, relgio o co co o e reset. O projeto dos barramentos que compe um sistema so de grande o a importncia no desempenho do sistema. Questes importantes no projeto de a o barramentos so: a (i)Tipo - dedicado ou multiplexado; (ii)Mtodo de Arbitrao - Centralizado ou Distribu e ca do; (iii)Temporizao - S ca ncrona ou Ass ncrona; (iv)Largura - nmero de linhas; u (v) Tipo de Transferncia - leitura, escrita, leitura/modicao/escrita, e ca escrita/leitura, em bloco. Para aumentar o desempenho do sistema, os barramentos so organizados de a forma hierrquica, de forma isolar o trfego de dados entre CPU e memria do a a o trfego proveniente de operaes de E/S. Os chamados barramentos de expanso a co a proporcionam maior exibilidade ao sistema (ex: SCSI), enquanto os barramentos de alta velocidade so utilizados para dispositivos de alta capacidade (ex: a FireWire).
1.2
Estrutura e Funcionamento da CPU
Os principais elementos da CPU so a Unidade de Controle , a Unidade Lgica a o e Aritmtica (ULA) e os Registradores. Esses elementos se conectam internae mente atravs do barramento interno da CPU. e
A CPU se comunica com o mundo externo atravs dos barramentos do sise tema. Ao longo da execuo de um programa, os barramentos constituem os ca chamados caminho dos dados. No topo da organizao hierrquica de memria ca a o em um sistema se encontram os registradores. Esses se dividem em dois tipos: Registradores vis veis ao Usurio e Registradores de Controle e de Estado. a Os registradores vis veis ao usurio so aqueles que podem ser referenciados a a pela linguagem de montagem. Eles podem ser registradores de dados, endereo c ou ento de propsito geral. Os registradores de Controle e de Estado so utia o a lizados para controlar a operao da CPU. Na maioria das vezes no so vis ca a a veis aos usurios. Exemplos de registradores de Controle e de Estado so o Program a a
18
Counter (PC), Instruction Register (IR), Memory Address Register (MAR), Memory Buer Register (MBR), Program Status Word (PSW), Stack Pointer (SI), Page Table Base Register (PTBR), Page Table Base Limit (PTBL). A seqncia de eventos ao longo de um ciclo de instruo depende do projeto ue ca da CPU, no entanto, em termos gerais, pode-se indicar o que acontece em nos subciclos de busca, indireto e interrupo. O ciclo de execuo depende do ca ca cdigo da operao que ser executada. A gura 1.1 mostra o diagrama de o ca a transio de estados do ciclo de instruo. ca ca
Figura 1.1: Transio de Estados do Ciclo de Instruo ca ca Durante o ciclo de busca, o contador de programa contm o endereo da e c prxima instruo a ser buscada na memria. Esse endereo movido para o o ca o c e registrador MAR e a unidade de controle requisita uma leitura na memria. O o resultado da leitura e colocado no registrador MBR, que em seguida copiado e para o registrador IR. Enquanto isso o PC incrementado de 1 para preparar e a busca da prxima instruo. O uxo de dados do ciclo de busca mostrado o ca e na gura 1.2. Ao m do ciclo de busca, o unidade de controle examina se a instruo ca especica algum operando com endereamento indireto. Os n bits mais a direita c de MBR so colocados em MAR, e ento a unidade de controle requisita uma a a leitura a memria para carregar o valor do operando para MBR. O uxo de o dados do ciclo de indireto mostrado na gura 1.3. e No ciclo de interrupo, o contedo do registrador PC dever ser salvo, para ca u que mais tarde a CPU possa retornar sua atividade normal depois de processar a interrupo. O contedo do PC transferido para MBR. A endereo de ca u e c memria reservado para guardar o valor de PC (ex: topo da pilha) carregado o e para MAR, e ento a unidade de controle solicita uma escrita na memria. Por a o m o PC carregado com o endereo da rotina de interrupo, para que o no e c ca prximo ciclo de instruo seja feita a busca da instruo apropriada. A gura o ca ca 1.4 mostra o uxo de dados do ciclo de interrupo. ca
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 Interrupo ca
1.2.1
Pipelines
Como pudemos ver, um ciclo de instruo pode subdividido em etapas menores. ca Uma diviso comum a baseada nos ciclos de busca, indireto, execuo e intera e ca rupo. A idia da tcnica de pipeline trabalhar as diversas etapas do ciclo ca e e e de instruo de forma paralela, e no de forma serial, de forma aumentar o ca a
20
desempenho da CPU. A tcnica de pipeline pode ser descrita genericamente como uma estratgia e e de aceitar novas entradas em uma extremidade sem que as entradas prvias e tenha aparecido como sa das na outra extremidade. Imaginemos um esquema em que o ciclo de instruo subdividido em 2 etapas que so a busca da inca e a struo e a execuo. Enquanto uma instruo est sendo executada, a prxima ca ca ca a o instruo pode estar sendo buscada. Este esquema congura um pipeline de 2 ca estgios, e a tcnica utilizada a de busca antecipada de instruo (Instruction a e e ca Prefetch ou Fetch Overlap). Embora possa ser obtido um ganho de desempenho, o pipeline de 2 estgios ainda muito fraco para lidar com instrues de desvio, a e co nas quais a busca da prxima instruo depende do resultado da execuo da o ca ca instruo corrente. ca Portanto, uma subdiviso do ciclo de instruo em um nmero maior de a ca u estgios pode proporcionar maior desempenho. Imaginemos o ciclo de instruo a ca como sendo composto dos seguintes estgios: a (1)BI - Busca da Instruo; ca (2)DI - Decodicao da Instruo; ca ca (3)CO - Calculo dos Endereos dos Operandos; c (4)BO - Busca dos Operandos; (5)EI - Execuo da instruo; ca ca (6)EO - Escrita do Operando. Essa subdiviso busca fazer com que os tempos gastos em cada um dos 6 a estgios seja parecido. Se os 6 estgios pudessem ser executados em paralelo, o a a desempenho seria aproximadamente 6 vezes maior. No entanto, podem existir conitos de acesso ` memria por parte dos a o estgios e nem todas as instrues possuem os seis estgios. Somam-se ` esses a co a a dois problemas, a existncia de instrues de desvios, principais inimigas da e co tcnica de pipeline. Para lidar com os problemas introduzidos pelas instrues e co de desvio so utilizadas tcnicas como: a e
Mltiplos Fluxos (duplicao de estgios iniciais); u ca a Busca Antecipada de Instruo-Alvo de Desvio; ca Memria de Lao de Repetio (loop buer ); o c ca Previso de Desvio baseadas no opcode; a Previso de Desvio baseadas em histrico (BTB - Branch Target Buer, a o tambm conhecida como BHT - Branch History Table). e As guras 1.5 e 1.6 mostram os diagramas de tempo para o pipeline de instrues com e sem instrues de desvio. co co
21
Figura 1.5: Diagrama do Tempo para Pipeline de Instrues co
Figura 1.6: Efeito do desvio condicional no Pipeline de Instrues co
1.3
Conjunto de Instrues co
A operao da CPU determinada pelo conjunto de instrues que ela executa. ca e co So as chamadas instrues de mquina. A coleo de instrues que uma CPU a co a ca co pode executar chamada Conjunto de Instrues. O conjunto de instrues e co co deve ser suciente para traduzir programas escritos em uma linguagem de alto n vel para a linguagem de mquina. Os principais elementos e uma instruo a ca so: a (i)Cdigo da operao (opcode): especica a operao a ser efetuada; o ca ca (ii)Referncia ` Operando Fonte: indica as entradas para a operao; e a ca (iii)Referncia ao operando Destino: A operao pode produzir um resule ca tado; (iv)Endereo da prxima instruo: Pode ser indicado implicitamente (ex: c o ca registrador PC). 22
Os operandos fonte e destino podem estar localizados em memria (principal o ou virtual), em algum registrador, ou em algum dispositivo de E/S. Cada instruo de um computador representada internamente como um ca e conjunto de bits. A instruo dividida em campos correspondentes aos eleca e mentos da instruo. O papel da CPU e ler a instruo, extrair informao de ca ca ca cada um dos campos e efetuar a operao. Devido `s diculdades de se lidar ca a com a representao binria, utilizada uma espcie de notao simblica para ca a e e ca o representar as instrues de mquina. Os cdigos das operaes so representaco a o co a dos por mnemnicos. (ex: ADD, SUB, MPY, DIV, LOAD, STOR). O mesmo o ocorre para os operandos. Um conjunto de instrues pode apresentar mais de co um formato de instruo. ca As instrues podem ser classicadas em: co (i)Processamento de Dados: instrues lgicas e aritmticas; co o e (ii)Armazenamento de dados: instrues de memria; co o (iii)Movimentao: instrues de E/S; ca co (iv)Controle: instrues de teste e desvio. co No projeto do conjunto de instrues as questes mais relevantes so o co o a repertrio de operaes, os tipos de dados, o formato e tamanho das instrues, o co co os registradores acess veis, e os modos de endereamento. As classes de dados c sobre as quais as instrues de mquina operam so endereos, nmeros (ex: co a a c u ponto xo, ponto utuante, decimal), caracteres (ex: ASCII e EBCDIC) e dados lgicos. o Os tipos de operaes mais comuns so: co a (i)Transferncia de Dados: mov,push/pop,xlat,in/out; e (ii)Aritmticas: add,sub,mul,idiv; e (iii)Lgicas: and,or,shl/shr; o (iv)Converso de Tipos: jmp,call,loop,int/into; a (vi)Controle do Sistema: hlt,wait;
(vii)Transferncia de Controle: blt,bgt,beq,call,jmp. e Nas operaes de salto e desvio, importante conhecer cada um dos cdigos co e o de condio envolvidos. (ex: Vai-Um, Zero, Paridade, Sinal, Overow) Na imca plementao das chamadas de procedimento importante ressaltar a utilizao ca e ca 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 funes. A execuo de um programa consiste co ca de uma seqncia de ciclos de instruo. Um ciclo de instruo pode ser subue ca ca dividido em quatro subciclos que so busca, indireto, execuo e interrupo. a ca ca Somente os ciclos de busca e execuo esto presentes em todos os ciclos de ca a instruo. Cada subciclo, por sua vez, composto por microoperaes. ca e co Os quatro registradores bsicos da unidade de controle so: a a PC (Program Counter ): Mantm o endereo da prxima instruo a ser e c o ca buscada na memria; o MAR (Memory Address Register ): Especica endereo de memoria para c uma operao de leitura ou escrita; ca MBR (Memory Buer Register ): Conectado ao barramento do sistema. Contm um valor a ser armazenado na memria ou o ultimo valor dela e o lido; IR (Instruction Register ): Mantm a ultima instruo buscada na memria. e ca o O ciclo de busca ocorre no in cio de cada ciclo de instruo, fazendo com ca que a instruo seja obtida na memria no endereo indicado pelo registrador ca o c PC, e armazenada no registrador IR. Uma vez completada essa etapa, pode ser necessrio que se busquem operandos para a instruo. Isso realizado no ciclo a ca e de indireto. Aps o termino do ciclo de execuo, feita uma checagem para o ca e determinar se ocorreu alguma interrupo, e neste caso o contedo de PC ca u e salvo em memria e PC carregado com um endereo da rotina de interrupo o e c ca apropriada. Os ciclos de busca, indireto e de interrupo envolvem um nmero ca u pequeno e xo de microoperaes. Isso no ocorre nos ciclos de execuo. Em co a ca uma mquina com N cdigos de instruo podem existir N diferentes seqncias a o ca ue de microoperaes para o ciclo de execuo. co ca Todas as microoperaes caem em uma das seguintes categorias: co (i)Transferncia de dados entre registradores; e
(ii)Transferncia de dados entre registrador e interface externa (barrae mento); (iii)Transferncia de dados de interface externa para registrador; e (iv)Execuo de operaes lgicas e aritmticas, usando registradores como ca co o e entrada e sa da. Portanto, a unidade de controle desempenha duas tarefas bsicas que so o a a seqenciamento e a execuo das microoperaes. A base para o funcionamento u ca co da unidade de controle so os sinais de controle, que constituem as entradas e a sa das.
24
As unidades de controle podem ser implementadas tanto em hardware quanto em software (Microprogramao). A implementao baseada em microproca ca gramao mais simples e tambm mais barata do que as implementaes em ca e e co hardware. As implementaes em hardware envolvem a criao de uma lgica co ca o complexa para sequenciamento das microoperaes, o que a torna mais cara. co No entanto, mais eciente dos que as implementaes basadas em microproe co gramao. As arquiteturas CISC geralmente utilizam unidades de controle mica croprogramadas, devido ao grande nmero de instrues e sua complexidade. J u co a as arquiteturas RISC, geralmente utilizam implementaes baseadas em hardco ware uma vez que o nmero de instrues reduzido e de baixa complexidade. u co e As tcnicas de microprogramao tambm podem ser aplicadas em eme ca e ulaes, permitindo que mquinas rodem programas escritos originalmente para co a outras mquinas. Microprogramas podem conferir maior desempenho ao sisa tema operacional se forem utilizados na implementao de certas primitivas. ca Alm disso, as tcnicas de microprogramao podem ser utilizadas na implee e ca mentao de dispositivos de propsito especial, por exemplo uma placa de rede ca o (rmware).
1.5
Modos de Endereamento c
Os modos de endereamento esto relacionados com a forma utilizada para c a especicar o valor ou endereo de um operando de uma instruo. Questes imc ca o portantes na escolha do modo de endereamento so a quantidade de posies de c a co memria endereveis, exibilidade de endereamento, nmero de referncias a o ca c u e memria feitas pela instruo e complexidade do clculo do endereo. Em geral, o ca a c as arquitetura no oferecem s um modo de endereamento, mas sim um cona o c junto de modos. Por este motivo, necessrio que exista uma forma de se e a identicar qual o modo de endereamento que se est utilizando. Isso feito c a e atravs do campo de modo de endereamento, que consiste em um subconjunto e c dos bits de uma instruo. ca Imediato: o valor do operando especicado diretamente na instruo. e ca Sua principal vantagem no requer acesso a memria para obter o e a o operando. A desvantagem que esse modo impe uma limitao no e o ca tamanho do operando;
Direto: o campo de endereo contem o endereo efetivo do operando na c c memria. Requer portanto apenas um acesso para determinar o valor do o operando. Sua limitao fornecer um espao de endereamento limitado; ca e c c Indireto: o campo de endereo aponta para uma posio de memria que c ca o contem o endereo de memria do operando. Sua principal desvantagem c o a necessidade de dois acessos ` memria. A vantagem em relao ao e a o ca modo de endereamento direto o aumento do espao de endereamento, c e c c que passa a ser igual 2n onde n o tamanho da palavra; e Registrador : semelhante ao modo direto, no entanto o modo de endereo e c se refere a um registrador e no ` uma posio de memria. Geralmente a a ca o e
25
composto por 3 ou 4 bits, o que permite referenciar de 8 a 16 registradores de propsito geral. Suas vantagens so o tamanho pequeno do campo de o a endereo e no necessidade de se acessar a memria. Sua desvantagem c a o e o espao de endereamento limitado pelo nmero de registradores; c c u Indireto via Registrador : semelhante ao modo de endereamento indireto. c O campo de endereo aponta para o registrado que contem a posio de c ca memria do operando. Sua vantagem a necessidade de um unico acesso o e a memria, um a menos que no modo indireto; o Deslocamento: requer que uma instruo tenha dois campos de endereo, ca c com pelo menos um expl cito. O valor de um dos campos usado diree tamente (valor = A). O outro campo baseado no cdigo da operao, e e o ca especica um registrador cujo contedo adicionado a A, para produzir o u e endereo efetivo. Os trs modos de endereamento por deslocamento so c e c a relativo, via registrador-base e indexado; Pilha: A pilha um bloco reservado de posies em memria. Elementos e co o podem ser colocados e removidos do topo da pilha. o apontador do topo da pilha (stack-pointer ) mantido em um registrador. Portanto, de fato, e referncias a pilha so feitas por endereamento indireto via registrador. e a c
1.6
Organizao de Memria ca o
Um sistema de computador t pico equipado com uma hierarquia de subsise temas de memria, algumas internas (diretamente acess o veis pelo processador, como registradores, cache e memria principal) e outras externas (acess o veis pelo processador por meio de um mdulo de E/S, como disco e cdrom). As o caracter sticas fundamentais de um sistema de memria so: o a 1. Localizao - processador, interna (principal), externa (secundria); ca a 2. Capacidade - tamanho da palavra e nmero da palavra; u 3. Unidade de Transferncia - palavra, bloco; e 4. Mtodo de Acesso - seqencial, direto, aleatrio, associativo; e u o 5. Desempenho - tempo de acesso, tempo de ciclo e taxa de transferncia; e
6. Tecnologia - semicondutores, magntica, ptica, magneto-ptico; e o o 7. Caracter sticas F sicas - voltil/no voltil, apagvel/no apagvel. a a a a a a Quanto ao mtodo de acesso das memrias internas, vale a pena destacar os e o acessos aleatrio e associativo. No acesso aleatrio, cada unidade enderevel o o ca possui um mecanismo de endereamento unico e sicamente conectado a ela. E c o mtodo utilizado na memria principal. O esquema associativo consiste em e o um tipo de memria de acesso aleatrio que possibilita comparar simultaneao o mente um certo nmero de bits de uma palavra com todas palavras da memria u o (totalmente associativo) ou com um conjunto de palavras de memria (associao tivo por conjunto). O mtodo associativo empregado pelas memrias cache. e e o
26
As restries de um projeto de memria podem ser resumidos por 3 questes: co o o Capacidade, Velocidade e Custo. Neste cenrio, valem as seguintes relaes: a co 1. Menor tempo de acesso, maior custo por bit; 2. Maior capacidade, menor custo por bit; 3. Maior capacidade, menor tempo de acesso. A organizao hierrquica dos sistemas de memria visa lidar com o dilema ca a o imposto pelas relaes apresentadas. A hierarquia elaborada de forma que as co e a medida que nela descemos as seguintes relaes so tambm vlidas: co a e a 1 O custo por bit diminui; 2 A capacidade aumenta; 3 O tempo de acesso aumenta; 4 A freqncia de acesso pelo processador diminui. ue Desse modo, as memrias menores, mais caras e mais rpidas so combio a a nadas com memria de maior capacidade, mais lentas e baratas. o A chave do sucesso dessa organizao baseia-se principalmente na relao ca ca 4, que resume o princ pio da Localidade das Referncias. Este princ e pio diz que ao longo da execuo de um programa, as referncias feitas ` memria pelo ca e a o processador, tanto no caso de instrues como dados, tendem a formar grupos co no qual esto prximas umas das outras. Desse modo poss a o e vel organizar os dados ao longo de uma hierarquia de forma que a porcentagem de acessos ` um a certo n seja sucessivamente bem inferior do que a porcentagem de acessos ` vel a um n imediatamente superior. vel Registradores, memria cache e memria principal so as trs formas de o o a e memria interna que empregam tecnologias de semicondutores. O uso de trs o e n veis explora as diferenas de velocidade e custo dessas memrias. Alm dec o e las, alguns sistemas utilizam tecnologias e tcnicas adicionais na hierarquia de e memria. o A Memria Expandida emprega uma tecnologia mais lenta que a memrias o o principais. Ela funciona como um ramo lateral a memria principal, no se o a comunicando com a memria externa. J a tcnica de Memria Virtual permite o a e o que os discos funcionem como uma extenso da memria principal, aumentando a o o desempenho do sistema. A utilizao de memrias cache tem por objetivo proporcionar uma velocica o dade de acesso prxima a velocidade de acesso aos registradores, no entanto o oferecendo uma capacidade maior do que o conjunto de registradores, e custo no muito superior ao da memria principal. Os principais elementos de projeto a o de memrias cache so: o a i Tamanho - deve ser projetado para conjugar bem velocidade, capacidade e custo; 27
ii Funo de Mapeamento - direto, associativo, associativo por conjuntos; ca iii Algoritmo de Substituio - LRU, FIFO, LFU, Aleatrio; ca o iv Pol tica de Escrita - direta (write-through), de volta (write-back) e unica (write-once); v Tamanho da Linha; vi Nmero de Memrias Cache - um ou dois n u o veis, unicada/separada. Entre os elementos de projeto de memria cache vale destacar trs. O o e primeiro a Funo de Mapeamento, que diz respeito a determinar onde um e ca bloco da memria principal pode ser encontrado na memria cache. Para reo o alizar este mapeamento so necessrios o endereo do bloco na memria prina a c o cipal e a funo de mapeamento. No esquema de mapeamento direto, um deca terminado conjunto de blocos da memria principal s pode ser encontrado em o o uma linha espec ca da memria cache. E de fcil implementao, porm pode o a ca e utilizar de forma ineciente o espao da cache. No mapeamento associativo c um bloco da memria principal pode ser colocado em qualquer linha da cache. o Maximiza a ocupao da cache, porm exige uma lgica de controle que realca e o ize comparao do rtulo com todas as linhas do cache simultaneamente. No ca o esquema associativo por conjuntos, um bloco da memria principal pode se eno contrar em um conjunto de linhas da cache, e no nela toda. Visa conjugar a vantagens dos mtodos direto e associativo. e O segundo elemento Pol e tica de Escrita, que visa garantir a coerncia das e informaes nos diferentes memrias acess co o veis pelo processador e dispositivos de E/S. Na tcnica a de escrita direta (write-through), todas as operaes de e e co escrita so feitas na memria principal e no cache. Esta garante a coerncia em a o e todas as memrias do sistema, no entanto de baixo desempenho. Na tcnica o e e de escrita de volta (write-back), as escritas so feitas apenas na cache. Minimiza a as operaes de escrita em memria principal, porm impe que operaes de co o e o co E/S acessem o cache. O terceiro elemento o nmero de memrias cache do sistema. Atualmente, e u o a organizao mais comuns baseada em 2 n ca e veis, um interno ao processador (L1) e outro externo (L2). Originalmente, a maioria dos projetos de cache inclui uma unica memria cache, que armazenava tanto instrues como da o co dos. Recentemente, tornou-se comum a utilizao de memrias separadas para ca o instrues e dados. Em processadores modernos que se valem de tcnicas de co e busca antecipada de instruo (Pipeline), tcnicas de Cache Separadas so mais ca e a ecientes que as de Cache Unicada.
1.7
Desempenho do computador
1 T empo de Execucao
O desempenho de um computador pode ser denido como: Desempenho = (1.1)
28
O tempo a medida de desempenho de um sistema computacional. Em e geral, ele medido em segundos e pode ser denido de diferentes maneiras. O e tempo de resposta ou tempo decorrido (elapsed time) dene o tempo total para se completar uma tarefa computacional, incluindo os acessos ` memria e ao a o disco, as atividades de entrada e sa e o overhead do sistema operacional. da O tempo do processador (CPU time) dene o tempo gasto pelo processador para executar um programa em particular, no considerando o tempo de a execuo de outros programas, tempo de espera por I/O, etc. Este tempo ca e dividido em tempo do usurio e tempo do sistema. O tempo do usurio o a a e tempo gasto na execuo das instrues do programa do usurio. J o tempo ca co a a do sistema o tempo gasto pelo sistema operacional para executar tarefas em e benef do programa do usurio. A medida de tempo que mais interessa o cio a e tempo de usurio. a Os projetistas medem a velocidade do hardware na execuo de suas funes ca co bsicas com o clock. O clock possui uma taxa constante e determina o momento a da ocorrncia de eventos do prprio hardware. O tamanho de um per e o odo de clock referenciado tanto como o tempo necessrio para completar um ciclo de e a clock quanto como a freqncia do clock (inverso do ciclo de clock). Por exemplo, ue um ciclo de clock igual a 2 s corresponde a uma freqncia de 500MHz, que ue e o inverso do ciclo de clock.
1.7.1
Tempo de execuo de um programa ca
Frmulas bastante simples relacionam a medida do tempo de execuo gasto no o ca processador com a mtrica bsica baseada nos ciclos de clock e tempo do ciclo e a de clock: Tempo de CPU do programa = N de ciclos x Per odo de clock = N de ciclos / Freqncia do clock ue
Essas frmulas no incluem qualquer referncia ao nmero de instrues o a e u co necessrias ` execuo de um programa. O tempo de execuo tambm depende a a ca ca e do nmero de instrues do programa. O nmero de ciclos de clock necessrios u co u a a ` execuo de uma instruo dado por: ca ca e
No de ciclos de clock = No instrues do programa x CPI co
(1.2)
A CPI a mdia do nmero de ciclos por instruo. Este parmetro permite e e u ca a a comparao entre diferentes implementaes de uma mesma arquitetura do ca co conjunto de instrues, uma vez que o nmero de instrues para a execuo do co u co ca programa nas diferentes implementaes o mesmo. co e
1.7.2
Desempenho da CPU
O desempenho da CPU na execuo de um programa pode ser medido em termos ca quantidade de instrues, do CPI e do per co odo do clock:
29
Tempo de CPU = No de instrues x CPI x Per co odo do clock
(1.3)
O tempo de CPU medido executando o programa, o per e odo do clock e divulgado pelo fabricante e o nmero de instrues obtido por meio de softu co e wares conhecidos como execution prolers ou por simuladores de arquitetura. Em uma primeira aproximao, o nmero de instrues, a CPI e o per ca u co odo do clock so afetados respectivamente pela capacidade de otimizao do coma ca pilador, pela arquitetura do processador e de seu conjunto de instrues; e pela co tecnologia empregada na implementao da mquina. ca a
1.7.3
Programas para medir desempenho
Existem quatro n veis de programas que podem ser usados para avaliao de ca desempenho, eles esto listados em ordem decrescente de preciso de previso: a a a Programas reais; Ncleos ou kernels (pedaos de programas reais); u c Toy Benchmarks (programas com 10 a 100 linhas de cdigo que produzem o um resultado conhecido a priori); Benchmarks sintticos (similar em losoa aos ncleos, tentam casar a e u freqncia mdia de operaes de um grande conjunto de programas). ue e co Os benchmarks so conjuntos de aplicaes que representam cargas de traa co balho cujo objetivo estimar o desempenho das cargas de trabalho reais. Os e benchmarks podem conter aplicaes t co picas de processamento cient co, compiladores, processadores de texto entre outras. Um Benchmark Suite um conjunto de programas de avaliao. A Stane ca dard Performance Evaluation Corporation (SPEC) tem lanado vrios benchc a mark suites: SPEC89, SPEC92, SPEC95 e SPEC2000. Estas benchmark suites so compostas por programas reais, escolhidos para serem representativos de a 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 mtrica de avaliaao, tempo de resposta ou throughput (nmero de e c u tarefas executadas por unidade de tempo), necessrio decidir como comparar e a os dados de desempenho obtidos a partir de diferentes benchmarks. A maneira mais simples de considerar o desempenho relativo usar o tempo e total de execuo de dois programas em mquinas diferentes. Por exemplo, os ca a tempos de execuo de dois programas conforme a tabela 1.1. ca Outra maneira de sumarizar os tempos utilizando as mdias aritmtica, e e e harmnica ou geomtrica. A mdia geomtrica inadequada, pois no prediz o o e e e e a tempo de execuo. ca 30
Programa 1 (s) Programa 2 (s) Total (s)
Computador A 1 1000 1001
Computador B 10 100 110
Tabela 1.1: Tempo total de execuo de 2 programas ca
Mdia Aritmtica = Tempo (i,n) = e e Mdia Harmnica = Taxa (i,n) = e o
1 n n
(1.4) (1.5)
n 1 i=1 T axai
Mdia Geomtrica = Tempo Normalizado (i,n) = e e
T normalizadoi (1.6)
i=1
Alm das mdia, existem ainda outras medidas de desempenho. Uma das e e alternativas a mtrica MIPS (million instruction per second), que dada por e e e um das seguintes expresses: o Nmero de instrues u co Tempo de execuo x 106 ca Freqncia de Clock ue CPI 106
MIPS
= =
Existem problemas com o uso da mtrica MIPS. Ela especica a taxa de e execuo de instrues, mas no considera a capacidade de executar mais ou ca co a menos trabalho. Portanto, no podemos comparar mquinas com conjuntos de a a instrues diferentes. Outro problema que os resultados obtidos variam enco e tre programas no mesmo computador, o que impede que determinada mquina a tenha um MIPS caracter stico. Outra alternativa a mtrica denominada MFLOPS (million oating-point e e operations per second), que dada pela seguinte expresso: e a
MFLOPS =
Nmero de op. de ponto utuante u Tempo de execuo x 106 ca
(1.7)
Uma operao de ponto utuante pode ser uma operao de adio, subca ca ca trao, multiplicao ou diviso aplicada a operandos expressos em preciso ca ca a a simples ou dupla.
1.7.5
Lei de Amdahl
A lei de Amdhal pode ser utilizada para demonstrar o ganho de desempenho de uma mquina. Este ganho dito acelerao ou speedup. Entende-se por a e ca acelerao a medida de como a mquina se comporta aps a implementao ca a o ca
31
de uma melhora em relao ao seu comportamento anterior. Podemos denir ca speedup como: speedup = Desempenho aps a melhora o Desempenho antes da melhora (1.8)
A lei de Amdhal demonstra que errado esperar que a melhora em um dos e aspectos que inuenciam no desempenho da mquina resulte numa melhora no a desempenho total proporcional ao tamanho do ganho inicial da frao. ca
32
Cap tulo 2
Componentes de um Computador
O computador est organizado em dois componentes que so: a a Hardware: corresponde a parte f sica que est dividida em: unidade de a entrada e sa da, processador, memria principal e memria secundria; o o a Software: o conjunto de programas que d vida ` mquina. E classicado e a a a em software aplicativo (jogos, planilha, etc.) e software bsico (sistema a operacional, compiladores, editores de texto, etc.). Para interligar os componentes do hardware existe uma placa de suporte especial, chamada placa-me. A placa-me responsvel por gerenciar toda a a a e a transao entre o processador e os perifricos. Os componentes principais da ca e placa-me so: chipset, BIOS, barramentos, e slots. a a Chipset o chip responsvel pelo controle de diversos dispositivos de entrada e a e sa como o barramento, o acesso ` memria, o acesso ao HD, perifricos da a o e on-board e o-board, comunicao do processador com a memria RAM e enca o tre outros componentes da placa-me. Uma placa-me possui dois chipsets: o a a chipset sul e o chiset norte. O chipset sul (south bridge) responsvel pelo conte a role de dispositivos de entrada ou sa enquanto o chipset norte (north bridge) da faz a comunicao entre o processador e a memria principal. ca o
O BIOS (Basic Input/Output System) o primeiro programa executado e pelo computador ao ser ligado. Sua funo primria preparar a mquina para ca a e a que o sistema operacional, que pode estar armazenado em diversos tipos de dispositivos (discos r gidos, disquetes, CDs, etc) possa ser executado. O BIOS armazenado num chip ROM (Read-Only Memory) localizado na placa-me, e a chamado ROM BIOS. O BIOS tambm responsvel por controlar o uso dos e e a dispositivos e manter informaes de data e hora. O BIOS trabalha junto com co o post, um software que testa os componentes do micro em busca de eventuais erros. Pode-se alterar as conguraes de hardware atravs do setup. co e
33
Os barramentos permitem a interligao entre os dispositivos da placa-me. ca a So divididos em trs conjuntos: via de dados, via de endereos e via de conta e c role. O desempenho do barramento pode ser medido pela sua largura de banda (32, 64 bits, etc.) e pela sua velocidade de transmisso (100 Mbps, 1G bps, etc.). a Os slots so responsveis por ligar os perifricos aos barramentos e suas a a e velocidades e largura de banda so correspondentes as dos seus respectivos bara ramentos. Na placa-me so encontrados vrios slots para encaixe de placas a a a (v deo, som, rede, modem, etc.). Alguns exemplos de slots: ISA, PCI, AGP, PCI Express, etc.
2.1
2.1.1
Principais componentes de Hardware

Discos R gidos
Os discos r gidos so dispositivos de armazenamento destinados a grandes quana tidades de dados. Fisicamente, um disco r gido pode ser visto como um composto por dois grandes blocos, como na gura 2.2. O primeiro bloco um e conjunto de discos magnticos superpostos em alturas diferentes com aux de e lio um eixo central. No momento de acesso ao disco, essa estrutura mantida em e uma rotao constante. O segundo bloco uma estrutura mecnica que suporta ca e a um conjunto de cabeotes, um para cada superf de disco. Essa estrutura c cie e capaz de realizar movimentos de vai-e-vem de maneira que os cabeotes possam c ser deslocados desde a borda do disco at o centro. e
Figura 2.1: Organizao f ca sica do disco Do ponto de vista da organizao lgica, cada superf de um disco dica o cie e vidida em circunferncias concntricas denominadas trilhas. Cada trilha, por e e sua vez, subdividida radialmente em unidades chamadas setores. Em geral, e os setores tm o mesmo tamanho. O setor possui a unidade m e nima de leitura e gravao em um disco. O conjunto de todas as superf ca cies do disco que cam exatamente ` mesma distncia do eixo central forma o cilindro, conforme a a a gura ??. As abstraes cilindro, trilha e setor so utilizadas para designar a co a organizao lgica da unidade de disco. A denio de trilhas e de setores em ca o ca 34
um disco chama-se formatao f ca sica e um procedimento realizado pelo fabrie cante. A capacidade total do disco obtida multiplicando-se cabeas x cilindros e c x setores x tamanho do setor.
Figura 2.2: Organizao lgica da unidade de disco ca o Para acessar dados no disco, necessrio informar ` controladora o ciline a a dro, a superf e o setor a ser acessado. Esse mtodo denominado de CHS cie e e (Cylinder, Head, Sector). Outra maneira acessar o disco enxerg-lo como e e a um conjunto de blocos, no qual cada bloco um ou mais setores. O nmero de e u blocos ento convertido em cilindros, superf e setores por um procedimento e a cie que se denomina de LBA (Linear Block Addressing). Outros termos bastante comuns associados a disco r gidos so formatao a ca lgica e parties. A formatao lgica consiste em gravar informaes no disco o co ca o co de forma que arquivos possam ser escritos, lidos e localizados pelo sistema operacional. O conceito de partio est associado ` capacidade de dividir logicaca a a mente um disco em vrios outros discos. a Para realizar um acesso a um disco, necessrio posicionar o cabeote de e a c leitura e escrita sob um determinado setor e trilha onde dado ser lido ou esa crito. O tempo total de acesso aos disco, seja para leitura ou para escrita, e dado pela seguinte frmula: o
Ta cesso = Ts eek + Tl atencia + Tt ransf erencia A descrio de cada um dos termos da soma a seguinte: ca e
(2.1)
Tempo de Seek: tempo necessrio para deslocar o cabeote de leitura e a c escrita at o cilindro correspondente ` trilha a ser acessada; e a Tempo de Latncia: tempo necessrio, uma vez o cabeote posicionado j e a c a na trilha correta, para o setor a ser lido, ou escrito, se posicionar sob o cabeote de leitura e escrita no in do setor a ser lido (ou escrito); c cio Tempo de Transferncia: corresponde ao tempo necessrio ` transferncia e a a e dos dados, isso , ` leitura ou a escrita dos dados. e a 35
Outro fator relacionado com a reduo do tempo de acesso a um disco ca e o entrelaamento (interleaving). Essa tcnica numera os setores no mais de c e a forma cont gua, mas sim com um espao entre eles. O disco 2 da Ilustrao 14 c ca possui um fator de entrelaamento igual a 2. Isso signica que entre o setor k c e o setor k+1, existem dois outros setores. O melhor fator de entrelaamento c para uma determinada unidade de disco depende da velocidade do processador, do barramento, do controlador e da velocidade de rotao do disco. ca
Figura 2.3: Trilha com 16 setores e diferentes fatores de entrelaamento c
2.1.2
Teclado
O teclado o principal perifrico de entrada de dados utilizado na integrao e e ca direta de usurios com o computador. O princ de operao do teclado basa pio ca e tante simples: gerar um s mbolo 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 pressionada. A cada elemento i,j da e matriz correspondente um caractere. Quando uma tecla pressionada, o teclado identica a linha e a coluna e associadas a essa tecla e gera um cdigo que denominado de scan mode (cdigo o e o de varredura). O pressionar da tecla gera ainda uma interrupo de hardware, ca e por conseqncia, a execuo de um tratador de interrupes espec ue ca co co para o teclado. Com base no scan mode, o tratador de interrupes consulta uma co tabela interna, substituindo o scan mode pelo cdigo ASCII correspondente ` o a tecla pressionada. O cdigo ASCII da tecla, em seguida, armazenado em o e uma regio especial da memria (buer do teclado) de onde recuperado por a o e chamadas do sistema operacional. Um teclado brasileiro difere de um teclado ingls na posio dos acentos e e ca da cedilha, por exemplo. A soluo empregada associar a certos programas ca e aplicativos mapas de cdigos. Atravs desses mapas de cdigos, os programas o e o aplicativos so capazes de consumir caracteres do buer de teclado e converta e los de forma apropriada. O procedimento de ler os dados do teclado e escrev-los na tela denomina-se e ecoamento. Quando se tem vrias janelas abertas, os caracteres digitados devem a ser direcionados ` janela correta. Dois mtodos so normalmente empregados: a e a centralizado e dedicado.
36
No mtodo centralizado o driver de teclado disponibiliza um conjunto de e mini-buers os quais podem ser encadeados para formar um buer maior. Nesse caso, para cada janela aberta o sistema operacional atribui uma estrutura de dados na qual um dos seus elementos um ponteiro utilizado para referenciar e e lista encadeada de mini-buers. No mtodo dedicado, a buerizao feita e ca e diretamente em uma rea de memria provida pela estrutura de dados associada a o ao terminal. Nesse caso, o nmero de entradas para o terminal limitado pelo u e tamanho do buer dessa estrutura.
2.1.3
Mouse
O mouse um perifrico de entrada que historicamente se juntou ao teclado e e como auxiliar no processo de entrada de dados, especialmente em programas com interface grca. O mouse tem como funo movimentar o cursor (apona ca tador) pela tela do computador. O formato mais comum do cursor uma seta, e contudo, existem opes no sistema operacional e softwares que permitem perco sonalizarmos o cursor do mouse. O mouse funciona como um apontador sobre a tela do monitor, e disponibiliza, normalmente, quatro tipos de operaes: movimento, click (clique), duplo co click e drag and drop (arrastar e largar). Existem modelos com um, dois, trs ou mais botes cuja funcionalidade e o depende do ambiente de trabalho e do programa que est a ser utilizado. Claraa mente, o boto esquerdo o mais utilizado. a e O mouse normalmente ligado ao computador atravs de portas: serial, PS2 e e ou, mais recentemente, USB (Universal Serial Bus). Tambm existem conexes e o sem o, as mais antigas em infra-vermelho, as atuais em Bluetooth. Outros dispositivos de entrada competem com o mouse: Touchpads (usados basicamente em notebooks) e Trackballs. O mouse original possu dois discos que rolavam nos eixos X e Y e tocavam a diretamente na superf cie. O modelo mais conhecido de rato provavelmente o e mouse baseado em uma esfera, que roda livremente, mas que na prtica gira dois a discos que cam em seu interior. O movimento dos discos pode ser detectado tanto mecanicamente quanto por meio tico. o
Os modelos mais modernos de mouse so totalmente ticos, no tendo peas a o a c mveis. De modo muito simplicado, eles tiram fotograas que so comparadas o a e que permitem deduzir o movimento que foi feito.
2.1.4
Placa de rede
Uma placa de rede um dispositivo de hardware responsvel pela comunicao e a ca entre os computadores em uma rede. A placa de rede o hardware que permite e aos computadores conversarem entre si atravs da rede. Sua funo controlar e ca e todo o envio e recebimento de dados atravs da rede. Cada arquitetura de rede e exige um tipo espec co de placa de rede, sendo as arquiteturas mais comuns as 37
redes Ethernet e Token Ring. Alm da arquitetura usada, as placas de rede ` venda no mercado diferenciame a se tambm pela taxa de transmisso, cabos de rede suportados e barramento e a 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 ` taxa de transmisso, as placas mais comuns so Ethernet de 10, a a a 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 tranado de c categoria 3 ou 5, ou ento cabos coaxiais. Usando uma placas de 100 Mbps o a requisito m nimo a n de cabeamento so cabos de par tranado n 5. No vel a c vel caso de redes Token Ring, os requisitos so cabos de par tranado categoria 2 a c (recomendvel o uso de cabos categoria 3) para placas de rede de 4 Mbps, e a cabos de par tranado blindado categoria 4 para placas de 16 Mbps. Devido `s c a exigncias de uma topologia em estrela das redes Token Ring, nenhuma placa e de rede Token Ring suporta o uso de cabos coaxiais.
2.1.5
Impressora
As impressoras so dispositivos de sa que tem por nalidade imprimir em a da papel ou lme plstico os resultados do processamento. Da mesma forma que a os monitores, a imagem impressa resultado de muitos pontos impressos indie vidualmente que no conjunto formam o texto ou a imagem desejados. Tambm e de forma semelhante aos monitores, as impressoras evolu ram a partir de dispositivos que imprimiam apenas caracteres em uma unica cor para as modernas impressoras capazes de reproduzir imagens sosticadas, de alta resoluo grca, ca a em milhares de cores. As impressoras so classicadas em: a Impressoras alfanumricas: Esses equipamentos recebem do computador e cdigos que representam caracteres alfanumricos e portanto tem capacio e dade de imprimir apenas esses caracteres. Geralmente poss usar apee vel nas uma fonte grca, caracter a stica do equipamento. Algumas impressoras permitem trocar o dispositivo de impresso, viabilizando a utilizao a ca de um pequeno nmero de fontes grcas; u a Impressoras grcas: Esses equipamentos recebem do computador a ina formao sobre os pontos a serem impressos. Dessa forma, podem imca primir grcos. Na impresso de textos, os caracteres so impressos como a a a pontos, que em determinada congurao formam a imagem grca do ca a caractere a ser impresso. Quando se utiliza uma impressora grca para a imprimir texto, existe a possibilidade de utilizar um grande nmero de u diferentes fontes grcas, denidas por software. a
2.1.6
Monitor
38
Cap tulo 3
Aritmtica Computacional e
3.1 N meros Com Sinal e N meros Sem Sinal u u
Existe uma grande variedade de opes para representar os nmeros inteiros co u com ou sem sinal. Apenas quatro se destacam: sinal e amplitude/magnitude (S + M ), complemento de 1, complemento de 2 e notao em excesso (biased ). ca
3.1.1
Sinal e amplitude/magnitude
Neste sistema de representao o bit mais a esquerda representa o sinal: 0 (zero) ca para indicar o valor positivo e 1 (um) para indicar o valor negativo. Os bits restantes representam o mdulo. A amplitude ou faixa de representao para n o ca bits [(2n1 1); 2n1 1]. Por exemplo, para n=8 a faixa de representao e ca [127; 127]. Neste sistema o zero possui duas representaes, por exemplo, e co n = 4 (0000 e 1000).
3.1.2
Complemento de 1
Neste sistema de representao o bit mais a esquerda representa o sinal: 0 (zero) ca para indicar o valor positivo e 1 (um) para indicar o valor negativo. Para os nmeros positivos, os n-1 bits representam o mdulo. O simtrico de um nmero u o e u positivo obtido pelo complemento de todos os seus d e gitos (trocando 0 por 1 e vice-versa) incluindo o bit de sinal. A amplitude ou faixa de representao ca para n bits [(2n1 1); 2n1 1]. Por exemplo, para n = 8 a faixa de e representao [127; 127]. Neste sistema o zero possui duas representaes, ca e co por exemplo, n = 4 (0000 e 1000).
3.1.3
Complemento de 2
Neste sistema de representao o bit mais a esquerda representa o sinal: 0 (zero) ca para indicar o valor positivo e 1 (um) para indicar o valor negativo. Para os nmeros positivos, os bits restantes representam o mdulo. A amplitude ou u o faixa de representao para n bits [(2n1 ); 2n1 1]. Por exemplo, para ca e n=8 a faixa de representao [128; 127]. Este sistema possui representao ca e ca assimtrica, o nmero de representaes negativas maior do que a positiva. e u co e Este sistema o zero possui uma unica representao, por exemplo, n=4 (0000). ca 39
O complemento de 2 de um nmero obtido em dois passos: primeiro obtmu e e se o complemento de todos os bits (inclusive o de sinal); e ao resultado obtido soma-se 1 (um) em binrio, desprezando o ultimo transporte, se houver. a Uma maneira prtica de se obter o complemento de 2 de um nmero copiar a u e da direita para a esquerda todos os bits at encontrar o primeiro bit 1 (copiar e inclusive este bit), e inverter todos os demais bits. Um exemplo para n=4: 0110 (6 na base 10) 1001 (nmero binrio invertido) u a + 0001 (soma binria com 1) a 1010 (complemento de 2) usando a regra: 0110 < > 1001
Os computadores manipulam tanto nmero inteiros positivos quanto negativos, u que so representados em complemento de 2. a
3.1.4
Notao em excesso ca
Neste sistema de representao o bit mais a esquerda representa o sinal: 1 ca (um) para indicar o valor positivo e 0 (zero) para indicar o valor negativo. A amplitude ou faixa de representao para n bits [(2n1 ); 2n1 1]. Por ca e exemplo, para n=8 a faixa de representao [128; 127]. Neste sistema cada ca e nmero inteiro corresponde ao valor desejado acrescido de um excesso de 2n1 , u onde n pode ser 4, 5, 7, 8, 16, etc. Este sistema tem uma vantagem em relao aos outros sistemas apresentaca dos anteriormente: o valor em binrio com todos os bits a 0 (zero) representa o a menor valor inteiro, que este tenha sinal ou no, e o mesmo se aplica ao maior a valor em binrio, i.e., com todos os bits 1: representa o maior inteiro, com ou a sem sinal. Binrio (4 bits) a 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111 S+M +0 1 2 3 4 5 6 7 -0 -1 -2 -3 -4 -5 -6 -7 C1 +0 1 2 3 4 5 6 7 -7 -6 -5 -4 -3 -2 -1 -0 C2 0 1 2 3 4 5 6 7 -8 -7 -6 -5 -4 -3 -2 -1 Excesso de 8 (n=4) -8 (0 - 8) -7 (1 - 8) -6 (2 - 8) -5 (3 - 8) -4 (4 - 8) -3 (5 - 8) -2 (6 - 8) -1 (7 - 8) 0 (8 - 8) 1 (9 - 8) 2 (10 - 8) 3 (11 - 8) 4 (12 - 8) 5 (13 - 8) 6 (14 - 8) 7 (15 - 8)
40
3.2
Adio e Subtrao ca ca
Numa soma os bits so somados um a um da direita para a esquerda, com os a carries sendo passados para o prximo bit ` esquerda. A operao de subo a ca trao usa a adio. O subtraendo simplesmente negado antes de ser somado ca ca e ao minuendo. Lembre-se que a mquina trata com nmeros representados em a u complemento a 2. O exemplo a seguir mostra as operaes de soma (6 + 7) e co subtrao (7 6) (complemento 2) bit a bit entre dois nmeros representados ca u com 4 d gitos binrios. a 7 = 0111 6 = 0110 13 = 1101 (soma) 1 = 0001 (subtrao) ca Tanto a soma como a subtrao podem gerar overow ou underow, se ca o resultado obtido no puder ser representado pela quantidade de bits que a formam uma palavra. Se somarmos ou subtrairmos dois nmeros com sinais u contrrios, nunca ocorrer overow ou underow. Isto porque operandos com a a sinais contrrios nunca podem ser maior do que qualquer dos operandos. a O overow ocorre quando somamos dois operandos positivos e obtemos um resultado negativo, ou vice-versa. Isto signica que utilizamos o bit de sinal, gerando um carry, para armazenar um valor pertencente ao resultado da operao. Racioc ca nio semelhante realizado para detectar a ocorrncia do e e underow numa subtrao. Neste caso, o bit de sinal tambm usado para ca e e armazenar um valor pertencente ao resultado da operao. ca Os projetistas de um sistema devem decidir onde tratar a ocorrncia de e overow ou de underow em operaes aritmticas. Elas podem ser tratadas co e tanto por hardware quanto por software. Pode existir a deteco por hardware ca que gera uma exceo, e que depois tratada por software. ca e
3.3
Operaes Lgicas co o
Os computadores manipulam palavras, mas muito util, tambm, manipular e e campos de bits dentro de uma palavra ou mesmo bits individuais. O exame de caracteres individuais (8 bits) dentro de uma palavra um bom exemplo e dessa necessidade. Assim, as arquiteturas de conjuntos de instrues incluem co instrues para manipulao de bits. co ca Um dos tipos de instruo utilizado a de deslocamento de bits. As inca e strues podem deslocar bits tanto ` direita quanto ` esquerda. Todos os bits co a a so movidos para o lado determinado e os bits que cam vazios so preenchidos a a com 0s. Outras instrues lgicas muito uteis so implementadas na unidade co o a lgica e aritmtica de um processador so as operaes NOT, AND, OR e XOR. o e a co O exemplo abaixo mostra as operaes lgicas, bit a bit, de deslocamento ` dico o a reita, ` esquerda, NOT, AND, OR e XOR. a
41
3.4
Construo de uma Unidade Lgica Aritmtica ca o e
A ALU (Arithmetic and Logic Control) a parte central do hardware de uma e CPU. Ela responsvel por realizar operaes aritmticas e lgicas bsicas, e e a co e o a 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 sa para o resultado, uma entrada relativa ao carry in e da um sa relativa ao carry out. A tabela abaixo mostra a tabela verdade para o da somador de um bit. a 0 0 0 0 1 1 1 1 Entrada b carry in 0 0 0 1 1 0 1 1 0 0 0 1 1 0 1 1 soma 0 1 1 0 1 0 0 1 Sa da carry out 0 0 0 1 0 1 1 1
As sa das soma e carry out so: a 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 somadores de um bit. Os carry outs gerados pelos bits menos signicativos so a propagados por toda extenso do somador. a A operao de subtrao pode ser realizada somando-se o minuendo com ca ca a negao do subtraendo. Este efeito realizado acrescentando uma entrada ca e complementada de b ao somador e ativando o carry in do bit menos signicativo para um. O somador ento calcula a + b + 1. a Outras funes de interesse, com o XOR podem ser inclu co das na ALU. Algumas operaes no so, em geral, implementadas na ALU (3.4). Exemplos: co a a shift, multiplicao, diviso e operaes de ponto utuante. ca a co 42
Figura 3.2: ALU
3.5
Ponto Flutuante
Para somar dois nmeros na base 10 em notao cient u ca ca temos que: Alinhar os pontos; Somar os nmeros; u Normalizar o resultado; Arredondar o resultado para o nmero mximo de casas permitidas. u a Um hardware para somar nmeros de ponto utuante tem que fazer as mesu mas operaes com nmeros binrios. Vejamos um exemplo: co u a Exemplo: Somar os nmeros 0.5 e -0.4375 em binrio e apresente com 4 bits u a de preciso; trunque o resultado na fase de arredondamento. a 0.5 = 0.1 (binrio) = 0.1 20 = 1.000 21 a 0.4375 = 0.0111 (binrio) = 0.0111 20 = 1.110 22 a
1. Igualar os expoentes (modicar o nmero menor) u 1.110 22 = 0.111 21 2. Somar as partes signicantes (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 nmero nal est OK. u a
43
Cap tulo 4
4.1 Introduo ca
O sistema operacional uma camada de software colocada entre o hardware e e os programas que executam tarefas para os usurios. O sistema operacional a responsvel pelo o acesso aos perifricos, ou seja, sempre que um programa e a e necessita de algum tipo de operao de entrada e sa ca da, ele solicita ao sistema operacional.
Figura 4.1: Sistema Operacional
O objetivo do sistema operacional tornar a utilizao do computador mais e ca eciente e mais conveniente. Uma utilizao mais eciente do computador ca e obtida por meio da distribuiao de seus recursos (memria principal, tempo de c o processador, impressora, espao em disco, etc.) entre os programas. Uma utic lizao mais conveniente obtida escondendo-se do programador detalhes do ca e hardware, em especial os perifricos. Para atingir esses objetivos, o sistema ope eracional oferece uma srie de servios como: gerncia de memria, gerncia do e c e o e processador, memria virtual, sistema de arquivos, sistema de entrada e sa o da. A arquitetura de um sistema operacional corresponde ` imagem que o usurio a a tem do sistema, a forma como ele percebe o sistema. Esta imagem denida e
44
pela interface por meio da qual o usurio acessa os servios do sistema operaa c cional. Essa interface formada pelas chamadas de sistema e pelos programas e de sistema. Os programas solicitam servios ao sistema operacional por meio das chamadas c de sistema que transferem a execuo dos programas para o sistema operacional. ca A parte do sistema operacional responsvel para implementar as chamadas de a sistema normalmente chamadas de ncleo ou kernel. Os principais compoe u nentes do kernel de qualquer sistema operacional so a gerncia de processador, a e gerncia de memria, sistema de arquivos e gerncia de entrada e sa e o e da. Os programas de sistemas, algumas vezes chamados de utilitrios, so proa a gramas normais executados fora do kernel do sistema operacional. Eles implementam tarefas bsicas para utilizao do sistema e muitas vezes so confuna ca a didos com prprio sistema operacional. Exemplos de programas de sistemas o so os utilitrios para manipulao de arquivos, listar arquivos, imprimir ara a ca quivos, trocar nome de arquivos, data, hora e etc. O programa de sistema mais importante o interpretador de comando. Sua tarefa receber comandos e e e execut-los. Esses comandos podem ser enviados de forma textual ou por meio a de uma interface grca de usurio (GUI). a a O sistema operacional no resolve problemas do usurio nal. Somente a a quando ocorre algum evento especial que o sistema operacional ativado. Dois e tipos de eventos ativam o sistema operacional: uma chamada de sistema ou uma interrupo de perifrico. ca e Os sistemas operacionais podem ser classicados segundo inmeros critrios, u e dentre os quais os mais comuns so: a Nmero de usurios u a Monousurios: projetados para suportar um unico usurio. Exempa a los de desse tipo de sistema so o MS DOS, Windows 3x, Windows a 9x, etc; Multiusurios: projetados para suportar vrias sesses de usurios. a a o a Exemplos desse sistema so Windows NT, UNIX, etc; a Nmero de tarefas u
Monotarefa: capazes de executar apenas uma tarefa de cada vez. Por exemplo, o MS DOS, etc; Multitarefa: capazes de executar vrias tarefas simultaneamente, a como uma compilao e um processamento de texto. Por exemplo, ca Windows, Unix, etc; Tipo de servio oferecido ao usurio c a Sistemas de processamento em lote (batch); Sistemas de tempo compartilhado (time sharing); Sistemas de tempo real (real time);
45
Sistemas Mainframes; Sistemas desktop; Sistemas distribu dos; Sistemas handheld; Sistemas paralelos.
4.2
4.2.1
Conceitos Bsicos a
Multiprogramao ca
A multiprogramao torna mais eciente o aproveitamento dos recursos do comca putador. Isso conseguido por meio da execuo simultnea de vrios prograe ca a a mas. Em um sistema multiprogramado diversos programas so mantidos na a memria ao mesmo tempo. o A idia da multiprogramao aproveitar o tempo ocioso do processador e ca e durante as operaes de entrada e sa co da, ou seja, enquanto o perifrico executa e o comando enviado, o sistema operacional inicia a execuo de outro programa. ca Isso faz com que exista uma maximizao do uso do processador e da memria. ca o Em um ambiente monoprogramado, o processador caria parado durante a realizao do acesso a um perifrico. ca e
4.2.2
Processo
Um processo pode ser denido como um programa em execuo. O processo ca e considerado um elemento ativo, pois altera o seu estado ` medida que executa a um programa. E o processo que realiza as chamadas de sistema. Em muitos sistemas operacionais os processos so criados por outros proa cessos, por meio de chamada de sistema. Nesse caso, poss e vel denir uma hierarquia de processos. O processo que faz a chamada de sistema chamado e de processo pai e o processo criado chamado de processo lho. Um mesmo e processo pai pode estar associado a vrios processos lhos. Os processos lhos, a por sua vez, podem criar outros processos.
Durante a sua execuo, um processo passa por diversos estados, reetindo ca o seu comportamento dinmico, isto , sua evoluo no tempo. Os poss a e ca veis estados para um processo so: criao (new), apto (ready), executando (runa ca ning), bloqueado (blocked) e terminado (exit). A gura 4.2 mostra esses cincos estados e as transies do processo entre eles. co No estado New um novo processo criado. Aps ser criado, o processo entra e o em um ciclo de processador. Ele precisa do processador para executar, mas o processador poder estar ocupado com outro processo, ele dever esperar. Dia a versos processos podem estar no nesse mesmo estado. Nesse caso, necessrio e a manter uma la com os processos aptos a ganhar o processador. Essa la e chamada de la 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 no existe uma garantia de que o processo a ser executado. a Os processos na la do processador esto no estado Ready. Um unico proa cesso ocupa o processador a cada instante. O processo que ocupa o processador est no estado Running. Neste estado processo pode realizar as chamadas de a sistema. Enquanto o sistema espera pelo trmino da chamada de sistema, o e processo est no estado Blocked. a O processo ca no estado Blocked at ser atendido. Com isso, o processador e ca livre. O sistema operacional seleciona outro do processo da la de aptos para receber o processador. O estado Exit indica que o processo terminou sua execuo ou foi abortado. ca A mudana de estado de qualquer processo iniciada por um evento. Esse c e evento aciona o sistema operacional, que ento altera o estado de um ou mais a processos. O evento pode ser uma chamada de sistema ou uma interrupo de ca hardware. Alguns outros caminhos so poss a veis no grafo de estado. Por exemplo, pode ocorrer de nenhum processo na memria principal est no estado Ready, pois o a todos esto aguardando uma operao de entrada e sa a ca da. Nesse caso, o sistema operacional realiza o swap (mover todo ou parte de um processo da memria o para o disco) de um dos processos bloqueados para disco, e coloca numa la de processo suspensos. O estado para essa situao o Suspend. Quando a ca e operao de entrada e sa de um dos processos nalizada, o sistema operaca da e cional trs do disco o processo da la de suspenso colocando no estado de Ready. a
4.2.3
Interrupes co
O mecanismo de interrupo constitui a base de operao de um sistema mulca ca tiprogramao. O mecanismo de interrupo permite que o controlador de ca ca perifrico chame a ateno do processador. A funo bsica do controlador e ca ca a de perifrico conectar o dispositivo em questo ao processador. e e a Uma interrupo sempre sinaliza a ocorrncia de algum evento. Quando ca e ela acontece, desvia a execuao da posio atual de programa para uma rotina c ca 47
espec ca. Essa rotina, responsvel por atender a interrupo chamada de a ca e tratador de interrupo. O tratador realiza as aes necessrias em funo da ca co a ca ocorrncia da interrupo. e ca Em computador podem existir diversos controladores capazes de gerar interrupes. A forma mais simples de identicar a origem da interrupo associar co ca e a cada controlador um tipo diferente de interrupo. Por exemplo, cada tipo de ca interrupo identicado por um nmero. ca e u Existem momentos que um programa no pode ser interrompido enquanto a realiza uma tarefa cr tica. Para isso, o processador possui instrues para habilco itar e desabilitar as interrupes. Enquanto as interrupes estiverem desabilco co itadas, elas sero ignoradas pelo processador. Elas no so perdidas, apenas a a a cam pendentes. Quando o programa tornar a habilitar as interrupes, elas co sero imediatamente atendidas pelo processador. a Interrupes de software, tambm chamadas de traps, so causadas pela exco e a ecuo de uma instruo espec ca ca ca para isso. O efeito semelhante a uma e chamada de sub-rotina, pois o prprio programa interrompido quem gera a o e interrupo. O maior uso para interrupes de software a implementao ca co e ca de chamadas de sistemas, por meio das quais os programas solicitam servios c ao sistema operacional. No poss desabilitar as interrupes de software, a e vel co mesmo porque no necessrio. a e a Existe uma terceira classe de interrupes geradas pelo prprio processador. co o So as interrupes por erro, muitas vezes chamadas de interrupes de exceo. a co co ca Elas acontecem quando o processador detecta algum tipo de erro na execuo do ca programa. Por exemplo, uma diviso por zero, um acesso a posio de memria a ca o invlido, etc. a
4.2.4
Threads
Uma thread nada mais que um uxo de execuo. Na maior parte das vezes, e ca cada processo formado por um conjunto de recursos mais uma unica thread. e A idia do multithreading associar vrios uxos de execuo (vrias threads) e e a ca a a um unico processo. Em determinadas aplicaes, conveniente disparar vrias co e a threads dentro de um mesmo processo (programao concorrente). E importante ca notar que as threads existem no interior de um processo, compartilhando entre elas os recursos de processo, como espao de endereamento, cdigo e dados. c c o Devido a essa caracter stica, a gerncia de threads (criao, destruio, troca e ca ca de contexto, sincronizao) mais leve quando comparada com processos. O ca e chaveamento entre duas threads de um mesmo processo muito mais rpido e a que o chaveamento entre dois processos. Em funo disso, threads so muitas ca a vezes chamadas de processos leves.
48
4.3
Escalonamento de Processos
Os mecanismos de gerenciamento de processador visam permitir que vrios proa cessos compartilham o processador de forma aumentar a Utilizao, aumentar ca o Throughput, diminuir o Tempo de Resposta e o Tempo Total de Execuo. ca Estas so as principais mtricas de desempenho de um sistema operacional no a e que diz respeito ` gerencia de processador. a Para alcanar bons resultados, os sistemas operacionais empregam vrias c a pol ticas de escalonamento para determinar qual processo tomar posse do proa cessador em um determinado instante. Essas pol ticas so os chamados Ala goritmos de Escalonamento. Exemplo de algoritmos de escalonamento so: a First In First Out (FIFO), Prioridades, Round-Robin, Shortest Job First (SJF), Mltiplas Filas com Realimentao, entre outras. u ca A parte do sistema operacional responsvel por escolher qual o processo a tomar posse do processador em um determinado instante o Scheduller, ena e quanto o responsvel por entregar o processador de fato a um processo o a e Dispatcher. E o Dispatcher quem realiza o chaveamento de contexto, que consiste em salvar o estado dos registradores do processo que deixar o processador e cara regar os registradores para o novo processo. O algoritmo FIFO o mais simples e de implementao mais fcil. No ene ca a tanto, no dos mais eciente no quesito tempo de resposta. Caso um processo a e muito grande tome posse do processador, outros processos podem ter que esperar um tempo muito longo at que possam executar. e O algoritmo Shortest Job First d posse do processador ao processo que a gastar menos tempo executando. O tempo de resposta mdio otimizado em a e e relao ao FIFO, no entanto, essa pol ca tica no pode ser implementada de forma a perfeita uma vez que no poss determinar quanto tempo um processo gasa e vel tar no processador na prxima vez em que tomar posse. Implementaes do a o co SJF estimam esse tempo utilizando informaes passadas do processo. co Os algor timos Round-Robin consistem em dividir o tempo de processamento em fatias de tempo chamadas time slots. Cada processo na la de prontos tem direito de executar durante um per odo de tempo xo antes de perder a posse do processador. Um problema neste algoritmo a necessidade de determinar a e fatia de tempo ideal, de forma que a impresso de paralelismo na execuo no a ca a 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 so a base das pol a ticas de escalonamento nos sistemas operacionais modernos. A cada processo associada uma prioridade. O proe cesso de maior prioridade quem toma a posse do processador no momento e oportuno. Uma variante dos algoritmos de prioridades pura, so os os algoa ritmos de Prioridade com Preempo. Neste esquema, um processo da la de ca prontos que tenha prioridade maior que o processo em execuo pode tomar ca 49
posse do processador antes do processo em execuo terminar de executar. ca Na verdade, nos sistema operacionais, no s um algoritmo de escalonamento a o utilizado na gerncia de processador. Usualmente, esse algoritmos so come e a binados de forma melhorar o desempenho do sistema. Algoritmos de mltiplas u las com realimentao so exemplos de combinao de vrias pol ca a ca a ticas. Esses algoritmos permitem que seja dado um tratamento adequado ` um determinado a processo de acordo com o seu comportamento. Em gerncia de processador existem tambm os conceitos de execuo em e e ca Background e Foreground. Processos em background so geralmente so aquea a les que esto rodando com uma prioridade muito baixa, necessitam de muito a pouco input e geram tambm um m e nimo de output. Processos em foreground funcionam da forma oposta. O escalonador responsvel por determinar qual processo receber o direito de a a executar chamado Escalonador de Curto Prazo. Existem tambm os escalone e adores de Longo e Mdio Prazo. O escalonador de Mdio Prazo parte por e e e exemplo do processo swapper e est intimamente ligado a gerencia de memria, a o enquanto o escalonador de longo prazo determina quando um processo novo de fato admitido no sistema para disputa dos recursos. E o escalonador de e longo prazo quem determina o grau de multiprogramao do sistema e tambm ca e conhecido como Job Scheduller. e
4.4
Entrada e Sa da
Uma das atribuies dos sistemas operacionais realizar a gerncia de perifricos, co e e e tambm conhecida como gerncia de entrada e sa e e da. Os perifricos so dispose a itivos que permitem que o computador se comunique com o mundo externo. A primeira preocupao dos sistemas operacionais no que diz respeito a gerncia ca e de E/S a forma de comunicao que ser utilizada, que pode ser serial ou e ca a paralela. As trs formas bsicas de se implementar o controle de perifricos so: e a e a E/S programada: O controle dos estado da operao de E/S feito atravs ca e e de loops de status. A responsabilidade do programador; A tcnica utie e lizar o estado da operaao de E/S utilizada E/S programada conhecida c e como polling; Interrupes: Os perifricos chamam a ateno do processador atravs co e ca e de um sinal de hardware. Cabe ao processador identicar, priorizar e mascarar as interrupes geradas pelos perifricos; co e Acesso Direto ` Memria (DMA): Em situaes em que o volume de dados a o co muito grande, utiliza-se esta tcnica para permitir que perifricos tenham e e e acesso direto a memria sem a necessidade da intermediao por parte do o ca processador. O localizao dos perifricos do ponto de vista da arquitetura do sistema ca e pode ser feita de basicamente de duas maneiras: Mapeamento em Memria e o
50
Espao de E/S. Os drivers de dispositivos consistem em uma camada superior c ao hardware e tm por objetivo esconder as diferenas entre dispositivos de e c mesmo tipo. Existe tambm a necessidade de se empregar tcnicas de escalonamento de e e E/S de forma otimizar o atendimento das requisies feitas aos perifricos. Nos co e discos magnticos, por exemplo, so utilizados algoritmos de escalonamento e a como: FCFS: First Come Fisrt Served. chegada; Atende as requisies na ordem de co
SSTF: Shortest Seek Time First. Atende primeiro as requisies que neco cessitam de menor tempo de seek (seek time o tempo necessrio para e a mover o cabeote para a trilha adequada); c SLTF: Shortest Latency Time First. Atende primeiro as requisies de co menor latncia (latncia o tempo necessrio para localizar um setor e e e a dentro de uma trilha do disco. Diretamente relacionado com a velocidade de rotao do disco.); ca Scan: Varre o disco na direo radial atendendo requisies. S atende ca co o requisies em um sentido; co CScan: Similar ao Scan, porm atende requisies na subida e na descida. e co Alm de pol e ticas de escalonamento de E/S, tambm so utilizadas tcnicas e a e de Buer e Cache para aumentar o desempenho. A tcnica empregada para e realizar a alocao e liberao de recursos conhecida como Spooling. A gerncia ca ca e e de perifricos tambm se responsabiliza pelo controle de acesso aos perifricos e e e e tratamentos de erros.
4.4.1
Camadas do subsistema de Entrada e Sa da
O objetivo do subsistema de entrada e sa padronizar ao mximo as rotinas da e a de acesso aos perifricos de forma a reduzir o nmero de rotinas de entrada e e u sa da. Para isso, o subsistema de entrada e sa organizado em uma estrutura da e de quatro camadas: hardware dos dispositivos de entrada e sa da, os drivers, a E/S independente de dispositivo e E/S n vel de usurio. A gura 4.3 mostra a essas camadas.
A camada inferior de software (drivers) composta por um conjunto de e mdulos de software implementados para fornecer os mecanismos de acesso a o um dispositivo de entrada e sa espec da co. A camada de software de E/S independente do dispositivo implementa procedimentos e funes gerais a todos co os dispositivos de entrada e sa como: escalonamento de E/S, denominao, da ca buerizao, cache de dados, alocao e liberao, direitos de acesso e tratamenca ca ca tos de erro. A E/S n de usurio uma interface de programao associada vel a e ca a `s bibliotecas de entrada e sa da, ou aplicativos de desenvolvimento. E importante notar que as bibliotecas de entrada e sa no fazem parte do sistema da a operacional.
51
Figura 4.3: Camadas do Subsistema de E/S
4.5
Gerncia de Memria e o
Umas das funes fundamentais de um sistema operacional moderno realizar a co e gerencia da memria principal do computador de forma permitir que os diversos o processos executem de forma eciente e protegida. Quando o assunto gerncia e e de memria, dois conceitos bsicos so os de memria lgica e memria f o a a o o o sica. Os programas fazem referncia ` endereos lgicos que no momento da execuo so e a c o ca a traduzidos em um endereo real chamado endereo f c c sico. As primeiras tcnicas e de traduo de endereos eram baseadas em registradores de base e limites. ca c Nos sistemas multiprogramados, necessrio tambm implementar tcnicas e a e e para que os diversos programas possam utilizar a memria ao mesmo tempo. Inio cialmente, a memria era dividida em parties de tamanho xo. Dois problemas o co decorrentes desta tcnica so conhecidos como Fragmentao Interna e a Frage a ca mentao Externa. A fragmentao interna ocorre quando um programa aloca ca ca uma partio de memria que excede a quantidade necessria. O espao exceca o a c dente naquela partio desperdiado. A fragmentao externa ocorre quando ca e c ca apesar da quantidade total de memria ser suciente, no existe uma partio o a ca cont gua capaz de atender as necessidades de um programa. Para solucionar o problema da fragmentao interna, foi criado o mecanismo ca de particionamento dinmico, no qual um programa aloca somente a quantidade a exata de memria. No entanto, esse mtodo aumenta a fragmentao externa o e ca uma vez que permite o aparecimento de lacunas pequenas demais para serem utilizadas por algum programa. Neste mtodo de particionamento so utilizadas e a vrias tcnicas de preenchimento de lacunas. Exemplos so: First-Fit, Best-Fit, a e a Worst-Fit e Circular-Fit. Para evitar o aparecimento de lacunas muito pequenas, foi criada uma tcnica chamada Pargrafo, que consiste em determinar a e a menor unidade de alocao de memria. ca o Todas as tcnicas apresentadas at aqui levam em considerao o fato de e e ca que os programas devem ocupar reas cont a guas de memria. Os sistema opo eracionais modernos supriram esta necessidade atravs da tcnica de Paginao. e e ca Aqui aparecem os conceitos de pginas lgicas e pginas f a o a sicas, semelhantes aos de endereos lgicos e f c o sicos. Neste contexto, o endereo lgico formado c o e
52
por duas partes que so o nmero da pgina mais o deslocamento dentro dela. a u a Existe tambm a necessidade de traduzir uma pgina lgica em uma pgina e a o a f sica. A Tabela de Pginas a responsvel por essa tarefa. Existem vrias a e a a formas de implement-la. a A primeira preocupao onde armazenar a tabela de pginas. Em sistemas ca e a com tabelas muito pequenas, as tabelas de pginas podem ser armazenadas a em registradores, no entanto, em geral a tabela de pginas armazenada na a e prpria memria principal utilizando registradores (PTBR e PTBL) para ino o dicar a posio da tabela na memria. Um problema inerente a esta tcnica ca o e a necessidade de se acessar a memria duas vezes quando se deseja ler um e o dado. Um acesso a tabela de pginas e outra ao dado em si. Para minimizar a este problema utilizado um mecanismo chamado Translation LookAside Buer e (TLB). O TLB consiste em uma memria de rpido acesso que armazena partes o a da tabela de pginas. Quando a traduo de uma pagina lgica em uma pgina a ca o a f sica poss e vel utilizando apenas o TLB, dito que ocorreu um HIT, caso e contrrio dizemos que ocorreu um MISS. a A tcnica de Segmentao utilizada para implementar a proteo de ene ca e ca dereos de memria utilizados por um processo. Usualmente isso feito atravs c o e e de registradores de limite. Quando um processo tenta acessar uma regio de a memria protegida ocorre uma falha de segmentao (Segmentation Fault). Esta o ca tcnica no deve ser confundida com a tcnica de segmentao de memria pree a e ca o sente em algumas arquiteturas, onde a memria dividida em partes como o e Segmento de Dados, Segmento de Cdigo, Pilha etc. o O Swapping uma outra tcnica utilizada para gerenciamento de memria. e e o Nesta tcnica, um processo suspenso e todas suas pginas de memria so e e a o a descarregadas para o disco (swap-out), liberando a memria para que algum o outro processo possa executar. Quando processo suspenso pode voltar para memria, as pginas do processo so novamente carregadas para a memria o a a o (swap-in). O swapper responsvel pelo swap-in e swap-out. e a Na tcnica de paginao pura, o processo no precisa mais ocupar um tree ca a cho cont guo de memria, no entanto, ainda necessrio que todas as pgina o e a a de um processo estejam carregadas na memria no momento da execuo. Uma o ca evoluo do esquema de paginao a tcnica de Memria Virtual. Memria ca ca e e o o Virtual consiste em um esquema de paginao sob demanda, no qual somente ca as pginas necessrias para a execuo de um processo so carregadas para a a a ca a memria. o Alm de aumentar o desempenho do sistema, esta tcnica permite que exe e istam programas com espao de endereamento lgico maiores. Para indicar c c o se uma pgina se encontra ou no carregada na memria em um determinado a a o instante, utilizado um bit adicional para cada entrada da tabela. Quando um e processo tenta acessar uma pgina que no est carregada na memria dito a a a o e que ocorreu um page-fault. O processo ento suspenso e at que esteja pronto e a e para executar novamente ocorre a seguinte seqncia de eventos: ue
53
1. Alocao de uma pgina f ca a sica; 2. Localizao da Pgina F ca a sica no Disco; 3. Leitura da Pgina no Disco; a 4. Atualizao da Tabela de Pginas; ca a 5. Processo vai para la de pronto. O responsvel por carregar a pgina solicitada o pager. Para carregar a a e uma nova pgina lgica para memria muitas vezes necessrio descarregar a o o e a uma pgina para o disco. Os algoritmos de substituio de pginas so os a ca a a responsveis por decidir qual pgina ser escolhida para deixar a memria. Exa a a o emplos de algoritmos de substituio de pgina so: ca a a FCFS: Escolhe a pgina que est a mais tempo na memria; a a o Otimo: Escolhe a pgina que vai ser acessada mais remotamente no futuro a (no implementvel); a e a LRU: Escolhe a que a mais tempo no acessada (obs: algoritmo implea e mentado por histrico de bits); o Second Chance: Organiza pginas em forma de um la circular e utiliza a bits de controle. O Trashing a situao em que um processo possui poucas pginas f e ca a sicas e o tempo gasto em page-faults muito alto, predominando no tempo total de e processamento. Uma forma de solucionar este problema utilizar a tcnica de e e swap para permitir que o processo possa executar de forma satisfatria. o
4.6
Sistemas de Arquivos
O sistema de arquivos a parte do sistema operacional mais vis e vel para os usurios. Durante todo tempo, os usurios manipulam arquivos contento texa a tos, planilhas, desenhos, guras, 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 diretrio. o
4.6.1
Conceitos bsicos sobre arquivos a
Um arquivo um recipiente no qual dados so armazenados. Em geral, cada e a arquivo contm um conjunto de dados que possui algum signicado prtico para e a o usurio ou para o sistema. Um arquivo pode conter um programa executvel, a a um mdulo de um programa fonte, um texto, uma gura, etc. Cada arquivo o e identicado por um nome, o qual permite que o usurio faa referncias a ele. a c e Alm do nome, cada arquivo possui uma srie de outros atributos que so mane e a tidos pelo sistema operacional como tipo de contedo, tamanho, data e hora u do ultimo acesso, data e hora da ultima alterao, lista de usurios que podem ca a 54
acessar o arquivo, etc. Em geral, o sistema operacional suporta diversas operaes sobre os arquivos, co como criao e destruio do arquivo, leitura e alterao do contedo, troca de ca ca ca u nome do arquivo, etc. Essas operaes correspondem a chamadas de sistema co que os programas de usurio podem usar para manipular os arquivos. a Em sistemas multiusurios, importante controlar o acesso aos arquivos. a e Sistemas operacionais multiusurios implementam mecanismos que permitem a controlar quais os usurios podem fazer o que em quais arquivos. a O controle de acesso inicia com a identicao dos usurios por meio de um ca a cdigo de usurio e uma senha. A partir do momento que a identicao do o a ca usurio aceita, todos os processos disparados a partir do terminal em questo a e a passam a ter os direitos de acesso associados com aquele usurio. E poss a vel associar a cada arquivo uma lista de usurios e direitos de acesso. A forma a usual permitir que apenas o usurio que criou o arquivo possa alterar a lista e a contendo os direitos de acesso do arquivo. A forma como os dados so dispostos dentro de um arquivo determina sua a estrutura interna. Cada tipo de arquivo possui uma estrutura interna apropriada para a sua nalidade. Por exemplo, arquivos de texto so organizados em a linha ou pargrafos. Arquivos que contm programas executveis so organizaa e a a dos em termos de segmento de cdigo e segmentos de dados. o Em geral, os sistemas operacionais ignoram a estrutura interna dos arquivos. Para o sistema operacional, cada arquivo corresponde a uma seqncia de bytes, ue cujo signicado conhecido pelo usurio que o criou. A unica exceo so os e a ca a arquivos que contm programas executveis. Nesse caso, a estrutura interna e a e denida pelo prprio sistema operacional. Como o conceito de tipo de arquivo o e util para os usurios, muitos sistemas operacionais suportam nomes de arquivos a onde o tipo indicado. A forma usual acrescentar extenso de nome que e e a identique o tipo de arquivo em questo. a O mtodo de acesso diz respeito ` forma como o contedo de um arquivo e a u acessado. O mtodo de acesso mais simples o seqencial. Este mtodo e e e u e e usado pelos compiladores, para a impresso de um arquivo, etc. Outro mtodo a e de acesso o acesso relativo. Neste mtodo, o programa inclui na chamada de e e sistema qual posio do arquivo a ser lida. As posies do arquivo so numerca co a adas a partir de 0 (ou a partir de 1 em alguns sistemas), sendo que cada posio ca corresponde a um byte. Em muitos sistemas operacionais, existe o conceito de posio corrente no ca arquivo. Nesse caso, a chamada de sistema para leitura ou escrita no informa a uma posio. Essa sempre acontece a partir da posio corrente. O sistema opca ca eracional tambm permite que o programa altere a posio corrente do arquivo e ca por meio de uma chamada de sistema. Existem outros mtodos de acesso mais sosticados, tais como seqencial e u indexado, indexado, direto, etc. Tais mtodos de acesso so implementados a e a 55
partir dos mtodos seqencial e relativo. e u
4.6.2
Implementao de arquivos ca
A forma bsica de implementar arquivos criar, para cada arquivo no sistema, a e um descritor de arquivo. O descritor de arquivo um registro no qual so e a mantidas as informaes a respeito do arquivo. Essas informaes incluem os co co seus atributos, alm de outros dados que no so vis e a a veis aos usurios, mas so a a necessrios para o que o sistema operacional implemente as operaes sobre os a co arquivos. Um descritor de arquivo contm as seguintes informaes: nome do arquivo, e co extenso do nome do arquivo, tamanho em byte, data e hora do ultimo acesso, a data e hora da ultima alteraao, identicao do usurio que criou o arquivo, lo c ca a cal no disco onde o contedo do arquivo foi alocado, etc. A forma usual manter u e o descritor de um arquivo na mesma partio onde est o seu contedo. Dessa ca a u forma, esse disco poder ser at mesmo sicamente removido de um computador a e e conectado a outro. Os arquivos nele podero ser acessados normalmente no a novo computador. O descritor acessado a cada operao de escrita ou leitura para determinar e ca a localizao no disco dos dados a serem escritos ou lidos. Para tornar mais ca rpido o acesso aos arquivos, o sistema de arquivos mantm na memria uma a e o tabela contendo todos os descritores dos arquivos em uso. Quando um arquivo entra em uso, o seu descritor copiado do disco para a memria. Quando o are o quivo deixa de ser usado, o seu descritor em memria pode ter sido alterado em o relao ` cpia do descritor em disco. Nesse caso, o sistema de arquivos escreve ca a o o descritor atualizado que est na memria sobre a cpia original do descritor a o o em disco. A maioria dos sistemas operacionais exige que os prprios programas o informem quando um arquivo entra em uso e quando ele no mais necessrio. a e a Para tanto, existem as chamadas de sistema open e close. Tambm util passar e e como parmetro o tipo de acesso que ser feito, isto , leitura (READONLY ou a a e RD) ou leitura e escrita (READWRITE ou RW). O sistema de arquivos utiliza uma Tabela de Descritores de Arquivos Abertos (TDAA) para manter em memria os descritores dos arquivos abertos. A o TDAA mantm informaes relativas aos arquivos abertos por todos os procese co sos no sistema. Isso necessrio porque normalmente permitido que vrios e a e a processos abram um mesmo arquivo simultaneamente. Cada entrada armazena uma cpia do descritor do arquivo mantido em disco, assim como algumas ino formaes adicionais, necessrias apenas enquanto o arquivo est aberto. Por co a a exemplo, nmero de processos utilizando o arquivo no momento. u As entradas da TDAA armazenam informaes que no variam conforme co a o processo que est acessando o arquivo. Entretanto, existem informaes dia co retamente associadas com o processo que acessa o arquivo. Essas informaes co no podem ser mantidas na TDAA, pois como vrios processos podem acesa a sar o mesmo arquivo, elas possuiro um valor diferente para cada processo. Um a exemplo de informao que depende do processo a posio corrente no arquivo. ca e ca 56
Uma soluo t ca pica criar, para cada processo, uma Tabela de Arquivos e Abertos por Processo (TAAP). Cada entrada ocupada na TAAP corresponde a um arquivo aberto pelo processo correspondente. No m nimo, a TAAP contm e em cada entrada as seguintes informaes: posio corrente no arquivo, tipo de co ca acesso (leitura ou leitura e escrita) e apontador para a entrada correspondente na TDAA. A gura 4.4 mostra as tabelas TDAA e TAAP. Toda TDAA como as TAAP devem car na memria do sistema operacional, fora do acesso dos o processos de usurio. a
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 contedo. No necessrio, nem conveniente, u a e a que a cada chamada de sistema, o processo fornea novamente o nome do arc quivo. Como resultado de um open com sucesso, o sistema de arquivos retorna para o processo o nmero da entrada na TAAP associada com o arquivo aberto. u Dessa forma, nas chamadas de sistemas aps o open, o processo indica o aro quivo atravs do nmero de sua correspondente entrada na TAAP. A partir da e u TAAP, o sistema de arquivos pode imediatamente localizar o descritor no arquivo TDAA. Muitos sistemas operacionais chamam esse nmero de handle do u arquivo. Existem duas funes importantes que o sistema de arquivos deve realizar co na implementao das chamadas de sistema read e write. So elas a montagem ca a e desmontagem de blocos lgicos e a localizao dos blocos lgicos no disco. Eso ca o sas funes so implementadas baseando-se em trs formas bsicas de alocao co a e a ca de arquivos: alocao com reas cont ca a guas, alocao encadeada e a alocao ca ca indexada.
4.6.3
Cache de Sistema de Arquivos
Uma importante estrutura de dados presente na implementao de um sistema ca de arquivos a sua cache. A cache no oferece nenhuma funcionalidade nova, e a isto , a presena ou ausncia de uma cache no adiciona ou elimina nenhuma e c e a
57
funo, chamada de sistema ou operao sobre arquivos. Entretanto, caches repca ca resentam um grande aumento no desempenho de qualquer sistema de arquivos, pois o uso do disco tente a ser intenso em sistemas operacionais de propsito o gerais. O objetivo do cache manter na memria principal uma certa quantie o dade de blocos do disco. Dessa forma, se algum bloco for requisitado para leitura ou escrita, ele ser encontrado na memria principal, evitando o acesso ao disco. a o A cache do sistema de arquivos utiliza uma rea da memria principal e a o e controlada pelo sistema operacional. Na verdade, existem diversos locais onde uma cache de disco pode ser mantida. E poss haver uma cache global, uma vel cache exclusiva para cada sistema de arquivos, etc. A forma bsica de operaao bem simples. Toda vez que um bloco de disco a c e necessrio para leitura e/ou escrita, a cache pesquisada. Se o bloco estiver e a e na cache, essa cpia usada. Se o bloco no estiver na cache, ele lido do disco, o e a e colocado na cache e ento utilizado. a Uma questo importante quando atualizar o disco aps um bloco presente a e o na cache ter sido alterado. Do ponto de vista de desempenho, o ideal postere gar a atualizao do disco ao mximo no sentido de minimizar as escritas em ca a disco. Por outro lado, caso ocorra uma pane do sistema, toda a informao na ca cache ser perdida, o disco car desatualizado e, possivelmente, o sistema de a a arquivos car corrompido. Existem diversas pol a ticas que podem ser utilizadas. Uma cache de sistema de arquivo pode possuir milhares de blocos, o que torna invivel uma pesquisa seqencial da mesma para localizar determinado a u bloco. Dada a natureza dinmica dessa estrutura e sua importncia para o dea a sempenho do sistema como um todo, uma tabela hash utilizada. O sistema de e arquivos fornece o nmero da partio e o nmero do bloco, e uma funo hash u ca u ca e utilizada para determinar o endereo do bloco na cache, caso ele esteja na cache. c Eventualmente, a cache pode se encontrar completamente ocupada, sendo necessrio liberar espao para algum outro bloco. A soluo t a c ca pica escolher e um bloco da cache, atualizar o seu contedo no disco se necessrio, declarar esse u a bloco da cache como livre e utiliz-lo para hospedar um novo bloco de disco. A a pol tica para escolher o bloco da cache a ser liberado geralmente a LRU (Least e Recently Used ).
4.6.4
Gerenciamento do espao livre c
Uma das tarefas do sistema de arquivos gerenciar o espao livre nos discos. e c Em outras palavras, determinar quais setores do disco esto livres e podem a ser alocados para aumentar o tamanho de um arquivo. Uma forma simples de gerenciar o espao livre em disco por meio de um mapa de bits. A gura 4.5 c e mostra esse mecanismo. Cada bit presente no mapa representa um bloco f sico do disco. Os bits so a considerados numerados da direita para esquerda, isto , o bit menos signicae tivo do primeiro byte o bit nmero zero. Bit ligado indica bloco ocupado, e u 58
Figura 4.5: Mapa de bits para gerenciamento de espao livre c e bit desligado indica bloco livre. O endereo do bloco representado por um c determinado bit denido pela prpria posio do bit dentro do mapa. e o ca Para alocar mais um bloco f sico para um arquivo, basta percorrer o mapa de bits at encontrar um bit zero. O bit ento ligado para indicar que o e e a respectivo bloco agora est ocupado. Quando um arquivo destru e seus a e do blocos liberados, basta desligar os bits correspondentes. O mapa de bits deve ser mantido na memria principal para que a busca seja rpida. o a O espao livre em disco tambm pode ser gerenciado por meio de uma lista c e contendo os nmeros de todos os blocos f u sicos livres (Lista de Blocos Livres). Como essa lista grande no caso de um disco quase vazio, ela deve ser mantida e no prprio disco. Para acelerar o processo de alocao e liberao de blocos o ca ca f sicos, alguns blocos da lista so copiados para a memria principal. Logo, soa o mente ser necessrio acessar o disco quando todos os endereos de blocos livres a a c copiados para a memria principal tiverem sido alocados. Ou ainda, quando o remoes de arquivos liberarem blocos f co sicos em tal quantidade que alguns blocos de endereos tenham que ser escritos em disco. Alguns sistemas operacionais c atualizam periodicamente a lista de endereos em disco para minimizar a corc rupo do sistema de arquivos em caso de falha no computador. ca
4.6.5
Diretrios o
Os diretrios so as estruturas do sistema de arquivos que contm a informao o a e ca quais arquivos existem no disco. Um diretrio pode ser entendido como sendo o um conjunto de arquivos ou um conjunto de referncias a arquivos. Existem e diversas formas de estruturar os diretrios de um sistema. A mais simples ter o e um unico diretrio para o disco inteiro. Nesse caso, o diretrio corresponde a o o uma lista de todos os (possivelmente milhares) arquivos do disco. Essa soluo, ca conhecida como diretrio linear, aceitvel apenas para sistemas de arquivo o e a muito pequenos. Por exemplo, pode ser utilizada para discos ex veis de pequena capacidade.
59
Para sistemas multiusurios, o diretrio linear problemtico, pois os ara o e a quivos de diferentes usurios cam misturados. Esse problema pode ser rea solvido com uma estrutura de diretrios organizada em dois n o veis. O diretrio o principal contm uma entrada para cada usurio do sistema. Essa entrada no e a a corresponde a um arquivo, mas sim a um subdiretrio que, por sua vez, contm o e os arquivos do usurio correspondente. Tambm necessrio criar no diretrio a e e a o principal uma entrada para conter os arquivos do sistema. As entradas do diretrio principal so usualmente chamadas de subdiretrios. o a o E poss estender o conceito de subdiretrios de tal forma que os usurios vel o a tambm possam criar livremente os seus prprios subdiretrios. Dessa forma, e o o cada usurio tem a liberdade de organizar os seus arquivos de forma lhe for a mais conveniente. O resultado um sistema de diretrios organizado na forma e o de rvore conforme a gura 4.6. a
Figura 4.6: Diretrio organizado em forma de rvore o a Em um sistema de diretrios organizado na forma de rvore, qualquer aro a quivo ou subdiretrio pode ser identicado de forma no amb o a gua por meio do caminho (pathname) para atingi-lo a partir da raiz da rvore. Facilmente, a a rvore de diretrio cresce at uma altura tal que passa a ser desconfortvel a o e a fornecer sempre o caminho completo at cada arquivo ou diretrio. O conceito e o de diretrio corrente facilita a identicao de arquivos nesse contexto. Dessa o ca forma, um arquivo pode ser identicado por seu caminho absoluto, que inicia a raiz da rvore, ou pelo seu caminho relativo, que inicia no diretrio corrente do a o usurio em questo. a a Uma exibilidade adicional presente em muitos sistemas operacionais est a na possibilidade de incluir o mesmo arquivo ou subdiretrio em vrios diretrios. o a o Dessa forma, o mesmo arquivo passa a ter diversos nomes absolutos (mesmo na a rvore, cada arquivo possui diversos nomes relativos, uma vez que o caminho relativo depende do diretrio corrente em questo. Essa facilidade denomio a e nada de link e efetivamente transforma a estrutura de diretrios em um grafo. o
60
4.6.6
Implementao de diretrios ca o
A forma mais simples de implementar diretrios consider-lo como arquivos o e a especiais, cujo contedo manipulado pelo prprio sistema operacional. Dessa u e o forma, todo o mecanismo de alocao, liberao e localizao de blocos f ca ca ca sicos no disco, dispon para arquivos, tambm usado para os diretrios. Diretrios vel e e o o passam a ser arquivos cujo contedo denido pelo sistema operacional e cujo u e acesso controlado por parte do usurio. e a Como diretrios so implementados como arquivos, cada diretrio possui o a o tambm seu descritor. Os diretrios so implementados como conjunto de dee o a scritores de arquivos, ou conjuntos de endereos de descritores de arquivos. c Quando diretrios so implementados como conjunto de descritores de arquivos, o a o contedo de um diretrio corresponde aos descritores dos arquivos e dos subu o diretrios contidos naquele diretrio, conforme a gura 4.7. Nesse caso, o nome o o do arquivo ou subdiretrio faz parte do seu descritor. o
Figura 4.7: Diretrios contendo descritores de arquivos o Outra possibilidade separar um conjunto de blocos da partio para are ca mazenar exclusivamente os descritores de arquivos e de subdiretrios. Esse o conjunto de blocos forma um vetor de descritores, no qual cada descritor pode ser identicado pelo nmero da partio e pela posio nesse vetor. Essa estruu ca ca tura de dados forma o que normalmente conhecido como um at le system, e pois os descritores no incluem nomes, no existe nenhuma estruturao dos ara a ca quivos em diretrios, apenas um diretrio unico (vetor) e arquivos identicados o o pela posio do vetor. ca Em qualquer soluo, cada diretrio nada mais que uma tabela. Existem ca o e diversas implementaes poss co veis para tabelas que podem ser usadas na implementao de um diretrio. Entre elas, destaca-se a lista no ordenada, lista ca o a ordenada e a tabela hash.
4.7
Sistemas Operacionais Distribu dos
Um sistema distribu uma coleo de computadores independentes que paredo e ca cem ao usurio como um unico computador. Essa denio implica hardware a ca 61
formado por mquinas autnomas e software fornecendo a abstrao de uma a o ca mquina unica. As principais vantagens so: a a Econmicas: aproveitar mquinas potencialmente ociosas; mais barato o a vrios processadores interconectados do que um supercomputador. a Distribuio inerente: algumas aplicaes so distribu ca co a das por natureza. Tolerncia a falhas: em caso de falha de uma mquina, o sistema como a a um todo pode sobreviver, apresentando apenas uma degradao de deca sempenho. Crescimento incremental: o poder computacional pode ser aumentado atravs da incluso de novos equipamentos. e a Flexibilidade: sistemas distribu dos so mais ex a veis do que mquinas a isoladas, por isso muitas vezes so utilizados at mesmo que no se esa e a teja buscando desempenho. E essa exibilidade que permite que vrios a usurios compartilhem dados e perifricos. a e E as desvantagens: Pouco software de alto n dispon para sistemas distribu vel vel dos. Diculdades para evitar acesso indevido (segurana). c A rede de interconexo pode causar problemas ou no dar vazo a dea a a manda. Sistemas distribu dos consistem de vrias CPUs interconectadas. No ena tanto, h vrias formas diferentes no qual esse hardware pode estar organizado. a a Dentre as vrias classicaes existentes, Flynn prope uma taxonomia cona co o siderando o nmero de uxo de instrues e o nmero de uxo de dados. u co u SISD(Single Instruction Single Data): uxo de instrues e dados unico co e a caracter stica dos uniprocessadores tradicionais MIMD(Multiple Instructions Multiple Data): caracteriza-se por vrios a processadores interconectados. Tanembaum apresenta a seguinte subclassicao, onde os dois primeiros so denidos em relao a organizao da ca a ca ca memria e os dois ultimos em relao a forma de interconexo: o ca a
Multiprocessador: mquinas MIMD com memria compartilhada (um a o unico espao de endereamento virtual compartilhado por todas as c c CPUs). Multicomputador: mquinas que no possuem memria compartila a o hada, isto , cada processador possui sua memria privada. e o Barramento: um unico cabo, rede, barramento ou outro meio que conecte todas as mquinas. Analogia: TV a cabo. a Switch: existem cabos individuais conectando mquina a mquina, a a com vrios padres poss a o veis.
62
Outra classicao: Fortemente acoplado(Tightly Coupled): comunicao ca ca rpida entre os processadores (grande nmero de bits por segundo). Fracamente a u acoplado(Loosely Coupled): atraso para troca de mensagem entre mquinas a e alto. Com a criao de novas arquiteturas de computadores, surgiram novas deca mandas de software e, em especial, novas funes exigidas ao S.O. Pode-se conco siderar como uma boa classicao da evoluo dos Sistemas Operacionais a ca ca tabela abaixo. A tabela 4.1 apresenta uma comparao entre as caracter ca sticas dos S.O modernos
Gerao ca 1a Sistema SO Centralizado Caracter stica Gerenciamento de Processos Gerenciamento de Memria o Gerenciamento de E/S Gerenciamento de Arquivos Acesso Remoto Troca de Informaes co Navegao na rede ca Viso global do Sistema de a arquivos, Espao de nomes c Tempo, Segurana c Poder Computacional Aplicaes Distribu co das Abertas e Cooperativas Objetivo Gerenciamento de recursos Memria estendida o Virtualidade Compartilhamento de recursos Interoperabilidade Viso de computador a Unico em sistema de Mltiplos u Computadores Transparncia e Trabalho cooperativo Autonomia
2a
SO de Rede
3a
SO Distribu do
4a
SO Cooperativo Autnomo o
Tabela 4.1: Sistemas Operacionais
4.7.1
Estruturao de Sistemas Distribu ca dos
Estruturao baseada na distribuio f ca ca sica Dentre os vrios modelos baseados da distribuio f a ca sica, encontram-se o modelo hierrquico, o do cache de CPU, o usurio servidor e o modelo de conjunto de a a processadores. No modelo hierrquico, os computadores so dispostos em uma rede sob a a a forma de rvore, de maneira que quanto mais prximos estiverem da raiz, mais a o potentes devero ser. O computador da raiz tratar, de forma geral, do sistema a a como um todo, enquanto que os computadores distantes da raiz trataro de a tarefas espec cas e especializadas. O modelo de cache de CPU consiste na utilizao de computadores de menor ca porte como elementos que interligam terminais com uma grande CPU. Nesse caso, uma parte do processamento ser executada no computador ligado ao a terminal, e a outra parte no computador central. O modelo usurio-servidor(cliente/servidor) surgiu na medida em que os a computadores pequenos, crescendo em potncia e tendo seus preos reduzidos, e c diminu ram gradativamente a importncia do computador central do modelo a cache de CPU.
63
Estruturao Lgica ca o Modelo de processos: Esses processos podem encapsular tanto elementos ativos com natureza, consistindo dos programas referentes `s atividades do sistema e do usurio quanto a a elementos naturalmente passivos correspondendo aos recursos e suas respectivas operaes, connados em gerenciadores de recursos. A comunicao entre os co ca processos, implementada pelo sistema operacional, pode ocorrer de duas formas: Chamada remota de procedimento: este tipo de comunicao entre proca cessos bastante dependente da linguagem usada para implementao e ca do sistema, devendo satisfazer suas restries com relao a chamada de co ca procedimento e a passagem de parmetros. a Troca expl cita de mensagem: este j mais ex a e vel do que o anterior, suas restries esto relacionadas com a existncia de ligaes impl co a e co citas ou expl citas entre os processos e com a interpretao da mensagem. ca Modelo de objetos: O modelo de objetos baseia-se no encapsulamento das vrias partes de um sisa tema em elementos denominados objetos que so estruturados de forma a aprea sentarem um conjunto de operaes responsveis pelo seu comportamento. Para co a conseguir acessar um objeto, um processo deve ter capacidade de faz-lo, usando e o conhecimento do nome do objeto e a posse da autorizao para cessar alguca mas ou todas as suas operaes. Cada objeto distribu no opera sozinho. A co do a princ ele constru para trabalhar com outros objetos e, para isso, precisa pio e do de uma espcie de barramento. Tais barramentos fornecem infra-estrutura e para os objetos, adicionando novos servios que podem ser herdados durante c a construo do objeto, ou mesmo em tempo de execuo para alcanar altos ca ca c n veis de colaborao com outros objetos independentes. CORBA um exemplo ca e de barramento.
64
Cap tulo 5
Principais Processadores de Mercado

5.1
5.1.1
Processadores Intel
Fam Pentium lia
Pentium 4 O processador Pentium 4 da Intel foi lanado em novembro de 2000, usando a c microarquitetura x86 de stima gerao da Intel, chamada Netburst, que veio e ca com um pipeline muito longo com a inteno de permitir clocks mais altos. ca Os processadores Pentium 4 podem encontrados em trs verses de ncleos: e o u Willamette, Northwood e Prescott. Os primeiros modelos de Pentium 4 utilizavam soquete 423, que, como o prprio nome j sugere, possu 423 terminais. Depois foram lanados modelos o a a c de Pentium 4 com soquete 478, que, apesar de possu rem mais contatos do que os modelos anteriores (soquete 423), eram sicamente 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 ncleo Willamette, u que tinha 8 KB de cache L1 para dados; 12 KB de cache L1 para instruo; ca 256 KB de cache L2; trabalhava externamente a 400 MHz (100 MHz transferindo quatro dados por pulso de clock); padro de pinagem soquete 423 a e 478; clock interno de 1,30 a 2 GHz; suporte a instrues MMX (oferece co um modelo de execuo SIMD (Single Instruction Multiple Data, ou seja, ca uxo unico de instrues e mltiplos de dados) simples, capaz de efetuar co u processamentos de dados inteiros, empacotados em registros de 64 bits. As instrues MMX melhoraram a execuo das assim chamadas tarefas co ca multim dias, como codicar e decodicar v deo), SSE (Streaming SIMD Extensions) e SSE2; tecnologia de construo de 180 nanmetro. ca o Northwood Em seguida vieram os modelos de Pentium 4 baseados no ncleo Northu
65
wood. Este ncleo cerca de 60% menor do que o ncleo Willamette devu e u ido ao seu processo de fabricao de 130 nanmetros. O ncleo Northwood ca o u possui 8 KB de cache L1 para dados; 12 KB de cache L1 para instruo; ca 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 instruoes MMX, SSE e SSE2. Alguns modelos possuem c suporte a tecnologia Hyper-Threading. Prescott O ncleo Prescott constru com tecnologia de 90 nanmetros utiu e do o e lizado nos processadores Pentium 4 modernos. Ele pode ser encontrado com 16 KB de cache L1 para dados; 12 KB de cache L1 para instruo; ca 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 a `s novas instrues MMX, SSE, SSE2 e SSE3. Alguns modelos possuem co 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 Vanderpool. A tecnologia VT permite que um processador funcione como se fosse vrios processadores trabalhando em paralelo de modo a permitir a que vrios sistemas operacionais sejam executados ao mesmo tempo em a uma mesma mquina. Embora o clock de um Prescott seja o mesmo de a 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 lanado em novembro de 2003 e foi o c primeiro processador para desktop a possuir o cache L3 integrado, caracter stica esta presente apenas em processadores voltados para o mercado corporativo. Este processador possui 2 MB de cache L3 sendo acessado na mesma freqncia de operao interna do processador. Os primeiros modelos de ue ca Pentium 4 Extreme Edition eram baseados no ncleo Gallatin, que tinha u 8 KB de cache L1 para dados; 12 KB de cache L1 para instruo; 512 KB ca 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 `s a instrues MMX, SSE e SSE2; tecnologia Hyper-Threading; tecnologia de co construo de 130 nanmetros. ca o Os modelos de Pentium 4 Extreme Edition atuais so baseados no ncleo a u Prescott 2M com tecnologia de 90 nanmetros. Possuem 16 KB de cache o L1 para dados; 12 KB de cache L1 para instruo; 2 MB de cache L2; no ca a possuem cache L3; trabalhava externamente a 1066 MHz (266 MHz transferindo quatro dados por pulso de clock); clock interno de 3,73 GHz; suporte `s instrues MMX, SSE, SSE2 e SSE3; tecnologia Hyper-Threading, a co EM64T.
66
Pentium D e Pentium Extreme Edition O processador Pentium D a verso de dois ncleos do Pentium 4, e o Pentium e a u Extreme Edition a verso do Pentium D com tecnologia HyperThreading hae a bilitada. Os processadores Pentium D e Pentium Extreme Edition podem ser encontrados em duas verses de ncleos: Smitheld e Presler. o u O Pentium D e o Pentium Extreme Edition so baseados na microarquitetura a x86 de stima gerao da Intel, chamada Netburst, ou seja, apesar do nome e ca diferente, eles so internamente um Pentium 4 (ou melhor, dois processadores a Pentium 4 em um unico encapsulamento). A diferena bsica entre o Pentium c a D e o Pentium Extreme Edition a ausncia da tecnologia HyperThreading nos e e processadores Pentium D. Smitheld Os processadores Pentium D e Pentium Extreme Edition da srie 800 so e a baseados no ncleo Smitheld. O ncleo Smitheld consiste na verdade u u em duas pastilhas de sil cio do ncleo Prescott montadas em um unico u processador. As principais caracter sticas dos processadores Pentium D da srie 800 so: e a tecnologia de ncleo duplo; 16 KB de cache L1 de dados por ncleo; 12 KB u u de cache L1 de instruo por ncleo; 2 MB de cache L2 (1 MB por ncleo); ca u u 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 `s instrues a co SSE3; soquete 775; processo de fabricao de 90 nm; tecnologia EM64T, ca XD e SpeedStep (modelos 840 e 830); e tecnologia Hyper-Threading nos processadores Pentium Extreme Edition. Os processadores Pentium D no tm esta tecnologia. a e Presler Os processadores Pentium D e Pentium Extreme Edition da srie 900 so e a baseados no ncleo Presler. u As principais caracter sticas dos processadores Pentium D e Pentium Extreme Edition da srie 900 so: tecnologia de ncleo duplo; 16 KB de e a u cache L1 de dados por ncleo; 12 KB de cache L1 de instruo por ncleo; u ca u 4 MB de cache L2 (2 MB por ncleo); barramento externo de 800 MHz u (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 `s instrues SSE3; soquete 775; processo de fabricao a co ca 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 no tm esta tecnologia. a e Pentium M O Pentium M o processador da Intel voltado para o mercado de notebooks e e utilizado pela plataforma Centrino. A plataforma Centrino da Intel um cone 67
junto de tecnologias desenvolvidas para notebooks e formada por trs compoe e nentes: Processador Pentium M Intel Chipsets 855 ou 915 Rede Wireless Intel/PRO Um notebook s pode ser considerado Centrino se ele possuir todos esses o trs componentes. O processador Pentium M da Intel foi lanado em maro de e c c 2003, usando a microarquitetura x86 de sexta gerao da Intel, ou seja, a mesma ca arquitetura usada pelos processadores Pentium Pro, Pentium II e Pentium III. Podem ser encontrados em duas verses de ncleos: Banias e Dothan. o u Banias Os primeiros modelos de Pentium M eram baseados no ncleo Banias, u que tinha 32 KB de cache L1 de instrues e 32 KB de cache L1 de co 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 instrues SSE2; tecnologia Enhanced SpeedStep; co tecnologia de construo de 0, 13m; padro de pinagem soquete 478 e ca a 479. Dothan O ncleo Dothan constru com tecnologia de 90 nanmetros utilizado u e do o e nos processadores Pentium M modernos. Ele possui 32 KB de cache L1 de instrues e 32 KB de cache L1 de dados; 2 MB de cache L2; trabalha co 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 instrues SSE2; tecnologia Enhanced SpeedStep, co Execute Disable (alguns modelos); padro de pinagem soquete 478 e 479. a
5.1.2
Fam Celeron lia
O nome Celeron utilizado pela Intel para designar sua linha de processadores de e baixo custo. Na verdade, o Celeron uma verso econmica dos processadores e a o topo de linha da Intel. Ou seja, o Celeron uma verso ?capada? do Pentium e a II, Pentium III ou do Pentium 4, com algumas caracter sticas reduzidas ou removidas. O Celeron diferencia-se do Pentium II, Pentium III ou do Pentium 4 em basicamente trs aspectos: e Tamanho do cache L2 Clock interno Clock do barramento externo Essas diferenas fazem com que o Celeron seja mais barato e tenha um dec sempenho menor do que os processadores Pentium II, Pentium III e Pentium 4, sendo, portanto, destinado para o mercado de usurios domsticos ou para a e aqueles que no necessitam de grande poder computacional. a
68
Existem vrios modelos de Celeron, mas atualmente o comercializado pela a Intel o Celeron D. O suxo D apenas para diferenci-lo das geraes anterie e a co ores. O Celeron D a verso topo de linha dos processadores Celeron. Esse proe a cessador baseado no Pentium 4 com ncleo Prescott e possui tecnologia de 65 e u e 90 nanmetros. o 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 instrues multim co dia SSE3, encapsulamento FCPGA e FC-LGA, padro de pinagem soquete 478 ou 775, e pode ser encontrado a com clocks de 2,13 GHz a 3,60 GHz. Por ser uma verso ?capada? do Pentium 4 a Prescott, que permite alcanar com maior facilidade freqncias mais elevadas, c ue o Celeron D no suporta a tecnologia Hyper-Threading, que permite simular a em um unico processador f sico dois processadores lgicos, e no possui ncleo o a u duplo. Alguns processadores Celeron D possuem a tecnologia EM64T (Extended Memory 64-bit Technology), que permite ao processador acessar mais memria o RAM, e a tecnologia XD (eXecute Disable), que impede que determinados tipos de v rus ataquem o micro. Antes do Celeron D, vieram alguns outros modelos: Celeron SEPP (Convington), Celeron A (Medocino), Celeron PPGA (Mendocino), Celeron Coppermine, Celeron Tualatin, Celeron Willamette, Celeron Northwood e o Celeron M.
5.1.3
Fam Core lia
Core Duo O Core Duo (conhecido anteriormente pelo nome-cdigo Yonah) o primeiro o e processador da Intel voltado para o mercado de notebooks a ter tecnologia de dois ncleos, isto , dentro dele h dois processadores completos. Curiosamente u e a este tambm o primeiro processador da Intel adotado pela Apple. e e Na realidade este processador um Pentium M com dois ncleos de proe u cessamento e constru com tecnologia de 65 nm (O Pentium M atualmente do e constru com tecnologia de 90 nm). do Apesar de ter dois ncleos de processamento dentro de um unico procesu sador, o tamanho do ncleo do Core Duo praticamente o mesmo do Pentium u e M (ncleo Dothan). Isto signica que o custo para a Intel produzir um Core Duo u quase o mesmo para produzir um Pentium M, que tem apenas um unico ncleo. e u O cache de memria L2 do Core Duo de 2 MB compartilhado entre o e os ncleos (a Intel chama esta implementao de cache L2 compartilhado de u ca Smart Cache, ou cache inteligente). No Pentium D 840, por exemplo, que e um processador de ncleo duplo, o tamanho do seu cache L2 de 2 MB, sendo u e 1 MB destinado para cada ncleo. Ou seja, no Pentium D existem dois cache u
69
L2 de 1 MB, um por ncleo. J no Core Duo, existe apenas um cache L2 de 2 u a MB que compartilhado entre os dois ncleos. e u Com o cache compartilhado, a quantidade de memria cache que cada ncleo o u utiliza no xa. Com um cache L2 de 2 MB, em um dado momento um ncleo a e u pode estar usando 1,5 MB de cache e o outro 512 KB (0,5 MB), por exemplo. Se em um processador de ncleo duplo com cache separado o cache L2 de um u ncleo acabe(isto , seu 1 MB est sendo totalmente usado), ele precisa ir ` u e a a lenta memria RAM buscar os dados, diminuindo o desempenho do sistema. No o caso do cache compartilhado, cada ncleo pode simplesmente redimensionaro u seu cache L2. Outra vantagem do cache L2 compartilhado que se um ncleo buscou um e u dado ou uma instruo e a armazenou no cache L2, esta mesma informao ca ca pode ser aproveitada pelo outro ncleo. Em processadores de ncleo duplo u u com memrias cache separadas o segundo ncleo teria de acessar este dado (ou o u instruo) atravs do barramento local do processador, isto , pelo lado de ca e e forado processador, usando o clock do barramento local, que muito inferior e ao clock interno do processador, diminuindo o desempenho do sistema. As principais caracter sticas do Core Duo so as seguintes: tecnologia de a ncleo duplo; Nome-cdigo: Yonah; 32 KB de cache L1 de instrues e 32 KB u o co de cache L1 de dados 2 MB de cache L2 compartilhado entre os dois ncleos; u Soquete 478 ou 479; tecnologia de 65 nm; barramento externo de 667 MHz (166 MHz transferindo quatro dados por pulso de clock); tecnologia de Virtualizao; tecnologia Execute Disable; tecnologia Enhanced SpeedStep; suporte `s ca a instrues SSE3. co Podemos dividir a plataforma Centrino em trs fam e lias. A primeira fam lia formada pelo processador Pentium M, chipset Intel 855/915 Express e rede e sem o Intel PRO/Wireless. A segunda fam formada pelo processador lia e Intel Core Solo (verso do processador Intel Core Duo, mas com um unico a ncleo de processamento ? at o momento somente um modelo de Core Solo foi u e lanado, T1300, rodando internamente a 1,66 GHz, externamente a 667 MHz, 2 c MB de cache L2), chipset Intel 945 Express e rede sem o Intel PRO/Wireless 3945ABG. J a terceira fam a lia, tambm conhecida como Centrino Duo (antes e chamada Napa), traz para os notebooks o poder computacional dos processadores de dois ncleos e formada pelo processador Intel Core Duo com clock u e interno de 1,50 a 2,16 GHz, chipset 945 Express e rede Intel PRO/Wireless 3945ABG. Core 2 Duo O Core 2 a gerao mais recente de processadores lanada pela Intel (os e ca c primeiros modelos foram lanados ocialmente em 27 de julho de 2006). A c chegada do Core 2 signica a substituio da marca Pentium, que estava sendo ca usada pela companhia desde 1993. Os modelos mais comuns e conhecidos dessa linha se chamam Core 2 Duo (com ncleo duplo), que substitui o Pentium 4 e o u Pentium D, mas existe tambm um modelo Core 2 Quad (com ncleo qudruplo) e u a e os modelos Core 2 Extreme (high end), que substitui o Pentium Extreme 70
Edition. O Core 2 Duo o primeiro processador para desktop a usar a nova microare quitetura Core. O lanamento do processador Core 2 Duo (nome-cdigo Conroe c o para desktop e Meron para portteis) marca o in de uma nova gerao de a cio ca processadores baseados na nova microarquitetura Core, e declara de uma vez por todas o m da microarquitetura Netburst usada desde 2000 pelos processadores Intel de 7a gerao. Como a microarquitetura Core baseada na arquitetura do ca e Pentium M e do Pentium III, podemos dizer que o Core 2 Duo um processador e Intel de 6a gerao. ca A diferena entre o Core 2 Duo e o Core 2 Extreme que este ultimo trac e 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 no confundir o processador Core 2 Duo com o Core Duo. O a Core Duo (conhecido anteriormente pelo nome-cdigo Yonah) o nome como e ercial para um Pentium M com dois ncleos de processamento constru com u do tecnologia de 65 nm. J o Core 2 Duo o nome comercial para o processador de a e nome-cdigo Merom (para notebooks) ou Conroe (para desktops), que utiliza a o nova microarquitetura Core da Intel. As principais caracter sticas tcnicas dos processadores da fam Core 2 e lia (Core 2 Duo e Core 2 Extreme) so as seguintes: arquitetura Core; 64 KB de a cache L1 (32 KB de dados + 32 KB de instrues) por ncleo; tecnologia de dois co u ncleos (o Core 2 Extreme QX6700 tem tecnologia de quatro ncleos); tecnolou u gia de 65 nm; soquete 775; barramento externo de 800 MHz (200 MHz transferindo 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 memria L2 compartilhado; tecnologia de Virtualizao (exceto o Core o ca 2 Duo E4300); tecnologia Intel EM64T; instrues SSE3 e SSSE3 (atualizao co ca 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 caracter sticas mencionadas anteriormente, mas com um barramento externo de 667 ou 533 MHz.
5.1.4
Xeon
Em 1998 a Intel estabeleceu uma distino entre seus processadores voltados ca para o mercado de servidores e estaes de trabalho dos voltados para o merco cado de usurios domsticos. Desde ento, a Intel passou a incluir o termo a e a Xeon(pronuncia-se z on) no nome dos processadores voltados para o mercado de servidores e estaes de trabalho. Esses processadores reconhecem mais co memria RAM, permitem trabalhar em ambiente multiprocessado (isto , com o e placas-me com vrios processadores instalados sobre ela) e possui um desema a 71
penho maior que os processadores voltados para o mercado domstico. e A Intel lanou verses para o mercado de servidores e estaes de trabalho c o co 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 usurios domsticos enquanto que o Pentium II a e Xeon era um processador voltado para o mercado de servidores e estaes de co 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 um processador voltado para o mercado de e servidores e estaes de trabalho baseado no Pentium 4. Atualmente, existem co 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 um processador voltado e para o mercado de servidores e estaes de trabalho baseado no Pentium 4, co sendo, portanto, um processador Intel de 7a gerao. Como vimos, os procesca sadores anteriores da srie Xeon usavam a arquitetura Intel de 6a gerao (a e ca mesma do Pentium Pro). A diferena entre os processadores Xeon MP e Xeon que o primeiro perc e mite multiprocessamento simtrico com quatro ou mais processadores, enquanto e que o Xeon permite multiprocessamento com no mximo dois processadores. a Antigamente, o processador Xeon era chamado Xeon DP(multiprocessamento simtrico com at dois processadores), sendo posteriormente renomeado para e e apenas Xeon. Os processadores Xeon possuem 8 KB de memria cache L1 para dados (16 o KB nos modelos que possuem a tecnologia de 64 bits EM64T) e um cache L1 de execuo de 150 KB. O cache L2 pode ser de 512 KB, 1 MB ou 2 MB, sendo ca 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 `s instrues SSE3, e `s tecnologias XD, EM64T e a co a Hyper-Threading.
Os modelos Xeon DP 53xx possuem suporte a tecnologia Quad-Core e no a suportam a tecnologia Hyper-Threading.
Xeon MP Como j explicamos, a diferena entre o Xeon MP e o Xeon a quantidade de a c e processadores suportados no modo de multiprocessamento simtrico: o Xeon e suporta at dois processadores em uma mesma placa-me, enquanto que o Xeon e a MP suporta at quatro processadores por barramento. e
72
Na realidade poss e vel construir servidores com mais de quatro processadores Xeon MP em uma mesma placa-me. Para isso, no entanto, os proa cessadores devem ser agrupados de quatro em quatro ? j que eles s suportam a o at quatro processadores por barramento ? devendo haver uma conexo entre e a os chipsets. Por exemplo, em um servidor com oito processadores Xeon MP, os quatro primeiros processadores estaro interligados atravs do mesmo barraa e mento, enquanto os outros quatro processadores estaro interligados atravs de a e um segundo barramento. A comunicao entre os barramentos locais ser feita ca a pelo chipset. As principais caracter sticas dos processadores Xeon MP so: soquete 603; a cache L1 de execuo de 150 KB; cache L1 de dados de 8 KB ou de 16 KB ca nos modelos com suporte ` tecnologia EM64T; multiprocessamento simtrico a e diretamente com at quatro processadores; tecnologia Hyper-Threading. Alguns e modelos possuem suporte `s instrues SSE3, e `s tecnologias XD, EM64T. a co a
Xeon N cleo Duplo (50xx e 7xxx) u A tecnologia de ncleo duplo traz dois processadores inteiros dentro de um u mesmo invlucro. Como os processadores Xeon de ncleo duplo modelos 50xx o u e 7xxx tm a tecnologia HyperThreading ? que simula a existncia de dois proe e cessadores em cada ncleo ? o sistema operacional reconhece cada processador u Xeon de ncleo duplo como sendo quatro processadores. Assim, em um servidor u com dois processadores Xeon de ncleo duplo, o sistema operacional reconhecer u a oito processadores (quatro ncleos, dois por processador, e dois processadores u lgicos por ncleo). o u Todos os processadores Xeon de ncleo duplo possuem as seguintes caracu ter sticas: soquete 604 (modelos 7xxx) ou 771 (modelos 50xx); Mesma arquitetura interna no Pentium 4 (Netburst); instrues SSE3; cache L1 de dados de 16 co KB e cache de execuo de 150 KB; suporte a multiprocessamento simtrico com ca e at dois processadores por placa-me; barramento externo de 667, 800 ou 1066 e a MHz; tecnologia Execute Disable; tecnologia EM64T; tecnologia HyperThreading; tecnologia de Virtualizao nos modelos 7xxx e 50xx; tecnologia Demandca Based Switching (DBS), exceto nos modelos 5060 e 5063; tecnologia Enhanced SpeedStep; tecnologia de construo 90 nanmetros ou 65 nanmetros. ca o o
Xeon N cleo Duplo (51xx) u Intel lanou recentemente uma nova srie de processadores Xeon (51xx) baseada c e na nova microarquitetura Core, a mesma usada pelos processadores Core 2 Duo. Esta nova srie era conhecida anteriormente por seu nome-cdigo, Woodcrest. e o Tenha em mente que os processadores Xeon de ncleo duplo de outras sries u e (50xx e 7xxx) so baseados na microarquitetura do Pentium 4 (Netburst) e por a isso possuem a tecnologia HyperThreading, que no est presente na microara a quitetura Core.
73
Todos os processadores Xeon da srie 51xx possuem as seguintes carace ter sticas: tecnologia de ncleo duplo; tecnologia de 65 nm; soquete 771; inu strues SSE3; cache L1 dividido, sendo 32 KB para dados e 32 KB para inco strues por ncleo; 4 MB de cache L2 compartilhado entre os ncleos; barraco u u mento externo de 1066 ou 1333 MHz; tecnologia EM64T; tecnologia de Virtualizao; tecnologia Execute Disable; tecnologia Demand-Based Switching (DBS), ca nos modelos 5160, 5150, 5148 e 5140; tecnologia Enhanced SpeedStep; tecnologia Dual Independent Bus (DIB), onde cada ncleo tem seu prprio barramento u o externo em vez de ter apenas um barramento compartilhado entre nos ncleos u para a comunicao com os outros dispositivos do micro. ca
5.1.5
Itanium
O projeto de processadores de 64 bits da Intel j se arrasta por muitos anos. a O primeiro processador lanado usando essa tecnologia foi o Itanium e recentec mente a Intel lanou mais um processador IA-64, o Itanium 2. c Esses dois processadores possuem caracter sticas de hardware bastante pesadas. O Itanium tem os dois caches de memria (L1 e L2) dentro do prprio o o 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 verso do processador. Ele consegue acessar at 16 EB a e (Exabytes, 1 EB = 26 0) de memria RAM e usa um barramento externo de o 64 bits rodando a 266 MHz, atingindo uma taxa de transferncia de 2,1 GB/s. e Esse processador usa uma mistura de soquete com cartucho. J o Itanium 2 tem uma memria cache L1 de 32 KB, uma memria cache a o o L2 de 256 KB e uma memria cache L3 de 1,5 MB ou de 3 MB, dependendo o do modelo. Os mais atuais possuem uma cache L3 de 6, 8, 12, 18 ou 24 MB dependendo do modelo. Seu barramento externo de 128 bits, rodando a 400 e ou 533 MHz. Possuem suporte a tecnologia Dual-Core, EM64T, VT. Esses dois processadores so voltados exclusivamente para o mercado de a servidores de alto desempenho. Isso deixa a AMD em grande vantagem, j que a haver processadores de 64 bits da AMD voltados para usurios comuns (como a a o Clawhammer ).
Outra vantagem da arquitetura de 64 bits da AMD sobre a arquitetura de 64 bits da Intel que a arquitetura da Intel no roda nativamente cdigo de 32 bits e a o usado pelos programas atuais, ao contrrio do que ocorre nos processadores da a AMD, que rodam diretamente esse tipo de cdigo. Isso signica que para rodar o sistemas operacionais e aplicativos de 32 bits, os processadores IA-64 (Itanium, Itanium 2 e futuros processadores) precisam traduzir as instrues de 32 bits co em instrues equivalentes de 64 bits. Isso faz com que haja uma demora na co execuo da instruo, pois h tempo perdido com essa converso. O resultado ca ca a a disso bvio: em alguns casos pode ocorrer de sistemas operacionais e prograeo 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 no tem muita importncia, j que mquinas usando esses proa a a a cessadores com certeza rodaro programas e sistemas escritos diretamente com a instrues de 64 bits. Mas como essa uma nova tecnologia, no s deco e a o e morado reescrever programas antigos como escrever novos programas para essa nova plataforma. E claro que esse mesmo problema existe nos processadores da AMD, isto , possivelmente demorar algum tempo at existirem sistemas e a e operacionais e programas escritos usando cdigo de 64 bits desses processadores. o Mas, por outro lado, eles podem rodar diretamente cdigo de 32 bits, facilitando o a entrada desses processadores no mercado.
5.2
5.2.1
AMD
Sempron
O Sempron o processador da AMD voltado para o mercado low-end, ou seja, e ele destinado a usurios que no precisam de grande poder computacional e e a a que esto mais preocupados com preo do que com desempenho. O concorrente a c do Sempron Celeron D da Intel. e O processador Sempron est dispon a vel em trs verses de soquete: 462 e o (Socket A), 754 e AM2 (940 pinos). Os processadores Sempron soquete 462 so a verses mais simples do Athlon XP, enquanto que os processadores Sempron o soquete 754 e soquete AM2 so verses mais simples do Athlon 64. a o Como o Sempron soquete 462 usa uma arquitetura interna completamente diferente dos processadores Sempron soquete 754 e soquete AM2, uma comparao direta entre esses dois processadores no poss ca a e vel. A nomenclatura PR(Performance Rating) usada pelo Sempron s serve o para a comparao entre modelos de Sempron usando o mesmo tipo de soquete. ca No poss a e vel comparar a nomenclatura PR do Sempron com a do Athlon XP ou com a do Athlon 64. Por exemplo, um Sempron 3000+ no necessariaa e mente mais rpido do que um Athlon XP 2800+ ou do que um Athlon 64 2800+. a
Soquete 462 Os processadores Sempron soquete 462 so, na realidade, processadores Athlon a XP com barramento externo de 333 MHz (166 MHz transferindo dois dados por pulso de clock) e 256 KB de memria cache L2 (ou 512 KB no caso do modelo o 3000+). Essa categoria de Sempron possui as demais caracter sticas do Athlon XP, tais como: 64 KB de cache L1 de instrues e 64 KB de cache L1 de dados; co 256 KB ou 512 KB de cache de memria L2; suporte `s instrues MMX, o a co 3DNow!, SSE e SSE2 (mas no `s instrues SSE3); processo de fabricao de a a co ca 130 nanmetro. o
75
Soquete 754 Os processadores Sempron soquete 754 so na realidade processadores Athlon a 64 com menos memria cache e sem as extenses de 64 bits, sendo que modelos o o lanados mais recentemente passaram a contar com as extenses de 64 bits. c o As principais caracter sticas dos processadores Sempron soquete 754 so: a 64 KB de cache de L1 de instrues e 64 KB de cache L1 de dados; 128 co KB ou 256 KB de cache de memria L2; barramento HyperTransport (baro ramento externo para acesso ao chipset Northbridge. Esta tecnologia permite o processador comunicar-se com a memria RAM e com os demais circuitos o do micro ao mesmo tempo, pois existe outro barramento externo para acesso a ` memria RAM. Antigamente, era apenas um barramento de acesso externo) o trabalhando a 800 MHz (este clock pode tambm ser referenciado como 1.600 e MHz) para os modelos atuais; congurao de memria single channel; suporte ca o a instrues SSE3 nos modelos que tm as extenses de 64 bits habilitadas; proco e o cesso de fabricao de 90 nanmetros. ca o
Soquete AM2 Ao contrrio dos processadores Sempron soquete 754, que trabalham apenas a na congurao de um unico canal (single channel), os processadores Sempron ca soquete AM2 podem utilizar a congurao de dois canais (dual channel), doca brando a taxa de transferncia no acesso ` memria desde que voc use dois e a o e ou quatro mdulos de memria em seu micro. Lembre-se que os processadores o o Sempron soquete 754 aceitam somente memrias DDR, enquanto que os proo cessadores Sempron soquete AM2 aceitam somente memrias DDR2. o As principais caracter sticas tcnicas do Sempron AM2 so as seguintes: 64 e a KB de cache de L1 de instruoes e 64 KB de cache L1 de dados; 128 KB ou 256 c KB de cache de memria L2; barramento HyperTransport trabalhando a 800 o MHz (3.2 GB/s). Este clock pode tambm ser referenciado como 1.600 MHz; e o controlador de memria integrado suporta memrias DDR2-400, DDR2-533 o o e DDR2-667 na congurao de dois canais (dual channel), o que signica que ca o processador acessa a memria a 128 bits, se dois ou quatro mdulos forem o o usados; conjunto de instrues SSE3; extenses de 64 bits habilitadas; processo co o de fabricao de 90 nanmetros. ca o
Existem os modelos de Semprom chamados Mobile Semprom. E concorrente direto do Pentium M. O Mobile Semprom possui as seguintes caracter sticas: 64 KB de cache de L1 de instrues e 64 KB de cache L1 de dados; 128KB ou co 256KB de cache L2 incorporado ao processador; Northbridge integrado; proteo ca avanada contra v c rus; suporte a instrues SSE2; processo de fabricao 90 co ca nanmetros. o
5.2.2
Athlon 64
Os processadores mais novos da AMD encontrados no mercado atualmente so a baseados na arquitetura do Athlon 64, tambm conhecida como x86-64 ou hame
76
mer. Os modelos de Athlon 64 so o Athlon 64, Athlon 64 FX e o Athlon 64 X2. a Esses trs processadores mais o Sempron so voltados para o mercado de e a desktops. O Athlon 64 voltado para o mercado mid-range (usurios entusie a 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 so voltados a para o mercado high-end (alto desempenho). Existem trs outros processadores e baseados na arquitetura do Athlon 64: Athlon 64 Mobile e Turion 64, que so a voltados para o mercado de notebooks, e o Opteron, que voltado para o mere cado de servidores. A principal caracter stica da arquitetura do Athlon 64 a presena do cone c trolador de memria dentro do prprio processador e no no chipset, como o o a acontece com outros processadores. Por causa desta arquitetura a comunicao ca entre o processador e os mdulos de memria feita atravs de um barramento o o e e dedicado, enquanto que a comunicao entre o processador e o chipset feita ca e atravs de um barramento independente, chamado HyperTransport. e Processadores da AMD baseados na arquitetura do Athlon 64 podem ser encontrados com os seguintes padres de pinagem: o Soquete 754 Usado pelas primeiras verses de Athlon 64, alguns modelos de Sempron o e Turion 64. Seu controlador de memria usa somente um canal (single o channel), o que signica que o processador acessa a memria a 64 bits; o Soquete 939 Usado pelos processadores Athlon 64, Athlon 64 FX, Athlon 64 X2 e o Opteron. Seu controlador de memria usa dois canais (dual channel), o o que signica que o processador acessa ` memria a 128 bits, se dois a o mdulos de memria forem usados. o o Soquete 940 Usado pelos primeiros processadores Athon 64 FX e pelo Opteron. Seu controlador de memria usa dois canais (dual channel), o que signica que o o processador acessa a memria a 128 bits, se dois mdulos forem usados o o (ou um nmero par de mdulos de memria for usado). E necessria a u o o a utilizao de memrias do tipo ECC; ca o
Soquete AM2 Usado pelos novos processadores Athlon 64, Athlon 64 FX e Athlon 64 X2. Nesses processadores o controlador de memria integrado suporta o memrias DDR2-533, DDR2-667 e DDR2-800 na congurao de dois o ca canais (dual channel), o que signica que o processador acessa a memria o a 128 bits, se dois mdulos forem usados. Lembre-se que o controlador o de memria dos processadores soquete 754, 939 e 940 suportam apenas o memrias DDR; o Soquete F Este soquete de 1.207 pinos criado para os novos modelos do Opteron tambm usado pelos processadores Athlon 64 FX utilizados na plataforma e e
77
Quad FX da AMD (Athlon 64 FX modelos 7x). Os processadores que utilizam este soquete trabalham no modo SMP (multiprocessamento simtrico), e podendo trabalhar com mais de um processador em paralelo. Assim como os processadores soquete AM2, nesses processadores o controlador de memria integrado tambm suporta memrias DDR2-533, DDR2-667 o e o e DDR2-800 na congurao de dois canais (dual channel), o que signica ca que o processador acessa a memria a 128 bits, se um nmero par de o u mdulos de memria for usado. o o O controlador de memria integrado nos novos processadores Athlon 64 soo quete AM2 e Athlon 64 FX soquete F suporta memrias DDR2-533, DDR2-667 e o DDR2-800. O problema, no entanto, como o clock do barramento de memria e o obtido. Em vez de ser gerado atravs do clock base do processador (clock e e HTT, que de 200 MHz), usada uma diviso do clock interno do processador. e e a O valor desta diviso metade do valor do multiplicador do processador. a e Por exemplo, um processador AMD64 com um multiplicador de clock 12x ter um divisor do barramento de memria de 6. Este processador trabalhar a o a a 2,4 GHz (200 MHz x 12) e sua memria funcionar a 400 MHz (DDR2-800, o a 2.400 MHz / 6). Tenha em mente que as memrias DDR e DDR2 so rotuladas o a com o dobro dos seus clocks reais. O problema quando o multiplicador de clock do processador um nmero e e u mpar. Para um processador AM2 com um multiplicador de clock 13x teoricamente o divisor do seu barramento de memria seria de 6,5. Como o barrao mento de memria do AMD64 no trabalha com divisores quebradoseste valor o a arredondado para o prximo nmero inteiro, sete neste caso. Enquanto este e o u processador funcionar a 2,6 GHz (200 MHz x 13) seu barramento de memria a o funcionar a 371 MHz (742 MHz DDR) e no a 400 MHz (800 MHz DDR), a a fazendo com que o processador no alcance a largura de banda mxima que as a a memrias DDR2 podem fornecer. o Outras caracter sticas encontradas nos processadores baseados na arquitetura do Athlon 64 so as seguintes: O processador no vendido com base a a e em seu clock de operao, mas sim atravs de um indicativo de desempenho ca e chamado performance rating(PR); podem acessar at 1 TB de memria RAM e o (barramento de endereos de 40 bits, 240 = 1 TB); suporte `s instrues MMX, c a co 3Dnow!, SSE e SSE2 (SSE3 apenas nos modelos mais novos); tecnologia EVP (Enhanced V rus Protection, tambm conhecida como NX Bit Disable); tece nologia CoolnQuiet (tecnologia que permite reduzir o barulho, o calor e o consumo de energia). Athlon 64 O Athlon 64 pode ser encontrado em verses para o soquete 754, soquete 939 e o o novo soquete AM2. E pode ser encontrado com diferentes verses de ncleo o u (90 nanmetros ou 130 nanmetros). O concorrente direto do Atlhon 64 o o o e Pentium 4. As principais caracter sticas tcnicas do Athlon 64 so as seguintes: 64 KB e a
78
de cache de L1 de instrues e 64 KB de cache L1 de dados; 512 KB ou 1 MB co de cache de memria L2; barramento HyperTransport trabalhando a 800 MHz o (3,2 GB/s) ou a 1 GHz (4 GB/s). Esses clocks podem tambm ser referenciados e como 1.600 MHzou 2.000 MHz, respectivamente; congurao de memria ca o DDR dual channel nos modelos soquete 939 e AM2 (precisa de dois mdulos de o mdulos de memria para usar este recurso); conjunto de instrues SSE3 em o o co alguns modelos.
Athlon 64 X2 O Athlon 64 X2 um Athlon 64 com tecnologia de ncleo duplo, ou seja, ele e u possui dois processadores dentro de um s. Todos os processadores Athlon 64 o X2 so encontrados para soquete 939 e AM2. O principal corrente do Athlon a 64 X2 o Pentium D Dual Core. e As principais caracter sticas tcnicas do Athlon 64 X2 so as seguintes: 64 e a KB de cache de L1 de instruoes e 64 KB de cache L1 de dados por ncleo; 512 c u KB ou 1 MB de cache de memria L2 por ncleo; barramento HyperTransport o u trabalhando a 1 GHz (4 GB/s). Esse clock pode tambm ser referenciado como e 2.000 MHz; congurao de memria DDR dual channel em todos os modelos; ca o conjunto de instrues SSE3 em alguns modelos. co
Athlon 64 FX Originalmente a diferena entre o Athlon 64 e o Athlon 64 FX era a quantic dade de memria cache L2 (512 KB no Athlon 64 vs. 1 MB no Athlon 64 FX) o e maior exibilidade para overclock, j que ele vinha com o multiplicador de a clock destravado. As principais caracter sticas tcnicas do Athlon 64 FX so as seguintes: 64 e a KB de cache de L1 de instrues e 64 KB de cache L1 de dados por ncleo; co u 1 MB de cache de L2; barramento HyperTransport trabalhando a 800 MHz (3,2 GB/s) ou 1 GHz (4 GB/s); congurao de memria DDR dual channel ca o em todos os modelos; conjunto de instrues SSE3 em alguns modelos; ncleo co u duplo nos modelos terminados em um nmero par. O Athlon 64 FX-60 foi o u primeiro Athlon 64 FX de ncleo duplo lanado. Esta tecnologia faz com que u c o processador possua dois processadores completos em seu interior; O Athlon 64 FX-62 baseado no novo soquete AM2 e, portanto, o seu controlador de e memria suporta as memrias DDR2. o o
5.2.3
Turion 64
Lanado para ser o principal concorrente do Pentium M da Intel, o Turion 64 da c AMD um processador de baixo consumo voltado para o mercado de notebooks. e O Turion 64 baseado na arquitetura do Athlon 64 e a principal diferena e c entre o Turion 64 e o Athlon 64 Mobile o consumo de energia. Uma outra e
79
diferena entre eles a quantidade de memria cache L2, que de 1 MB nos c e o e processadores Athlon 64 Mobile, enquanto que os processadores Turion 64 podem ter memria cache L2 de 512 KB ou 1 MB, dependendo do modelo. o Tanto o Turion 64 quanto o Athlon 64 Mobile possuem a tecnologia PowerNow! da AMD, que similar a tecnologia CoolnQuiet usado pelos procese sadores desktop. Esta tecnologia altera o clock e a tenso de alimentao do a ca processador de acordo com a carga de trabalho que esteja sendo realizada, de modo a economizar bateria. As principais caracter sticas do Turion 64 so as seguintes: o processador a no vendido com base em seu clock de operao, mas atravs de um nmero a e ca e u de modelo; 64 KB de cache de L1 de instrues e 64 KB de cache L1 de dados; co 512 KB ou 1 MB de cache de memria L2; barramento HyperTransport trabalo hando a 800 MHz (3,2 GB/s); congurao de memria DDR single channel; ca o soquete 754; podem acessar at 1 TB (terabyte) de memria RAM; suporte e o a `s instrues MMX, 3Dnow!, SSE e SSE2 e SSE3; tecnologia PowerNow!; tecco nologia EVP (Enhanced Virus Protection), tambm conhecida como NX Bit e Disable; tecnologia de 90 nanmetros. o Os processadores Turion 64 esto dispon a veis em duas sries: ML, que tem e consumo mximo (TDP, Thermal Design Power) de 35 W, e MT, que tem cona sumo mximo de 25 W. a
Turion 64 X2 O Turion 64 X2 um Turion 64 com tecnologia de dois ncleos e com suporte as e u memrias DDR2 na congurao de dois canais (dual channel), o que signica o ca que o processador pode acessar a memria a 128 bits. o O Turion 64 X2 o primeiro processador para notebook da AMD com tece nologia de dois ncleos e a usar o novo padro de pinagem soquete S1, que utiu a liza 638 pinos em vez dos 754 pinos usados no soquete do Turion 64. Portanto, sicamente um Turion 64 X2 menor do que um Turion 64 por ter menos pinos. e Enquanto que o concorrente do Turion 64 o Pentium M, os concorrentes e do Turion 64 X2 so os processadores da Intel Core Duo e Core 2 Duo (nomea cdigo Merom). o As principais caracter sticas do Turion 64 X2 so as seguintes: 64 KB de a cache de L1 de instrues e 64 KB de cache L1 de dados por ncleo; 256 ou co u 512 KB de cache de memria L2 por ncleo; barramento HyperTransport trao u balhando a 800 MHz (3,2 GB/s); congurao de memria DDR2 dual channel; ca o soquete S1; podem acessar at 1 TB (terabyte) de memria RAM; suporte `s e o a instrues MMX, 3Dnow!, SSE e SSE2 e SSE3; tecnologia PowerNow!; tecnoloco gia de Virtualizao; tencnologia EVP (Enhanced V ca rus Protection); tecnologia de 90 nanmetros. o
80
5.2.4
Opteron
O Opteron o processador da AMD voltado para o mercado de servidores de e rede. Ele baseado na arquitetura do Athlon 64. Os principais concorrentes e so o Intel Xeon e Intel Itanium. a Existem duas diferenas principais entre o Opteron e os outros processadores c baseados na arquitetura do Athlon 64. Primeiro, vrios modelos de Opteron a permitem o multiprocessamento simtrico (SMP), ou seja, permitem trabalhar e com mais de um processador na placa-me, enquanto que os outros procesa sadores no. a Os processadores Opteron so identicados atravs de um numero de moda e eloe o primeiro d gito deste nmero indica qual o grau de processamento u e simtrico que o processador aceita: os modelos de Opteron comeando com e c 1no permitem multiprocessamento simtrico, enquanto que os modelos comeando a e c com 2permitem multiprocessamento simtrico com at 2 processadores e os e e modelos comeando com 8permitem multiprocessamento simtrico com at 8 c e e processadores. Processadores Opteron com suporte a memrias DDR usam um nmero o u de modelo de trs d e gitos, enquanto que processadores Opteron com suporte a memrias DDR2 usam um nmero de modelo de quatro d o u gitos. A segunda diferena principal no nmero de barramentos HyperTransport c e u suportados. Todos os processadores baseados na arquitetura do Athlon 64 e os processadores Opteron iniciados com 1tm apenas um barramento Hye perTransport. Processadores Opteron iniciados com 2tm dois barramentos e HyperTransport (ou trs, no caso dos processadores Opteron de quatro d e gitos), enquanto que processadores Opteron iniciados com 8tm trs barramentos e e HyperTransport. Os processadores Opteron podem ser encontrados para vrios tipos de soa quete: Soquete 939 Existem alguns modelos de Opteron da srie 1 para este soquete. Eles e no passam de modelos de Athlon 64 ou de Athlon 64 X2 (se tiver dois a ncleos) com outro nome. Estes modelos trabalham com memrias DDR u o comuns; Soquete 940 Estes modelos necessitam memrias DDR registradas(isto , com buer), o e que um tipo especialde memria para servidores; e o Soquete AM2 Existem alguns modelos de Opteron da srie 1 para este soquete. Eles e no passam de modelos de Athlon 64 X2 com outro nome (porm com a a e tecnologia de virtualizaao, no presente no Athlon 64 X2). Estes modelos c a trabalham com memrias DDR2 comuns; o
81
Soquete F Estes modelos trabalham com memrias DDR2 registradas(isto , com o e buer), que um tipo especialde memria para servidores. e o Processadores Opteron que trabalham com memrias DDR2 tambm so o e a chamados de Opteron de Segunda Gerao. ca Em todos os modelos de Opteron o controlador de memria usa dois canais o (dual channel), ou seja, o processador acessa a memria a 128 bits, se dois o mdulos forem usados (ou se um nmero par de mdulos de memria forem o u o o usados). As principais caracter sticas tcnicas do Opteron so as seguintes: suporte e a a multiprocessamento Simtrico; 64 KB de cache de L1 de instrues e 64 KB e co de cache L1 de dados; 1 MB de cache de memria L2 por ncleo; barramento o u HyperTransport trabalhando a 800 MHz (3,2 GB/s) ou 1 GHz (4 GB/s); congurao de memria em dois canais (voc precisa instalar dois ou um nmero ca o e u par de mdulos de memria para usar este recurso); podem acessar at 1 TB o o e (terabyte) de memria RAM; suporte `s instrues MMX, 3Dnow!, SSE e SSE2 o a co (SSE3 apenas nos modelos mais novos); tencnologia EVP (Enhanced V rus Protection); tecnologia de virtualizao AMD-V nos modelos de quatro d ca gitos. Os seguintes modelos de Opteron so encontrados: Opteron Modelos 1xx a (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
Lgica de Programao o ca
83
Cap tulo 6
Orientao a Objetos ca
6.1 Introduo ca
A anlise e o projeto orientados a objetos tm como meta identicar o melhor a e conjunto de objetos para descrever um sistema de software. O funcionamento deste sistema se d por meio do relacionamento e troca de mensagens entres os a objetos. Na programao orientada a objetos, implementa-se um conjunto de classes ca que denem os objetos presentes no sistema de software. Cada classe determina o comportamento (denido nos mtodos) e os estados poss e veis (atributos) de seus objetos, assim como o relacionamento com outros objetos. As linguagens de programao que do suporte a orientao a objetos so: ca a ca a 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 caracter sticas: possuem um estado e tem um comportamento. Por exemplo, cachorro tem um estado (nome, cor, raa) e um comportamento (latindo, comendo, lambendo). c Analogamente, objetos de software so modelados de acordo com os oba jetos do mundo real, ou seja, possuem estado e comportamento (objeto e uma abstrao do mundo real). Um objeto de software armazena seu esca tado em variveis e implementa seu comportamento com mtodos. Estas a e variveis e mtodos so formalmente chamados de variveis de instncia a e a a a e mtodos de instncia a m de distingu e a -los de variveis e mtodos de a e classe. As variveis de um objeto fazem parte do seu ncleo (centro). Os mtodos a u e envolvem e escondem o ncleo do objeto de outros componentes da aplicao, u ca 1. Empacotar as variveis de um objeto sobre proteo de seus mtodos a ca e e chamado de encapsulamento. O encapsulamento utilizado para esconder e detalhes de implementao pouco importante. Este um dos princ ca e pios fundamentais da programao orientada a objetos. ca
84
Figura 6.1: Representao de um objeto ca ` As vezes, por razes de ecincia ou implementao, um objeto deseja o e ca expor algumas de suas variveis ou esconder alguns de seus mtodos. Esta a e capacidade de controlar quais componentes podem acessar seus mtodos e e suas variveis chamada de Controle de Acesso. a e Cada objeto tem sua identidade que signica que dois objetos so disa tintos mesmo que eles apresentem exatamente as mesmas caracter sticas (atributos iguais). Esta identicao de objeto deve ser unica, uniforme e ca independente do contedo do objeto. u A estrutura de dados de um objeto representada em termos de atributos e (tambm chamados de campos (elds)), ou seja, os dados ou informaes e co do objeto. A 1 mostra um exemplo da representao de objeto do mundo real para o ca objeto de software. Os atributos Raio, x e y so as variveis de instncia. a a a Em Java, para declarar uma varivel de classe basta acrescentar a palavra a static. O mesmo vale para o mtodo. e
Figura 6.2: Representao do objeto do mundo real para o objeto de software ca 2. Mtodos e E uma rotina que executada por um objeto ao receber uma mensagem. e Os mtodos determinam o comportamento dos objetos de uma classe e e so anlogos `s funes ou procedimentos da programao estruturada. O a a a co ca envio de mensagens (chamado de mtodos) pode alterar o estado de um e objeto. 3. Atributos Os atributos so os elementos que denem a estrutura de uma classe. Os a
85
atributos tambm so conhecidos como variveis de classe, e podem ser e a a divididos em dois tipos bsicos: atributos de instncia e de classe. Os a a valores dos atributos de instncia determinam o estado de cada objeto. a Um atributo de classe possui um estado que compartilhado por todos os e objetos de uma classe. Atributos de classe podem ser chamados tambm e de atributos estticos ou constantes. a As mensagens enviadas a um objeto (chamada de mtodo) podem mudar e o valor de um ou mais atributos, alterando o estado de um objeto. 4. Classes Uma classe um modelo (prottipo) que deni as variveis (estado) e os e o a mtodos (comportamento) comuns a todos os objetos do mesmo tipo. Na e classe so denidas as variveis e implementados os mtodos. Os objetos a a e so criados a partir de suas classes. a As classes no so diretamente suportadas em todas as linguagens de oba a jetos, e no so necessrias para que a linguagem seja orientada a objetos. a a a Alm dos mtodos e atributos de uma classe, outros poss e e veis membros so: a Construtor: dene o comportamento no momento da criao de um obca jeto de uma classe; Destrutor: dene o comportamento no momento da destruio do objeto de uma classe. Normalmente utilizado para liberar ca recurso (memria) do sistema; Propriedade: dene o acesso a um estado o do objeto; Evento: dene um ponto em que o objeto pode chamar outros procedimentos de acordo com seu comportamento e estado interno; Obs.: Lembrar sempre que a classe dene as caracter sticas comuns e os objetos so instncias dessa classe, com estado prpria. a a o 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 mtodos (de B), o e objeto A envia uma mensagem para o objeto B. Algumas vezes, o objeto que recebe a mensagem precisa de mais informaes para saber exataco mente o que fazer. Por exemplo, quando voc quer trocar as marchas de e uma bicicleta, deve-se indicar qual a marcha desejada. Esta informao ca acompanha a mensagem como um parmetro. a Assim, trs componentes fazem parte de uma mensagem: e
o objeto para onde a mensagem endereada (bicicleta); o nome do e c mtodo a realizar (mudar marcha); parmetro(s) necessrios para realizar e a a o mtodo (segunda marcha); e A mensagem, tambm, pode ser direcionada diretamente a uma classe por e meio da invocao de um mtodo dinmico. ca e a 6. Herana c A herana um mecanismo que permite criar novas classes a partir de c e classes j existentes, aproveitando-se das caracter a sticas existentes na classe a ser extendida. Com a herana poss c e vel criar classes derivadas (subclasses) a partir de classes bases (superclasses).
86
As subclasses herdam todas as caracter sticas de suas superclasses, como suas variveis (estado) e seus mtodos (comportamento). Entretanto, as a e subclasses no esto limitadas ao comportamento herdado de sua supera a classe. As subclasses podem adicionar variveis e mtodos a aqueles hera e dados. As subclasses, tambm, podem redenir (override) mtodos herdados e e e oferecer implementaes especializadas para estes mtodos. co e O conceito de herana pode ser aplicado para mais de um n c vel. A a rvore de herana, ou hierarquia de classe, pode ser to profunda quanto c a necessrio. Os mtodos e variveis so herdados por meio dos n a e a a veis. Em geral, quanto mais baixa na hierarquia for a posio da classe, mais esca pec co o seu comportamento. e Como benef cios do conceito de herana, podemos citar: c Subclasses oferecem comportamentos especializados a partir de elementos bsicos comuns, oferecidos pela superclasse. A utilizao do conceito de a ca herana muito interessante, pois promove um grande reuso e reaproveitac e mento de cdigo existente; Programadores podem denir classes abstratas o que determinam comportamentos genricos. A superclasse abstrata dene e e pode implementar parcialmente o comportamento de uma classe, mas a maioria das informaes da classe ca indenida ou no implementada. co a e A herana mltipla ocorre quando uma classe pode estender caracter c u sticas de vrias outras classes ao mesmo tempo, ou seja, quando a subclasse a possui mais de uma superclasse. Algumas linguagens evitam utilizar este mecanismo, pois pode levar uma codicao confusa o que diculta a ca manuteno do cdigo. A linguagem Java no suporta herana mltipla, ca o a c u apenas herana simples. J a linguagem C++ oferece suporte ` herana c a a c mltipla. u Uma linguagem ao utilizar herana mltipla est sujeita a dois problec u a mas: coliso de nomes (nomes idnticos nas classes superiores) e herana a e c repetida (classe herda de uma classe superior que herda de uma classe comum); 7. Polimorsmo Segundo a terminologia de orientao a objetos, polimorsmo signica que ca uma mesma mensagem enviada a diferentes objetos resulta em um comportamento que dependente da natureza do objeto que est recebendo a e a mensagem. Ou seja, duas ou mais classes derivadas de uma mesma superclasse podem invocar mtodos que tm a mesma assinatura (nome, lista e e de parmetros e retorno), mas comportamentos distintos, especializado a para cada classe derivada, usando para tanto uma referncia a um objeto e do tipo superclasse. A deciso sobre qual mtodo deve ser selecionado, de acordo com o tipo da a e classe derivada, tomada em tempo de execuo por meio do mecanismo e ca de ligao tardia. No caso do polimorsmo, necessrio que os mtodos ca e a e tenham exatamente a mesma identicao, sendo utilizado o mecanismo ca de redenio de mtodos. A seguir um exemplo de polimorsmo. ca e
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 : " + operacao.calcular(x, y); e } public static void main( String args[] ) { //Primeiro calculamos uma soma Contas.mostrarCalculo(new Soma(), 5, 5); //Imprime o resultado : 10 e Contas.mostrarCalculo(new Subtracao(), 5, 5); //Imprime o resultado : 0 e } } Note que, embora o mtodo calcular tenha sido chamado duas vezes no ine terior de mostrarCalculo, o comportamento apresentado variou de acordo com a classe ao qual ele representava no momento. Os benef cios do polimorsmo so: a clareza e manuteno do cdigo, a a ca o diviso da complexidade e aplicaes ex a co vies. Algumas linguagens promovem o polimorsmo principalmente por meio do uso de classes abstratas e interfaces, como o caso da linguagem Java. e 8. Sobrecarga A sobrecarga um tipo de polimorsmo que permite a existncia de vrios e e a mtodos de mesmo nome, porm com assinaturas levemente diferentes, ou e e seja, variando no nmero e tipo de argumentos e o valor de retorno. Ficar u a a cargo de o compilador escolher de acordo com as listas de argumento os procedimentos ou mtodos a serem executados. Por exemplo: e 88
public class Soma { public int Soma (int x, int y) { return x+y; } public String Soma { return x+y; } (String x, String y)
public double Soma (double x, double y) { return x+y; } } 9. Interfaces Uma interface uma coleo de denies de mtodos abstratos (sem ime ca co e plementao). E utilizada para os objetos interagirem entre si. A classe ca que implementa a interface deve implementar todos os mtodos denidos e na interface. Uma interface, tambm, pode incluir declaraes de cone co stantes. Apesar de uma classe abstrata implementar mtodos abstratos, no se e a pode confundir interface com classe abstrata. As classes abstratas no a podem ser instanciadas, e estas s so utilizadas como superclasses. Por o a exemplo, comida no mundo real. No existe uma instncia (objeto) do a a tipo comida. O que existe so instncias de cenouras, mas, bananas, etc. a a ca Comida representa o conceito abstrato e no capaz de criar uma instncia a e a prpria. As classes abstratas podem possuir mtodos implementados. o e Em Java, para denir uma interface utiliza-se a palavra interface. Embora, uma classe no possa conter mais de uma superclasse, a classe pode a implementar mais de uma interface. Por este motivo, muitas das vezes as interfaces so apresentadas como uma alternativa para herana mltipla a c u de classes. 10. Pacotes Para tornar as classes mais fceis de serem encontradas e utilizadas, para a evitar conitos 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 diretrio, o ou seja, as classes e as interfaces de um mesmo pacote devem estar em um mesmo diretrio. o A utilizao de pacotes proporciona as seguintes vantagens: ca Fica mais fcil para outros programadores determinar quais classes e ina terfaces esto relacionadas; Os nomes das classes de um pacote no iro a a a 89
conitar 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 denidas fora do pacote. Em Java, para criar um pacote coloca-se a palavra chave package no in cio do arquivo onde a classe ou interface denida. e Obs.: Apenas os membros (classe, variveis e mtodos) pblicos so acess a e u a veis fora do pacote onde foram denidos. Obs.: Para uma linguagem ser considerada verdadeiramente orientada a objetos, a linguagem de programao deve oferecer, no m ca nimo, as caracter sticas de: encapsulamento, herana e polimorsmo. c
6.3
Princ pios de programao orientada a obca jetos
Basicamente, os princ pios de programao orientada a objetos so: ca a Classes, objetos e instncias; Campos, mtodos e propriedades; Sobrecarga; a e Herana e classes hierrquicas; Polimorsmo; Interfaces. c a
6.4
Tratamento de excees co
O termo exceo usado para designar um evento que ocorre durante a execuo ca e ca de um programa que desvia o uxo normal de instrues. Em outras palavras, co uma exceo uma condio provocada por uma situao excepcional que requer ca e ca ca uma ao espec ca ca imediata. Muitos tipos de erros podem causar excees: co problemas que variam desde erros srios de hardware, tal como uma falha no e disco r gido, a erros simples de programao, tal como tentar acessar um ca ndice inexistente de um vetor, diviso por zero, um objeto no inicializado, etc. a a Erros causam excees, mas podem existir excees que no so erros. Por co co a a exemplo, numa funo que l dados de um arquivo, a chegada ao nal do arquivo ca e uma condio excepcional que pode ser considerada como exceo. e ca ca Linguagens como ADA, C++, JAVA e EIFFEL possuem mecanismos prprios o de tratamento de excees que facilitam a vida dos programadores tornando co ainda o cdigo mais leg uma vez que separam o cdigo principal do cdigo o vel o o de tratamento do erro. Quando uma exceo ocorre, ela necessita ser tratada. A unidade ou bloco ca de cdigo que manipula a exceo denominada tratador de exceo e a ao o ca e ca ca de indicar a ocorrncia de exceo e transferir o controle para o tratador de e ca exceo denominada sinalizao da exceo. ca e ca ca Tratadores de exceo se comportam como procedimentos chamados implicica tamente pela ocorrncia de uma exceo. Como tratadores de exceo no so e ca ca a a chamados diretamente, eles no possuem nome. Em sua denio costumam a ca conter variveis locais e bloco de cdigo de tratamento. J as excees devem a o a co possuir nome bem denido para que possam ser identicadas. Caso o tratador que capturou a exceo no tenha conhecimento suciente ca a para tratar a exceo ele pode lanar a exceo para um n superior (propagao ca c ca vel ca da exceo). Assim pode-se gerar uma cadeia de propagao at que um trataca ca e dor capture a exceo ou at atingir-se o n ca e vel mais alto da hierarquia dos 90
tratadores onde normalmente um tratador padro ser executado na sa do a a da programa. Outra questo importante o ponto de retorno aps a execuo do bloco a e o ca de cdigo do tratador. Isto depender do modelo de continuao adotado pelo o a ca mecanismo de tratamento de exceo. Em geral, adota-se um dos seguintes ca modelos de continuao: ca Terminao: assume que o erro cr ca e tico e que no existem condies de a co retornar ao ponto onde a exceo foi gerada, retornando o controle para o n ca vel superior. Nesta alternativa a unidade onde ocorreu a exceo e todas as unidades ca na pilha de chamada de subprogramas at onde o tratador de exceo foi execue ca tado so encerradas, continuando-se a execuo do programa na unidade onde a ca o tratador foi encontrado, aps a regio de tratamento; Retomada: assume-se o a que o erro pode ser corrigido e a execuo pode retornar para o bloco onde ca ocorreu a exceo. Portanto, o retorno feito para o bloco gerador do erro. ca e Embora, em princ pio, essa soluo parea ser a mais apropriada, a experincia ca c e tem mostrado que essa alternativa raramente efetiva. e Normalmente, as linguagens tm adotado o modelo de terminao. Em Java, e ca a exceo um tipo especial de objeto que criado quando algo sai de errado ca e e em um programa. Aps criar uma exceo, o ambiente de execuo envia este o ca ca objeto ao seu programa, numa ao denominada levantar uma exceo. E reca ca sponsabilidade do programa capturar esta exceo. Para capturar uma exceo ca ca utilizam-se as clusulas try (blocos de cdigos protegidos) e catch (tratadores a o de excees). Para passar para frente a exceo, utiliza-se a palavra trhows. As co ca excees em Java so instncias da classe Exception (superclasse) ou de suas co a a herdeiras.
91
Parte III
Metodologia de Desenvolvimento
92
Cap tulo 7
Ciclo de Vida
Um modelo de ciclo de vida ou modelo de processo pode ser visto como uma representao abstrata de um esqueleto de processo, incluindo tipicamente alguca mas atividades principais, a ordem de precedncia entre elas e, opcionalmente, e artefatos requeridos e produzidos. De maneira geral, um modelo de processo descreve uma losoa de organizao de atividades, estruturando as atividades do ca processo em fases e denindo como essas fases esto relacionadas. Entretanto, a ele no descreve um curso de aes preciso, recursos, procedimentos e restries. a co co Ou seja, ele um importante ponto de partida para denir como o projeto deve e ser conduzido, mas a sua adoo no o suciente para guiar e controlar um ca a e projeto de software na prtica. a Ainda que os processos tenham de ser denidos 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 fornecer uma estrue tura que possibilite ao gerente fazer estimativas razoveis de recursos, a custos e prazos. Uma vez estabelecido o escopo de software, com os requisitos esboados, uma proposta de desenvolvimento deve ser elaborada, c isto , um plano de projeto deve ser elaborado congurando o processo e ` a ser utilizado no desenvolvimento de software. A medida que o projeto progride, o planejamento deve ser detalhado e atualizado regularmente. Pelo menos ao nal de cada uma das fases do desenvolvimento (anlise a e especicao de requisitos, projeto, implementao e testes), o planejaca ca 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 gerncia de projeto. e Anlise e Especicao de Requisitos Nesta fase, o processo de levantaa ca mento de requisitos intensicado. O escopo deve ser renado e os reqe uisitos mais bem denidos. Para entender a natureza do software a ser constru do, o engenheiro de software tem de compreender o dom nio 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 construo de um modelo descrevendo o que o software tem de fazer (e ca no como faz-lo). a e
93
Projeto Esta fase responsvel por incorporar requisitos tecnolgicos aos reqe a o uisitos essenciais do sistema, modelados na fase anterior e, portanto, requer que a plataforma de implementao seja conhecida. Basicamente, ca envolve duas grandes etapas: projeto da arquitetura do sistema e projeto detalhado. O objetivo da primeira etapa denir a arquitetura geral do e software, tendo por base o modelo constru na fase de anlise de reqdo a uisitos. Essa arquitetura deve descrever a estrutura de n vel mais alto da aplicao e identicar seus principais componentes. O propsito do ca o projeto detalhado detalhar o projeto do software para cada componente e identicado na etapa anterior. Os componentes de software devem ser sucessivamente renados em n veis maiores de detalhamento, at que possam e ser codicados e testados. Implementao O projeto deve ser traduzido para uma forma pass ca vel de execuo pela mquina. A fase de implementao realiza esta tarefa, isto ca a ca , cada unidade de software do projeto detalhado implementada. e e Testes inclui diversos n veis de testes, a saber, teste de unidade, teste de integrao e teste de sistema. Inicialmente, cada unidade de software imca plementada deve ser testada e os resultados documentados. A seguir, os diversos componentes devem ser integrados sucessivamente at se obter o e sistema. Finalmente, o sistema como um todo deve ser testado. Entrega e Implantao uma vez testado, o software deve ser colocado em ca produo. Para tal, contudo, necessrio treinar os usurios, congurar ca e a a o ambiente de produo e, muitas vezes, converter bases de dados. O ca propsito desta fase estabelecer que o software satisfaz os requisitos o e dos usurios. Isto feito instalando o software e conduzindo testes de a e aceitao. Quando o software tiver demonstrado prover as capacidades ca requeridas, ele pode ser aceito e a operao iniciada. ca Operao nesta fase, o software utilizado pelos usurios no ambiente de ca e a produo. ca Manuteno Indubitavelmente, o software sofrer mudanas aps ter sido enca a c o tregue para o usurio. Alteraes ocorrero porque erros foram encona co a trados, porque o software precisa ser adaptado para acomodar mudanas c em seu ambiente externo, ou porque o cliente necessita de funcionalidade adicional ou aumento de desempenho. Muitas vezes, dependendo do tipo e porte da manuteno necessria, essa fase pode requerer a denio de ca a ca um novo processo, onde cada uma das fases precedentes re-aplicada no e contexto de um software existente ao invs de um novo. e Os modelos de processo, de maneira geral, contemplam as fases Anlise e Especia cao de Requisitos, Projeto, Implementao, Testes e Entrega e Implantao. ca ca ca A escolha de um modelo de processo fortemente dependente das caracter e sticas do projeto. Assim, importante conhecer alguns modelos de ciclo de vida e em e que situaes so aplicveis. co a a
94
7.1
Modelo seq encial linear u
Algumas vezes chamado de ciclo de vida clssico ou modelo em cascata, o modelo a seqencial linear requer uma abordagem sistemtica seqencial para o desemu a u penho do software. Abrange as seguintes atividades: Modelagem e engenharia do sistema. Estabelecimento de todos os requisitos do sistema, alocao de algum desses requisitos para o software. ca Anlise de requisitos de software. O processo de denio de requisitos a ca e intensicado e focalizado especicamente no software. Os requisitos do sistema do spftware so documentados e revistos com o cliente. a Projeto. Traduz os requisitos para uma representao do software, que pode ca ser avaliada quanto ` qualidade, antes que a codicao tenha in a ca cio. Enfoca quatro atributos distintos: estrutura de dados, arquitetura do software, representaes da interface e detalhes procedimentais (algoritmicos). co Gerao de cdigo. O projeto traduzido para linguagem de mquina. ca o e a Teste. So conduzidos para descobrir erros e garantir que entradas denidas a produziro resultados reais, que concordam com os resultados exigidos. a Manuteno. O software ir inevitavelmente sofrer modicaes. A manuteno ca a co ca reaplica cada uma das fases precedentes a um programa existente. O modelo seqencial linear o mais amplamente usado. Entre os problemas u e encontrados quando esse modelo aplicado so: e a 1. Modicaes podem causar confuso ` medida que o projeto prossegue, co a a pois o modelo acomoda interao apenas indiretamente. ca 2. Exige que o cliente estabelea todos os requisitos explicitamente. c 3. Uma verso executvel do programa s car dispon quando o projeto a a o a vel terminar.
7.2
Modelo em V
O modelo em V uma variao do modelo em cascata que procura enfatizar e ca a estreita relao entre as atividades de teste (teste de unidade, teste de inca tegrao, teste de sistema e teste de aceitao) e as demais fases do processo, ca ca como mostra a gura 7.1. O modelo em V sugere que os testes de unidade so utilizados basicamente a para vericar a implementaao e o projeto detalhado. Uma vez que os testes c de integrao esto focados na integrao das unidades que compem o softca a ca o ware, eles tambm so usados para avaliar o projeto detalhado. Assim, testes e a de unidade e integrao devem garantir que todos os aspectos do projeto do ca sistema foram implementados corretamente no cdigo. Quando os testes de ino tegrao atingem o n do sistema como um todo (teste de sistema), o projeto ca vel da arquitetura passa a ser o foco. Neste momento, busca-se vericar se o sistema atende aos requisitos denidos na especicao. Finalmente, os testes de ca aceitao, conduzidos tipicamente pelos usurios e clientes, valida os requisitos, ca a 95
conrmando que os requisitos corretos foram implementados no sistema (teste de validao). A conexo entre os lados direito e esquerdo do modelo em V ca a implica que, caso sejam encontrados problemas em uma atividade de teste, a correspondente fase do lado esquerdo e suas fases subseqentes podem ter de u ser executadas novamente para corrigir ou melhorar esses problemas.
Figura 7.1: O modelo em V Os modelos seqenciais pressupem que o sistema entregue completo, aps u o e o a realizao de todas as atividades do desenvolvimento. Entretanto, nos dias ca de hoje, os clientes no esto mais dispostos a esperar o tempo necessrio para a a a tal, sobretudo, quando se trata de grandes sistemas. Dependendo do porte do sistema, podem se passar anos at que o sistema que pronto, sendo invivel e a esperar. Assim, outros modelos foram propostos visando a, dentre outros, reduzir o tempo de desenvolvimento. A entrega por partes, possibilitando ao usurio dispor de algumas funcionalidades do sistema enquanto outras esto a a sendo ainda desenvolvidas, um dos principais mecanismos utilizados por esses e modelos, como veremos a seguir.
7.3
Modelo de prototipagem
O paradigma de prototipagem comea com a denio dos requisitos. Um projeto c ca rpido realizado e concentra-se na representao daqueles aspectos que caro a e ca a vis veis pelo cliente. O prottipo criado e avaliado e ajustado para satisfazer o e e as necessidades do cliente. Idealmente, o prottipo serve como um mecanismo para identicao dos o ca requisitos do software. A prototipagem pode ser problemtica, pois o cliente v a e o que parece ser uma verso executvel do software, ignorando que o prottipo a a o apenas consegue funcionar precariamente.
7.4
Modelo RAD
O desenvolvimento rpido de aplicaao (rapid application development, RAD a c e um modelo incremental que enfatiza o ciclo de desenvolvimento extremamente curto. Abrange as seguintes fases:
96
Modelagem do negcio. O uxo de informao entre as funes do negcio o ca co o modelado. e Modelagem dos dados. O uxo de informao renado num conjunto de ca e objetos de dados. Modelagem do processo. Os objetos de dados so tranformados para cona seguir o uxo de informao necessrio para implementar uma funo do ca a ca negcio. Descries do processamento so criadas. o co a Gerao da aplicao. O RAD considera o uso de tcnicas de quarta gerao. ca ca e ca O processo RAD trabalha para reusar componentes de programas existentes ou criar componentes reusveis. a Teste e entrega. Os componentes novos devem ser testados e todas as interfaces devem ser exaustivamente exercitadas. As desvantagens do RAD so: a 1. O RAD exige desenvolvedores e clientes compromissados com atividades continuamente rpidas. a 2. Nem todos tipo de de aplicao so apropriados para o RAD. ca a 3. Quando riscos tcnicos so elevados o RAD no adequado. e a a e
7.5
7.5.1
Modelos de processo de software evolucionrios a

Modelo incremental
Este modelo uma extenso do modelo espiral sendo porm mais formal e e a e rigoroso. O desenvolvimento de um produto comercial de software uma grande e tarefa que pode ser estendida por vrios meses, possivelmente um ano ou mais. a Por isso, mais prtico dividir o trabalho em partes menores ou iteraes. Cada e a co iterao resultar num incremento. Iteraes so passos em uxo de trabalho e ca a co a incrementos so crescimentos do produto. a O princ pio subjacente ao processo incremental e iterativo que a equipe e envolvida possa renar e alargar paulatinamente a qualidade, detalhe e mbito a do sistema envolvido. Por exemplo, numa primeira iterao deve-se identicar a viso global e deca a terminar a viabilidade econmica do sistema, efetuar a maior parte da anlise o a e um pouco de desenho e implementao. Numa segunda gerao, deve-se conca ca cluir a anlise, fazer uma parte signicativa do desenho e um pouco mais de a implementao. Numa terceira iterao, deve-se concluir o desenho, fazer-se ca ca parte substancial da implementao, testar e integrar um pouco, etc. Ou seja, ca a principal consequncia da aproximao iterativa que os produtos nais de e ca e todo o processo vo sendo amadurecidos e completados ao longo do tempo, mas a cada iterao produz sempre um conjunto de produtos nais. ca A cada iterao so realizadas as seguintes tarefas: ca a Anlise. Renamento de requisitos, renamento do modelo conceitual. a Projeto. Renamento do projeto arquitetural, projeto de baixo n vel. 97
Implementao. Codicao e testes. ca ca Transio para produto. Ddocumentao, instalao, . . .. ca ca ca Vantagens do processo incremental e iterativo: Possibilidade de avaliar mais cedo os riscos e pontos cr ticos do projeto, e identicar medidas para os eliminar ou controlar. Reduo dos riscos envolvendo custos a um unico incremento. Se a equipe ca que desenvolve o software precisar repetir a iterao, a organizao perde ca ca somente o esforo mal direcionado de uma iterao, no o valor de um c ca a produto inteiro. Denio de uma arquitetura que melhor possa orientar todo o desenvolvica mento. Disponibilizao natural de um conjunto de regras para melhor controlar ca os inevitveis pedidos de alteraes futuras. a co Permite que os vrios intervenientes possam trabalhar mais efetivamente a pela interao e partilha de comunicao da resultante. ca ca
7.5.2
Modelo espiral
O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vrios conjuntos de fases se sucedem at se obter o sistema nal. a e Um ciclo se inicia com a determinao de objetivos, alternativas e restries ca co (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratgia para alcanar os objetivos. Na segunda tarefa, anlise e c a e avaliao de alternativas, identicao e soluo de riscos, executa-se uma ca ca ca anlise de risco. Prototipao uma boa ferramenta para tratar riscos. Se o a ca e risco for considerado inaceitvel, pode parar o projeto. Na terceira tarefa ocorre a o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto avaliado e se prepara para iniciar um e novo ciclo. Variaes do modelo espiral consideram entre trs e seis tarefas ou setores co e da espiral, que podem ser: comunicao com o cliente; ca planejamento;
anlise de risco; a engenharia; construo e liberao; ca ca avaliao do cliente. ca O modelo espiral , atualmente a abordagem mais real e stica para desenvolvimento de software em grande escala, e usa uma abordagem que capacita a empresa que presta o servio, e o cliente a entender e reagir aos riscos em c cada etapa evolutiva. Este tipo de modelo exige considervel experincia na a e determinao de riscos e depende dessa experincia para ter sucesso. ca e 98
Vantagens deste modelo: O modelo em espiral permite que ao longo de cada iterao se obtenham ca verses do sistema cada vez mais completas, recorrendo ` prototipagem o a para reduzir os riscos. Este tipo de modelo permite a abordagem do renamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reete, de uma forma bastante real stica, o processo de desenvolvimento. Desvantagens: Pode ser dif convencer grandes clientes (particularmente em situaes cil co de contrato) de que a abordagem evolutiva controlvel. e a A abordagem deste tipo de modelo exige considervel experincia na avaliao a e ca dos riscos e baseia-se nessa experincia para o sucesso. Se um grande risco e no for descoberto, podero ocorrer problemas. a a Este tipo de modelo relativamente novo e no tem sido amplamente e a usado. E importante ter em conta que podem existir diferenas entre o prottipo c o e o sistema nal. O prottipo pode no cumprir os requisitos de desemo a penho, pode ser incompleto, e pode reetir somente alguns aspectos do sistema a ser desenvolvido. O modelo em espiral pode levar ao desenvolvimento em paralelo de mltiplas u partes do projeto, cada uma sendo abordada de modo diferenciado, por isso necessrio o uso de tcnicas espec e a e cas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.
7.5.3
Modelo espiral ganha-ganha
As melhores noegociaes buscam um resultado ganha-ganha. Isto , o cliente co e ganha obtendo um produto ou sistema que satisfaz ` maior parte das necessia dades do cliente, e o desenvolvedor ganha trabalhando com oramentos e prazos c de entrega real sticos e poss veis de serem cumpridos. O modelo espiral ganha-ganha dene um conjunto de atividades de negociao no comeo de cada passagem, em torno da espiral. Ao invs de uma unica ca c e atividade de comunicao com o cliente,as seguintes atividades so denidas: ca a 1. Identicao dos principais interessados do sistema ou do subsistema. ca 2. Determinao das condies de lucro do interessado. ca co 3. Negociao das condies de ganho do interessado para reconcili-las no ca co a a mbito das condies ganha-ganha para todos os envolvidos. co Alm da nfase na negociao inicial, o modelo espiral ganha-ganha introduz e e ca trs marcos de processo, chamados pontos de ancoragem, que ajudam a estae belecer quendo um ciclo completado em torno da espiral e fornecem marcos e de deciso antes do projeto de software presseguir. Esses pontos de ancoragem a so: a 99
Objetivos de ciclo de vida (life cycle objectives, LCO). Dene um conjunto de objetivos para cada atividade principal. Arquitetura do ciclo de vida (life cycle architecture, LCA). Estabelece objetivos que precisam ser satisfeitos, ` medida que a arquitetura do sisa tema, e do software, denida. e Capacidade operacional inicial (initial operational capability, IOC). Representa um conjunto de objetivos associado com a preparao do software para ca instalao e distribuio. ca ca
7.5.4
Modelo de desenvolvimento concorrente
O modelo de desenvolvimento concorrente representado como uma srie de e e grandes atividades tcnicas, tarefas e seus estados associados. Ele dene uma e srie de eventos que podem disparar transies de um estado para outro, para e co cada uma das atividades da engenharia de software. E freqentemente usado u como um paradigma para o desenvolvimento de aplicaes Cliente/Servidor. co Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma viso exata de como est o estado do projeto. a a
7.6
Desenvolvimento baseado em componentes
O desenvolvimento baseado em componentes incorpora caracter sticas de tecnologias orientadas a objetos no modelo espiral. A atividade de engenharia comea com a identicao de classes candidatas. Se a classe existe, ela ser rec ca a utilizada. Se a classe no existe, ela ser desenvolvida nos moldes do paradigma a a de orientao a objetos. ca
7.7
Modelo de mtodos formais e
O modelo de mtodos formais compreende um conjunto de atividades que dee terminam uma especicao matemtica para o software. Uma variante dessa ca a abordagem denominada engenharia de software cleanroon (Sala Simpa). Utie lizando mtodos formais eliminam-se muitos problemas encontrados nos outros e modelos, como p.ex., ambigidade, incompletitude e inconsistncia, que podem u e ser corrigidas mais facilmente de forma no ad hoc, mas atravs de anlise a e a matemtica. a
7.8
Tcnicas de quarta gerao e ca
As tcnicas de quarta gerao concentram-se na capacidade de se especicar o e ca software a uma mquina em um n que esteja prximo ` linguagem natural. a vel o a Engloba um conjunto de ferramentas de software que possibilitam que: O sistema seja especicado em uma linguagem de alto n vel. O cdigo fonte seja gerado automaticamente a partir dessas especicaes. o co Atividades das tcnicas de quarta gerao englobam: e ca 100
Obteno dos Requisitos. O cliente descreve os requisitos os quais so traduzica a dos para um prottipo operacional. Os principais problemas so: o a O cliente pode estar inseguro quanto aos requisitos. O cliente pode ser incapaz de especicar as informaes de um modo co que uma ferramenta 4GL possa realizar. As 4GLs atuais no so sosticadas sucientemente para acomodar a a a verdadeira linguagem natural. Estratgia de projeto. : Para pequenas aplicaes poss e co e vel mover-se do passo de obteno dos requisitos para o passo de implementao usando ca ca uma Linguagem de 4G. Para grandes projetos necessrio desenvolver e a uma estratgia de projeto. De outro modo ocorrero os mesmos problemas e a encontrados quando se usa abordagem convencional (baixa qualidade). Implementao usando 4GL. Os resultados desejados so representados de ca a modo que haja gerao automtica de cdigo. Deve existir uma estrutura ca a o de dados com informaoes relevantes e que seja acess pela 4GL . c vel Teste. O desenvolvedor deve efetuar testes e desenvolver uma documentao ca signicativa. O software desenvolvido deve ser constru de maneira que do a manuteno possa ser efetuada prontamente. ca
101
Cap tulo 8
Anlise Comparativa de a 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 organizao (decomposio e ca ca precedncia de atividades), incluindo a denio de um modelo de ciclo de vida; e ca os artefatos requeridos e produzidos por cada uma das atividades do processo; os procedimentos (mtodos, tcnicas e normas) a serem adotados na realizao e e ca das atividades; os recursos necessrios para a realizao das atividades, dentre a ca eles recursos humanos, recursos de hardware e recursos de software, incluindo as ferramentas a serem utilizadas para apoiar a aplicao dos procedimentos na ca realizao das atividades; e roteiros para a elaborao dos principais documentos ca ca (artefatos) gerados no desenvolvimento. Entre as principais metodologias em uso no mercado de software atualmente esto RUP e XP. a De maneira geral, o ciclo de vida de um software envolve, pelo menos, as atividades de planejamento, levantamento de requisitos, anlise, projeto, implea mentao, testes, implantao, operao e manuteno. ca ca ca ca Uma vez que o software sempre parte de um sistema (ou negcio) maior, e o o trabalho comea pelo estabelecimento dos requisitos para todos os elementos c do sistema e, na seqncia, procede-se a alocao para software de algum subue ca conjunto destes requisitos. Esta etapa a Engenharia de Sistemas e antecede a e todas as demais relacionadas.
8.1
RUP - Rational Unied Process
O Processo Unicado proposto pela Rational (Rational Unied Process RUP) foi criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma sistemtica para se obter reais vantagens no uso da Linguagem de Moda elagem Unicada (Unied Modeling Language UML). De fato, ele no exa e atamente um processo: uma infraestrutura genrica de processo que pode ser e e
102
especializada para uma ampla classe de sistemas de software, para diferentes a reas de aplicao, tipos de organizao, n ca ca veis de competncia e tamanhos de e projetos. O RUP est fundamentado em trs princ a e pios bsicos: orientao a casos a ca de uso, arquitetura e iterao. Ele dito dirigido a casos de uso, pois so os ca e a casos de uso que orientam todo o processo de desenvolvimento. Com base no modelo de casos de uso, so criados uma srie de modelos de anlise, projeto a e a e implementao, que realizam estes casos de uso. E centrado em arquitetura, ca pois defende a denio de um esqueleto para a aplicao (a arquitetura), a ca ca ganhar corpo gradualmente ao longo do desenvolvimento. Finalmente, o RUP e iterativo e incremental, oferecendo uma abordagem para particionar o trabalho em pores menores ou mini-projetos. Esses trs conceitos so igualmente imco e a portantes. A arquitetura prov a estrutura para guiar o desenvolvimento do e sistema em iteraes, enquanto os casos de uso denem as metas e conduzem o co trabalho de cada iterao. ca O ciclo de vida adotado no RUP tipicamente evolutivo. Contudo, uma e forma de organizao em fases adotada para comportar os ciclos de desenca e volvimento, permitindo uma gerncia mais efetiva de projetos complexos. Ao e contrrio do tradicionalmente denido como fases na maioria dos modelos de a ciclo de vida planejamento, levantamento de requisitos, anlise, projeto, ima plementao e testes, so denidas fases ortogonais a estas, a saber: ca a Concepo nesta fase, estabelecido o escopo do projeto e suas fronteiras, ca e determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a preciso necessria para se proceder estimaa a tivas de prazos e custos. As estimativas devem ser globais para o projeto como um todo e detalhadas para a fase seguinte. Assim, a nfase nesta e etapa recai sobre o planejamento e, por conseguinte, necessrio levane a tar requisitos do sistema e preliminarmente analis-los. Ao trmino dessa a e fase, so examinados os objetivos do projeto para se decidir sobre a cona tinuidade do desenvolvimento; Elaborao o propsito desta fase analisar mais renadamente o dom ca o e nio do problema, estabelecer uma arquitetura de fundao slida, desenvolver um ca o plano de projeto para o sistema a ser constru e eliminar os elementos do de projeto que oferecem maior risco. Embora o processo deva sempre acomodar alteraes, as atividades da fase de elaborao asseguram que co ca os requisitos, a arquitetura e os planos esto sucientemente estveis e que a a os riscos esto sucientemente mitigados, de modo a se poder prever com a preciso os custos e prazos para a concluso do desenvolvimento. a a Construo durante esta fase, um produto completo desenvolvido de maneira ca e iterativa e incremental, para que esteja pronto para a transio ` comuca a nidade usuria. a Transio nesta fase, o software disponibilizado ` comunidade usuria. Aps ca e a a o o produto ter sido colocado em uso, naturalmente surgem novas consideraes que vo demandar a construo de novas verses para permitir co a ca o ajustes do sistema, corrigir problemas ou concluir algumas caracter sticas que foram postergadas.
103
E importante realar que dentro de cada fase, um conjunto de iteraes, c co envolvendo planejamento, levantamento de requisitos, anlise, projeto e implea mentao e testes, realizado. Contudo, de uma iterao para outra e de uma ca e ca fase para a prxima, a nfase sobre as vrias atividades muda, como mostra o e a a gura 8.1, em que a cor preta indica grande nfase, enquanto a cor branca e indica muito pouca nfase. Na fase de concepo, o foco principal recai sobre e ca o entendimento dos requisitos e a determinao do escopo do projeto (planeca jamento e levantamento de requisitos). Na fase de elaborao, o enfoque est ca a na captura e modelagem dos requisitos (levantamento de requisitos e anlise), a ainda que algum trabalho de projeto e implementao seja realizado para proca totipar a arquitetura, evitando certos riscos tcnicos. Na fase de construo, o e ca enfoque concentra-se no projeto e na implementao, visando evoluir e rechear ca o prottipo inicial, at obter o primeiro produto operacional. Finalmente, a o e fase de transio concentra-se nos testes, visando garantir que o sistema posca sui o n vel adequado de qualidade. Alm disso, usurios devem ser treinados, e a caracter sticas ajustadas e elementos esquecidos adicionados.
Figura 8.1: A nfase principal de cada uma das fases e Alm dos conjuntos de iteraes em cada fase, as fases em si podem ocorrer e co de forma iterativa. Como mostra a gura 8.2, elas no necessariamente tm a a e mesma durao. O esforo realizado em cada uma varia fortemente em funo ca c ca das circunstncias espec a cas 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) destinada a grupos pequenos de e desenvolvimento, e em projetos de durao de at 36 meses. Os principais papeis ca e nesta metodologia so: Programador - foco da metodologia; Coach - responsvel a a por questes tcnicas do projeto, maior conhecimento do processo,valores e o e prticas XP. Verica o comportamento da equipe; Tracker - Coletar sinais via tais do projeto uma ou 2 vezes por semana e mantem todos informados; Gerente - responsvel pelos assuntos administrativos,mantem um forte relacionamento a com o cliente. Entre as principais caracteristicas da metodologia XP esto: (i) Metforas a a - Utilizao de comparaes e analogias para facilitar entendimento; (ii)Design ca o Simples do Sistema; (iii)Testes Automatizados - Testes de Unidade e de Aceitao; ca (iv)Refactoring - Todo desenvolvedor tem o dever de melhorar um cdigo que eso teja funcionado porm mal escrito; (v)Programaao de Dupla- Todo cdigo deve e c o ser implementado em dupla; (vi)Propriedade Coletiva do Cdigo; (vii)Semana o de 40 horas - Evitar trabalhar a mais. Incialmente se obtem resultados, mas depois h o desgaste; (viii)Integrao cont a ca nua - Eliminar erros graves de integrao; (ix)Releases Curtos - Release um conjunto de funcionalidade bem ca e denidas 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 usurios onde so descritas funcionalidades do sistema; (xi)CRC - Linguagem a a para Modelagem de Classes do XP. Utiliza os story cards.
8.3
Scrum
Scrum um processo para construir software incrementalmente em ambientes e complexos, onde os requisitos no so claros ou mudam com muita freqncia. a a ue Em Rugby, Scrum um time de oito integrantes que trabalham em conjunto e para levar a bola adiante no campo. Ou seja: times trabalhando como uma unidade altamente integrada com cada membro desempenhando um papel bem denido e o time inteiro focando num unico objetivo. O objetivo do Scrum fornecer um processo conveniente para projetos e e desenvolvimento orientado a objetos. A metodologia baseada em princ e pios semelhantes aos de XP: equipes pequenas, requisitos pouco estveis ou descona hecidos, e iteraes curtas para promover visibilidade para o desenvolvimento. co No entanto, as dimenses em Scrum diferem de XP. o Scrum divide o desenvolvimento em sprints de 30 dias. Equipes pequenas, de at 7 pessoas, so formadas por projetistas, programadores, engenheiros e e a gerentes de qualidade. Estas equipes trabalham em cima de funcionalidade (os requisitos, em outras palavras) denidas no in de cada sprint. A equipe toda cio responsvel pelo desenvolvimento desta funcionalidade. e a Todo dia, feita uma reunio de 15 minutos onde o time expes ` gerncia e a o a e o que ser feito no prximo dia, e nestas reunies os gerentes podem levantar a o o os fatores de impedimento, e o progresso geral do desenvolvimento. Scrum interessante porque fornece um mecanismo de informao de status e ca que atualizado continuamente, e porque utiliza a diviso de tarefas dentro e a da equipe de forma explicita. Scrum e XP so complementares pois Scrum a
105
prov prticas geis de gerenciamento enquanto XP prov prticas integradas e a a e a 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 existncia deste conjunto so: e a Todo projeto tem necessidades, convenes e uma metodologia diferentes. co O funcionamento do projeto inuenciado por fatores humanos, e h e a melhora neste quando os indiv duos produzem melhor. Comunicao melhor e lanamentos freqentes reduzem a necessidade de ca c u construir produtos intermedirios do processo. a Crystal/Clear uma metodologia direcionada a projetos pequenos, com e equipes de at 6 desenvolvedores. Assim como com SCRUM, os membros da e equipe tem especialidades distintas. Existe uma forte nfase na comunicao e ca entre os membros do grupo. Existem outras metodologias Crystal para grupos maiores. Toda a especicao e projeto so feitos informalmente, utilizando quadros ca a publicamente vis veis. Os requisitos so elaborados utilizando casos de uso, um a conceito similar `s estrias de usurio em XP, onde so enunciados os requisitos a o a a como tarefas e um processo para sua execuo. ca As entregas das novas verses de software so feitos em incrementos reguo a lares de um ms, e existem alguns subprodutos do processo que so response a abilidade de membros espec cos do projeto. Grande parte da metodologia e pouco denida, e segundo o autor, isto proposital; a idia de Crystal/Clear e e e permitir que cada organizao implemente as atividades que lhe parecem adeca quadas, fornecendo um m nimo de suporte util do ponto de vista de comunicao ca e documentos.
8.5
Feature Driven Development (FDD)
Mtodo gil e adaptativo e a Foco nas fases de desenho e construo. ca
Interage com outras metodologias. No exige nenhum processo espec a co de modelagem. Possui desenvolvimento iterativo. Enfatiza aspectos de qualidade durante o processo e inclui entregas freqentes u e tang veis. Suporta desenvolvimento gil com rpidas adaptaes `s mudanas de a a co a c requisitos e necessidades do mercado. O FDD consiste de 5 processos principais: 106
Desenvolver um modelo compreens (Develop an overall model). vel 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 arcabouo para desenvolvimento rpido de aplicaes c a co (RAD). Fixa tempo e recursos ajustando a quantia de funcionalidades. Funciona com pequenas equipes. Suporta mudanas nos requisitos durante o ciclo de vida. c Consiste em cinco fases: Estudo das possibilidades (Feasibility study). Estudo dos negcios (Business study). o Iterao do modelo funcional (Functional model iteration). ca Iterao de projeto e construo (Design and build iteration). ca ca Implementao nal (Final implementation). ca Prticas: a Usurio sempre envolvido. a Equipe do DSDM autorizada a tomar decises. o Foco na frequente entrega de produtos. Adaptao ao negcio o critrio para entregas. ca o e e Construa o produto certo antes de voc constru corretamente. e -lo Desenvolvimento iterativo e incremental. Mudanas so revers c a veis utilizando pequenas iteraes. co
Requisitos so acompanhados em alto n a vel. Testes integrados ao ciclo de vida.
8.7
Adaptive Software Development (ASD)
E iterativo e incremental. Funciona bem em sistemas grandes e complexos. E Arcabouo para evitar o caos. O cliente deve estar sempre presente. E uma c metodologia voltada para o desenvolvimento de aplicaes em conjunto (Joint co Application development - JAD). Possui trs ciclos de fase: e
107
Especular (Speculate). Fixa prazos e objetivos e dene um plano baseado em componentes. Colaborar (Collaborate). Construo concorrente de vrios componentes. ca a Aprender (Learn). Repetitivas revises de qualidade e foco na demostrano o ca das funcionalidades desenvolvidas (Learning loop). H presena do cliente a c e de especialistas do dom nio. Os ciclos duram de 4 a 8 semanas. E orientado a misses (Mission-driven), o pois atividades so justicadas atravs de uma misso, que pode mudar ao longo a e a do projeto. E baseado em componentes e interativo. Os prazos so pr-xados a e (time-boxed), pois fora os participantes do projeto a denir severamente dec cises do projeto. Uma propriedade interessante a tolerncia a mudanas o e a c (Change-tolerant). As mudanas so freqentes, ento sempre melhor esc a u a e tar pronto a adapt-las do que control-las. Isso feito atravs de constante a a e e avaliao de quais componentes podem mudar. ca
108
Cap tulo 9
Engenharia de Requisitos
9.1 O Processo de Engenharia de Requisitos
As descries das funes que um sistema deve incorporar e das restries que co co co devem ser satisfeitas so os requisitos para o sistema. Isto , os requisitos de a e um sistema denem o que o sistema deve fazer e as circunstncias sob as quais a deve operar. Em outras palavras, os requisitos denem os servios que o sistema c deve fornecer e dispem sobre as restries ` operao do mesmo. o co a ca Requisitos so, normalmente, classicados em requisitos funcionais e no a a funcionais. Requisitos funcionais, como o prprio nome indica, apontam as o funes que o sistema deve fornecer e como o sistema deve se comportar em deco terminadas situaes. J os requisitos no funcionais descrevem restries sobre co a a co as funes oferecidas, tais como restries de tempo, de uso de recursos etc. Alco co guns requisitos no funcionais dizem respeito ao sistema como um todo e no a a a funcionalidade espec ca. Dependendo da natureza, os requisitos no funcionais a podem ser classicados de diferentes maneiras, tais como requisitos de desempenho, requisitos de portabilidade, requisitos legais, requisitos de conformidade etc. Os processos de engenharia de requisitos variam muito de uma organizao ca para outra, mas, de maneira geral, a maioria dos processos de Engenharia de Requisitos composta das seguintes atividades: e Levantamento (ou Descoberta ou Elicitao) de Requisitos Nesta fase, ca os usurios, clientes e especialistas de dom a nio so identicados e trabala ham junto com os engenheiros de requisitos para descobrir, articular e entender a organizao como um todo, o dom ca nio da aplicao, os procesca sos de negcio espec o cos, as necessidades que o software deve atender e os problemas e decincias dos sistemas atuais. e Anlise de Requisitos visa a estabelecer um conjunto acordado de requisitos a consistentes e sem ambigidades, que possa ser usado como base para u o desenvolvimento do software. Para tal, diversos tipos de modelos so a constru dos. Documentao de Requisitos a atividade de representar os resultados da ca e Engenharia de Requisitos em um documento (ou conjunto de documentos), contendo os requisitos do software. 109
Vericao e Validao de Requisitos A vericao de requisitos avalia se ca ca ca o documento de Especicao de Requisitos est sendo constru de ca a do forma correta, de acordo com padres previamente denidos, sem cono ter requisitos amb guos, incompletos ou, ainda, requisitos incoerentes ou imposs veis de serem testados. J a validao diz respeito a avaliar se esse a ca documento est correto, ou seja, se os requisitos e modelos documentados a atendem `s reais necessidades e requisitos dos usurios / cliente. a a Gerncia de Requisitos se preocupa em gerenciar as mudanas nos requisie c tos j acordados, manter uma trilha dessas mudanas, gerenciar os relaa c cionamentos entre os requisitos e as dependncias entre o documento de e requisitos e os demais artefatos produzidos no processo de software, de forma a garantir que mudanas nos requisitos sejam feitas de maneira c controlada e documentada.
9.2
9.2.1
Tcnicas de Levantamento de Requisitos e

Observao ca
A observao possibilita um contato pessoal e estreito do pesquisador com o ca fenmeno pesquisado, o que apresenta uma srie de vantagens. As tcnicas de o e e observao so extremamente uteis para descobriraspectos novos de um probca a lema. Isto se torna crucial nas situaes em que no existe uma base terica co a o slida que oriente a coleta de dados. Ao mesmo tempo em que o contato direto o e prolongado do pesquisador com a situao pesquisada apresenta as vantagens ca mencionadas, envolve tambm uma srie de problemas. Algumas cr e e ticas so a feitas ao mtodo de observaao, primeiramente por provocar alteraes no ame c co biente ou no comportamento das pessoas observadas. Outra cr tica a de que e este mtodo se baseia muito na interpretao pessoal. Alm disso h criticas no e ca e a sentido de que o grande envolvimento do pesquisador leve a uma viso distorcida a do fenmeno ou a uma representao parcial da realidade. o ca
9.2.2
Entrevista
Entrevista uma tcnica de elicitao de requisitos muito usada. O engenheiro e e ca de requisitos ou analista discute o sistema com diferentes usurios , a partir da a qual elabora um entendimento de seus requisitos. H, basicamente, 2 tipos de a entrevista: a) entrevistas fechadas onde o engenheiro de requisitos procura as perguntas para um conjunto um pr-denido de questes; b) entrevistas abertas e o onde no h agenda prdenida e o engenheiro de requisitos discute, de modo a a e aberto, o que os usurios querem do sistema. Entrevistas podem ser efetivas a para desenvolver um entendimento do problema e para elicitar muitos requisitos gerais do sistema. Usurios nais so usualmente felizes para descreverem seus a a trabalhos e as diculdades que eles enfrentam de forma relativamente natural, entretanto eles podem ter expectativas no realistas sobre o suporte que o coma putador dar. Portanto, entrevistas so muito menos efetivas para entendimento a a do dom nio da aplicao e para o entendimento das questes organizacionais as ca o quais afetam os requisitos.
110
9.2.3
Anlise de Protocolo a
A anlise de protocolo pede a pessoa se engajar em alguma tarefa e correntea ` mente falar sobre esta tarefa, explicando o seu pensamento do processo. Usurios a alegam que esse tipo de linguagem pode ser considerada uma verbalizao dica reta do processo cognitivo espec co. A anlise de protocolo no um guia a a e convel sobre o que as pessoas esto pensando, ela est sujeita a problemas a a a de interpretaes pelos analistas. A restrio em estudar protocolos que as co ca e pessoas podem produzir linguagens que oferece um perl de atividade cognitiva autnoma. Segundo (Goguen, 1997), mesmo se fosse poss conseguir um o vel perl de atividade cognitiva autnoma da pessoa, tal objeto seria inapropriado o para o processo de requisitos, porque o cliente no tem qualquer modelo mental a pr-existente do sistema desejado. Os clientes tm conhecimento sobre negcios e e o e necessidades organizacionais, enquanto o time de requisitos tem conhecimento sobre as possibilidade tcnicas. e
9.2.4
JAD
JAD uma marca registrada da IBM. O tema principal do JAD colocar e e autoridades representativas e gerenciais juntas dentro de um workshop estruturado para promover decises. Segundo (Damian, 1997) JAD consiste de 5 fases: o denio do projeto, pesquisa, preparao para a sesso JAD, a sesso JAD, o ca ca a a documento nal. As fases de denio de projeto e pesquisa no processo JAD ca lidam com a coleta de informaes. A sesso JAD ento usada para validar co a e a as informaes recolhidas nas fases anteriores. O processo JAD concentrase na co sesso JAD, e deste modo JAD contribui para a elicitao de requisitos como a ca signicado para validar as informaes j colhidas. Na sesso JAD, as pessoas co a a certas tm que estar envolvidas, e a presena de um facilitador pode ajudar a e c manter a sesso focalizada e minimizar ataques e defesas emocionais improdua tivas. JAD promove cooperao, entendimento, e trabalho em grupo entre os ca vrios grupos de usurios e o pessoal de sistemas de informao. a a ca
9.2.5
PD
Tradicionalmente valores democrticos, os quais tem sido levados em conta no a processo de projeto, tem sido somente aqueles concentrados em fatores tcnicos e e econmicos. Mas com o uso do PD fatores tcnicos-sociais tem sido levados em o e conta. O projeto deveria ser feito com o usurio. Aprendizado mtuo deveria a u ser uma parte importante do trabalho em um grupo de projeto, no sendo a meramente uma visita aos laboratrios de pesquisa. Trabalhadores e clientes so o a inteligentes e criativos, contribuidores produtivos para as organizaes, desde co que sejam encorajados a expressarem seus desejos, aplicarem sua esperteza e exercitarem suas capacidades de tomar decises, assumindo responsabilidades o do impacto de suas aes. co
9.2.6
QFD
O termo qualidade denido como um conjunto de meios para produzir ecoe nomicamente produtos ou servios, os quais satisfaam os requisitos do cliente. c c QFD um conceito que prov meios de interpretar requisitos do cliente em reqe e uisitos tcnicos, apropriados para cada estgio do desenvolvimento e produo e a ca 111
do produto(Damian, 1997). As fases iniciais do QFD podem ser descritas como sendo simplesmente um sistema de identicao e priorizao das necessidades ca ca do cliente obtidas de cada recurso avaliado. QFD um conceito que aplica-se e bem para a elicitao de requisitos, especialmente num modelo de elicitao ca ca onde a voz do cliente o guia para a criao de requisitos. e ca
9.2.7
CRC
Como denido em (Zhu, 1998), CRC uma sesso de grupo, que similar ao e a e JAD, onde os papis dos participantes e o papel do facilitador so claramente e a denidos. Em CRC, participantes consistem no somente de usurios e facilitaa a dor, mas tambm de outras pessoas envolvidas indiretamente no sistema. CRC e diferente de JAD e QFD pois ele foca-se no usurio operativo. e a
9.2.8
Prototipao ca
Este mtodo para elicitao de requisitos utiliza-se do uso de uma tcnica de e ca e prototipao para a avaliao do usurio. O conjunto inicial de requisitos ca ca a e usado como base para criar o Prottipo de Interface do Usurio com o siso a tema inicial (simplicado). Para essa criao, o projetista precisa manter o ca prottipo to simples quanto poss o a vel. O ponto forte desta atividade apree sentar muitas alternativas para o usurio antes de se gastar muito esforo para a c qualquer prottipo em particular. Aps a aceitao do prottipo pelos usurios, o o ca o a os desenvolvedores precisam criar um documento de especicao dos requisitos ca paralelo ao prottipo de interface (McConnel, 1998). o
9.2.9
Cenrios a
Usurios nais e outros agentes do sistema acham a utilizao de cenrios mais a ca a fceis para relacionar-se aos exemplos da vida real do que descries abstratas a co das funes realizadas pelo sistema. Por essa razo, freqentemente util desenco a e u volver um conjunto de interaao dos cenrios, e usar estes para elicitar e clarear c a requisitos de sistema. Cenrios so exemplos de sesses de interao as quais a a o ca so concentradas com um tipo unico de interao entre um usurio nal e o sisa ca a tema. Usurios nais simulam suas interaes usando cenrios. Eles explicam a co a para o time de engenheiros de requisito o que eles esto fazendo e a informao a ca da qual eles precisam do sistema para descrever a tarefa descrita no cenrio. a
9.2.10
FAST
Tcnicas facilitadas de especicao de aplicaes (facilitated application spece ca co ication techniques). Consiste nos seguintes passos: 1. Reunies iniciais entre o cliente e o desenvolvedor (sesso de perguntas e o a respostas). Produzem como resultado a solicitao de produto. ca 2. So selecionados local, horrio e data para o FAST e escolhido um facila a e itador. 3. A solicitao de produto distribu para todos os participantes antes ca e da da data da reunio. a
112
4. E solicitado a cada participante que faa uma lista dos objetos que so c a parte do ambiente , uma lista de servios (processos ou funes), uma c co lista de restries (custo, tamanho, regras de negcio) e critrios de deco o e sempenho. 5. Quando a reunio a FAST comea, o primeiro tpico de discusso a a c o a e necessidade e a justicativa do produto. 6. Cada um apresenta suas listas, cr ticas e debates so proibidos nesta etapa. a 7. Uma lista combinada que elimina objetos redundantes produzida, mas e no apaga nada. a 8. A lista modicada com uma discusso dirigida pelo facilitador. O proe a duto a lista de consenso. e 9. A equipe subdividida em equipes menores; cada uma trabalha para e produzir miniespecicaoes, ou seja, detalham cada objeto da lista de c consenso. 10. As equipes apresentam suas miniespecicaes e a lista modicada noco e vamente atravs de discusses. e o 11. Cada participante da reunio cria os critrios de validao para os elemena e ca tos da lista. 12. Uma lista de consenso de critrios de validao criada. e ca e 13. Algum ca responsvel em redigir o rascunho completo das especicao. e a ca
9.3
Anlise de Requisitos a
A anlise de requisitos uma atividade de engenharia de software que vence a e o espeo entre a engenharia de requisitos, no n c vel de sistema, e o projeto de software. As atividades de engenharia de requisitos resultam na especicao ca das caracter sticas operacionais do software (funo, dados e comportamento). ca A anlise de requisitos constri modelos de dom a o nio que fornecem ao projetista uma viso do software. a A especicao de requisitos produzida no auge da tarefa de anlise. Alguns ca e a padres sugerem que uma especicao de requisitos deve conter: o ca
Introduo. Declara as metas e objetivos do software. ca Descrio da informao. Fornece uma descrio detalhada do problema que ca ca ca o software deve resolver. O contedo, uxo e estrutura da informao so u ca a documentados. Descrio funcional. Uma narrativa de processamento fornecida para cada ca e funo. ca Descrio comportamental. Examina a operao do software como conseqncia ca ca ue de eventos externos e caracter sticas de controle geradas internamente.
113
Critrios de validao. Informa como devemos reconhecer uma implementao e ca ca bem-sucedida e quais classes de testes devem ser conduzidas para validar a funo, o desempenho e as restries. ca co Bibliograa e apndice. A bibliograa contm todos os documentos que se e e relacionam ao software. O apndice contm informaes que suplementa e e co as especicaes. co
9.3.1
Mtodos de anlise e a
Entre os mais importantes mtodos de anlise, trs se destacam: A anlise estrue a e a turada, a anlise essencial e a anlise orientada a objetos. A seguir discutiremos a a suas principais caracter sticas. Anlise estruturada a A Anlise Estruturada adota uma viso de desenvolvimento baseada em um a a modelo entrada-processamento-sa da. No paradigma estruturado, os dados so a considerados separadamente das funes que os transformam e a decomposio co ca funcional usada intensamente. e Anlise essencial a Os mtodos orientados a funoes conduzem o desenvolvimento de software estrue c turando as aplicaes segundo a tica das funes (aes) que o sistema dever co o co co a realizar. Os mtodos orientados a dados, por sua vez, enfatizam a identicao e ca e estruturao dos dados, subjugando a anlise das funes para um segundo ca a co plano. Esses mtodos tm origem no projeto de bancos de dados e, geralmente, e e tm no modelo de Entidades e Relacionamentos (ER) sua principal ferramenta. e A anlise essencial uma metodologia estruturada, sendo uma evoluo da a e ca anlise estruturada. Essa metodologia procurou conciliar as abordagens oria entadas a dados e a funes em um unico mtodo, utilizando modelos para co e dados, funes e controles (DFDs, DERs e Diagramas de Transio de Estados, co ca respectivamente) como ferramentas para a modelagem de sistemas. Anlise orientada o objeto a A orientao a objetos pressupe que o mundo composto por objetos, onde ca o e um objeto uma entidade que combina estrutura de dados e comportamento e funcional. No paradigma orientado a objetos, os sistemas so estruturados a a partir dos objetos que existem no dom nio do problema, isto , os sistemas so e a modelados como um nmero de objetos que interagem. u
9.3.2
DFDs
Modelagem da anlise a
Ferramenta de modelagem utilizada para descrever a transformao de entradas ca em sa das. Representa um sistema como uma rede de processos interligados entre si por uxos de dados e depsitos de dados. E a ferramenta de modelagem o mais importante da anlise estruturada. Junto com o DER, a ferramenta mais a e importante da anlise essencial. Seus componentes so: a a 114
Processo. Tambm chamado de funo, bolha ou transformao, o processo e ca ca representa as transformaes realizadas sobre os dados em um sistema e co correspondem a funes ou procedimentos que um sistema tem que prover. co E representado gracamente por c rculos e deve ter um nome composto por um verbo e um objeto. Fluxo de dados. Representa uma coleo de itens de dados em movimento. E ca representado gracamente atravs de uma seta entrando ou saindo de um e processo, com a ponta indicando o sentido do uxo. Deve ter associado um nome o mais signicativo poss vel, de modo a facilitar a validao do ca diagrama com os usurios. Esse nome deve ser um substantivo que facilite a a identicao da coleo de dados transportada. ca ca Depsito de dados. O depsito de dados utilizado para modelar um repositrio o o e o de uma coleo de pacotes de dados em repouso. E representado gracaca mente por duas linhas paralelas com um nome que represente seu contedo u e que normalmente o plural do nome dos pacotes transportados pelos e uxos para dentro e para fora do depsito. o Terminador ou entidade externa. Entidades externas ou terminadores so a fontes ou destinos de dados do sistema. Representam os elementos do ambiente com os quais o sistema se comunica. Tipicamente, uma entidade externa uma pessoa (p.ex. um cliente), um grupo de pessoas (p. ex. um e departamento da empresa ou outras instituies) ou um outro sistema que co interaja com o sistema em questo. Uma entidade externa deve ser idena ticada por um nome e representada por um retngulo. Assim como no a caso dos depsitos de dados, em diagramas complexos, podemos desenhar o um mesmo terminador mais de uma vez, para se evitar o cruzamento de linhas de uxos de dados ou para impedir que longas linhas de uxos de dados saiam de um lado a outro do diagrama. Quando o software complexo, devemos organizar o DFD em n e veis. Dois DFDs especiais esto presentes em qualquer modelo funcional: a Contexto. Mostra o sistema como uma caixa-preta, trocando informaes (uxos co de dados) com entidades externas ao sistema. N vel 0 - Geral ou de Sistema. E uma decomposio do diagrama de conca texto, mostrando o funcionamento do sistema em questo, isto , as grandes a e funes do sistema e as interfaces entre elas. Os processos nesse diagrama co recebem os nmeros 1, 2, 3, etc. . . E necessrio assegurar a coerncia enu a e tre os diagramas de contexto e de n 0, isto , assegurar que os uxos vel e de dados entrando ou saindo do diagrama efetivamente reproduzem as entradas e sa das do diagrama de contexto. Neste diagrama, devem aparecer os depsitos de dados necessrios para a sincronizao dos processos. o a ca Dicionrio de Dados a O dicionrio de dados uma listagem organizada de todos os elementos de a e dados pertinentes ao sistema, com denies precisas para que os usurios e co a desenvolvedores possam conhecer o signicado de todos os itens de dados. Exemplicando para uma estrutura de dados nome: nome = t tulo-cortesia + 115
primeiro-nome + (nome-intermedirio) + ultimo-nome, t a tulo-cortesia = [Sr. Sra. Srta. Dr. Professor] etc. . . Aspectos de anlise essencial a O modelo comportamental determina o comportamento interno do sistema para que este possa interagir corretamente com o ambiente. Aps a construo do o ca 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 constru um DFD. do Diagramas de Fluxos de Dados Organizados em N veis Hierrquicos. a Representa os processos em n veis hierrquicos, a partir do diagrama zero. a Diagramas de Transio de Estados. Representa o comportamento das enca tidades e relacionamentos com atributos ao longo do tempo. Ser cona stru um DTE para cada entidade ou relacionamento com atributo do do DER que possuir comportamento signicativo, isto , possuir mais de um e estado ao longo de seu ciclo de vida. Dicionrio de Dados. Descreve os dados representados no DER, nos DFDs a e nos DTEs. Especicao da Lgica dos Processos (Mini-especicaes). Descreve ca o co a lgica dos processos do DFD que no foram detalhados em diagramas o a de n inferior (lgica dos processos primitivos). vel o Como podemos perceber, a anlise essencial faz uso praticamente das mesmas a tcnicas de modelagem da anlise estruturada, a saber a modelagem de dados e a (utilizando modelos de entidades e relacionamentos), a modelagem funcional (utilizando Diagramas de Fluxo de Dados - DFDs) e a modelagem de controle (utilizando diagramas de transio de estados). Isso bastante natural, j ca e a que a anlise essencial , de fato, uma extenso da anlise estruturada. Na a e a a realidade, a principal diferena entre a anlise essencial e a anlise estruturada c a a est na estratgia para atacar o problema: a primeira defende uma abordagem a e baseada em eventos, onde a anlise de eventos passa a ser um passo fundamental, a a segunda baseada apenas na decomposio top-down da funcionalidade do e ca sistema.
9.4
Gerenciamento de Requisitos
Gerenciar requisitos consiste de procedimentos para coletar, vericar e avaliar mudanas, de forma melhor administr-las. E o considerado uma das primeiras c a a reas chave para melhoria de qualidade. No gerenciamento de requisitos um conceito importante o de rastreabilidade. A rastreabilidade pode ser vista e como a habilidade de acompanhar e descrever a vida de um requisito em ambas as direes. Rastrear envolve identicar links entre requisitos, fontes dos requico sitos e design do sistema. As ferramentas mais utilizadas para rastreamento de
116
requisitos so as Matrizes de Rastreabibilidade (Traceability Matrix ), que usuala mente correlacionam requisitos com casos de testes, e tcnicas de Referncias e e 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
Cap tulo 10
Mtricas e
Mtricas devem ser coletadas de modo que os indicadores de processo e de e produto possam ser determinados. Indicadores de processo permitem ` orgaa nizao de engenharia de software ter idia da eccia de um processo existente ca e a (o paradigma, as tarefas de engenharia de software, os produtos de trabalho e os marcos de tempo). J os indicadores de projeto permitem ao gerente de projeto a de software: Avaliar o status de um projeto em andamento. Acompanhar riscos potenciais. Descobrir reas-problemas anter que elas se tornem cr a ticas. Ajustar uxo 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 mtricas podem ser usadas para determinar e indicadores de projeto e de processo.
10.1
Mtricas de processo e aperfeioamento de e c processo de software
Ns medimos a eccia de um processo de software indiretamente. H usos o a a pblicos e privados de diferentes tipos de dados do processo. As mtricas cou e letadas com base individual dever ser privadas e servir como indicador apenas para o indiv duo. Exemplo de mtricas privadas incluem porporo de defeitos e ca (por ind viduo e por mdulo) e erros encontrados durante o desenvolvimento. o Mtricas pblicas geralmente assimilam informaes, que eram originalmente e u co privadas. Porpores de defeitos de projeto (absolutamente no atribu co a veis a um certo indiv duo), esforo, tempo transcorrido e dados relacionados so coletac a dos e avaliados numa tentativa de sescobrir indicadores, que possam aperfeioar c o desempenho do processo organizacional. H uma sutil diferena entre erros e defeitos. Um defeito ocorre quando a c atividades de garantia de qualidade deixam de descobrir um erro num produto produzido durante o processo de software. 118
` A medida que uma organizao sente-se mais confortvel, coletanto e usando ca a mtricas de processo de software, a derivao de indicadores simples d lugar e ca a a uma abordagem mais rigorosa, chamada melhoria estat stica do processo de software (statistical software process improvemente, SPPI). Essencialmente, a SSPI usa a anlise de falhas de software para coletar informao sobre todos a ca erros e defeitos. A anlise de falhas funciona da seguinte maneira: a 1. Todos os erros e defeitos so categorizados por origem (falha de especia cao, falha de lgica, no atendimento a padres). ca o a o 2. O custo para corrigir cada erro e defeito registrado. e 3. A quantidade de erros e defeitos de cada categoria contada e ordenada e de forma decrescente. 4. O custo total de erros e defeitos de cada categoria calculado. e 5. Os dados resultantes so analisados, para descobrir as categorias que proa duzem um maior custo para a organizao. ca 6. So desenvolvidos planos para modicar o processo, com o objetivo de a eliminar (ou reduzir a freqncia das) classes de erros e defeitos que so ue a mais dispendiosas. Para a organizao dessas mtricas so utilizados o grco de pizza que associa ca e a a os erros e defeitos `s suas origens e o diagrama espinha de peixe. a
10.2
Mtricas de projeto e
As mtricas de projeto so usadas para evitar atrasos, avaliar a qualidade e no e a a ultrapassar os custos permitidos. A primeira aplicao das mtricas de projeto, ca e na maioria dos projetos de software, ocorre durante a estimativa. Mtricas e coletadas de projetos anteriores so usadas como base e ` medida que o projeto a a prossegue, medidas de esforo e de tempo so comparadas com as estimativas c a originais. Dessa maneira, o gerente do projeto monitora e controla o progresso. ` A medida que o trabalho tcnico se inicia, outras mtricas de projeto comeam e e c a ter importncia. A taxa de produo, representada em termos de pginas de a ca a documentao, horas de reviso, pontos por funo e linhas de cdigo fonte ca a ca o ` entregue, medida. A medida que o software evolui, mtricas tcnicas so e e e a coletadas para avaliar a qualidade do projeto.
10.3
Medio de software ca
As medies so categorizadas em medidas diretas e indiretas. As medidas dico a retas do processo de engenharia de software incluem custo, linhas de cdigo o (lines of code, LOC) produzidas, velocidade de execuo, tamanho de memria ca o e defeitos relatados durante um certo per odo. Medidas indiretas do produto incluem funcionalidade, qualidade, complexidade, ecincia, conabilidade, manutenie bilidade e muitas outras habilidades.
119
10.3.1
Mtricas orientadas a tamanho e
So mtricas baseadas em linhas de cdigo. Mtricas orientadas a tamanho a e o e no so universalmente aceitas como o melhor modo de medir o processo de a a desenvolvimento de software. Os opositores argumentam que essas mtricas pee nalizam programas curtos e bem feitos e que medidas de LOC so depndentes a e da linguagem de programao. Por outro lado, existem muitos modelos de estica mativas que usam LOC ou KLOC como entrada chave e essas mtricas podem e ser facilmente coletadas. As mtricas orientadas a tamanho mais utilizadas e incluem: Erros por KLOC (milhares de linha cdigo). o Defeitos por KLOC. $ por LOC. Pginas de documentao por KLOC. a ca Erros por pessoa-ms. e LOC por pessoa-ms. e $ por pgina de documentao. a ca
10.3.2
Mtricas orientadas a funo e ca
Mtricas de software orientadas a funo usam uma medida da funcionalidade e ca entregue pela aplicao como valor de normalizao. ca ca Pontos por funo so calculados completando a tabela 10.1. Cinco caracca a ter sticas do dom nio da informao so determinadas e as contagens so regca a a istradas na tabela. Essas caracter sticas so denidas da seguinte maneira: a Quantidade de entradas do usurio. So contadas as entradas do usurio a a a que fornecem dados distintos. Quantidade de sa das do usurio. So contados telas, relatrios, mensagens a a o de erros etc. N mero de consultas do usurio. So contadas consultas distintas. Uma u a a consulta denida como um entrada que resulta na gerao de alguma e ca resposta imediata.
Quantidade de arquivos. Cada grupo de dados lgico (que pode ser parte o de uma base de dados maior ou um arquivo separado) contado. Esses e grupos de dados tambm so conhecidos como arquivos mestres lgicos. e a o Quantidade de interfaces externas. Todas as interfaces em linguagem de mquina (p. ex., arquivos de dados em um meio de armazenamento), que a so usadas para transmitir informao a outro sistema so contadas. a ca a Uma vez coletados esses dados, um valor de complexidade associado com e cada contagem. Para contar pontos por funo (function points, FP), usada ca e a seguinte relao: ca FP = total da contagem [0, 65 + 0, 01 (Fi )] Os Fi so valores de ajuste de complexidade, baseados nas respostas das a seguintes perguntas: 120
Parmetro de medio a ca Quantidade de entradas do usurio a Quantidade de sa das do usurio a Quantidade de consultas do usurio a Nmero de arquivos u Quantidade de interfaces externas
Contagem x x x x x
Simples 3 4 3 7 5
Mdio e 4 5 4 10 7
Complexo 6 7 6 15 10
Total
Tabela 10.1: Tabelas das caracter sticas dos pontos de funo ca 1. O sistema requer salvamento (backup) e recuperao (recovery)? ca 2. Comunicaes de dados so necessrias? co a a 3. H funes de processamento distribu a co do? 4. O desempenho cr e tico? 5. O sistema vai ser executado em um ambiente operacional existente, intensamente utilizado? 6. O sistema requer entradas de dados on-line? 7. A entrada de dados on-line exige que a transao de entrada seja conca stru atravs de vrias telas ou operaes? da e a co 8. Os arquivos mestre so atualizados on-line? a 9. As entradas, sa das, arquivos ou consultas so complexas? a 10. O processomento interno complexo? e 11. O cdigo projetado para ser reusado? o e 12. A converso e a instalao esto inclu a ca a das no projeto? 13. O sistema est projetado para instalaes mltiplas em diferentes orgaa co u nizaes? co 14. A aplicao est projetada para facilitar modicaes e para facilidade de ca a co uso pelo usurio? a
Cada uma dessas questes respondida usando uma escala que varia entre 0 a o e 5. Os valores constantes e os fatores de peso podem ser ajustado empiricamente para a equao dos pontos de funo. So exemplos importantes de medidas de ca ca a produtividade, qualidade e outros atributos de software as mtricas: e Erros por FP. Defeitos por FP. $ por FP. Pginas de documentaao por FP. a c FP por pessoa-ms. e 121
10.3.3
Mtricas de pontos por funao estendidas e c
A medida de pontos por funo foi originalmente projetada para ser usada ca em aplicaes de sistemas de informao comerciais. A medida de pontos por co ca funo cou inadequada para muitos sistemas embutidos e de engenharia (que ca enfatizam funo e controle). ca Uma extenso de pontos por funo, chamada pontos por caracter a ca stica utilizada em eplicaes de software de sistemas. Para calcular pontos por caracco ter stica, valores de dom nio de informao so novamente contados e ponderca a ados. Alm disso, a mtrica pontos por caracter e e stica trata uma nova caracter sitca do software: algoritmos. Outra extenso de pontos por funo, para sistemas em tempo real e proa ca dutos de engenharia, foi desenvolvida pela Boeing. Essa abordagem integra a dimenso de dados do software com as dimenses funcional e de controle para a o forncer uma medida orientada a funo, adequada a aplicaes que enfatizam ca co as capacidades de funo e controle. Essa extenso chamada de pontos por ca a e funo 3D. As trs dimenses so: ca e o a Dimenso de dados. Semelhante a contagem de pontos por funo tradia ca cional. Dimenso funcional. Considera a quantidade de operaes internas necessrias a co a para transformar dados de entrada para transformar dados de entrada em sa da. Dimenso de controle. E medida contando a quantidade de transies entre a co estados.
10.4
Mtricas de qualidade de software e
A medio da qualidade de software uma atividade de natureza subjetiva. ca e Qualidade de software uma mistura complexa de fatores que vo variar com e a cada aplicao diferente e com os clientes que as encomendam. As principais ca medidas so mostradas a seguir: a Correo. A medida mais comum defeitos por KLOC. Para ns de avaliao ca e ca de qualidade, defeitos so contados durante um per a odo padro, tipicaa mente um ano.
Manutenibilidade. Uma mtrica utilizada o tempo mdio para modicao e e e ca (mean-time-to-change, MTTC), que o tempo despendido para analisar o e pedido de modicao, projetar uma modicao adequada, implementar ca ca a modicao, test-la e distribu para todos os usurios. Outra mtrica ca a -la a e chamada preju - custo para corrigir defeitos encontrados depois que e zo o software foi entregue a seus usurios nais. a Integridade. E a capacidade do sistema resistir ` ataques (tanto acidentais a quanto intencionais). Ameaa a probabilidade de um ataque ocorrer c e dentro de um certo per odo. Segurana. E a probabilidade de um ataque c ser repelido. A integridade do sistema pode ser ento denido como intea gridade = (1 ameaca) (1 seguranca).
122
Utilizao. Se amigvei ao uso. Pode ser medida em quatro tpicos: (1) ca e a o aptido f a sica ou intelectual necessria para aprender a lidar com o sistema, a (2) o tempo necessrio para se tornar moderadamente eciente no uso a do sistema, (3) o aumento l quido de produtividade e (4) uma avaliao ca subjetiva das atitudes dos usurios com relao ao sistema. a ca Outra medio muito utilizada a ecincia na remoo de defeitos defect ca e e ca removal eciency, DRE). A DRE uma medida da capacidade de ltragem das e atividades de controle e garantia de qualidade de software, ` medida que so a a aplicadas. A frmula utilizada DRE = E/(E + D). Onde E a quantidade o e e de erros encontrados e D a quantidade de defeitos. As principais formas de classicar fatores de qualidade so apresentadas nas a subsees a seguir. co
10.4.1
Fatores de qualidade de McCall
Os fatores de qualidade de McCall concentram-se nos trs aspectos importantes e de um produto de software: suas caracter sticas operacionais, sua habilidade de passar por modicaes e sua adaptabilidade a novos ambientes. A seguir so co a listados esses aspectos e os seus respectivos fatores: Operao do produto. Correo, conabilidade, utilizao, integridade e ecincia. ca ca ca e Reviso do produto. Mantenabilidade, exibilidade e testabilidade. a Transio do produto. Portabilidade, reutilizao e interoperabilidade. ca ca E dif desenvolver medidas diretas desses fatores. Assim, um conjunto de cil mtricas denido e usado para desenvolver expresses para cada um dos fatores e e o de acordo com a seguinte relao: Fq = c1 m1 + c2 m2 ... + cn mn , em que ca Fq um fator de qualidade de software, cn so coecientes de regresso, mn so e a a a as mtricas que afetam o fator de qualidade. Infelizmente, muitas das mtricas e e denidas podem ser medidas apenas sunjetivamente. As mtricas podem estar e em forma de checklist que usada para atribuir um grau a atributos espec e cos do software. O peso atribu a cada mtrica dependente de produtos e do e e preocupaes locais. co
10.4.2
FURPS
A Hewlett-Packard desenvolveu um conjunto de fatores de qualidade que recebeu a sigla FURPS: funcionalidade, utilizao, conabilidade, desempenho e ca suportabilidade. Esses fatores podem ser denidos da seguinte maneira: Funcionalidade. Avaliada pelo conjunto de caracter sticas e capacidades do programa. Utilizao. Avaliada considerando fatores humanos como esttica, consistncia ca e e e documentao. ca Conabilidade. Avaliada medindo a freqncia e a severidade das falhas, a ue preciso dos resultados de sa a da, o tempo mdio entre falhas (MTTF), a e capacidade de recuperao de falhas e previsibilidade do programa. ca
123
Desempenho. Medido pela velocidade de processamento, tempo de resposta, consumo de recursos, throughput e ecincia. e Suportabilidade. Combina a capacidade de estender o programa (estensibilidade), adaptabilidade e reparabilidade.
10.4.3
ISO 9126
A norma da ISO identica seis atributos-chave de qualidade: Funcionalidade. Grau com que o software satisfaz as necessidades declaradas com os subatributos - adequabilidade, preciso, interoperabilidade, atendibila idade e segurana. c Conabilidade. Per odo de tempo em que o software est dispon para uso a vel com os subatributos - maturidade, tolerncia a falha e recuperabilidade a Utilizao. Grau em que o software fcil de usar com os subatributos ca e a inteligibilidade, adestrabilidade e operabilidade. Ecincia. Grau em que o software faz uso otimizado dos recursos do sistema e com os subatributos - comportamento em relao ao tempo e comportaca mento em relao aos recursos. ca Mantenabilidade. Facilidade com a qual podem ser feitos reparos no software 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 no necessariamente se prestam a medidas diretas. No entanto, a fornecem de fato uma base valiosa para medidas indiretas e uma excelente lista de vericao para avaliar a qualidade de um sistema. ca
10.5
Estimativas
Muitas vezes, as estimativas so feitas usando-se a experincia passada como a e unico guia. Mas se um novo projeto for totalmente diferente dos projetos re alizados at o momento? Assim, apenas a experncia passada talvez no seja e e a suciente. Vrias tcnicas de estimativa esto dispon a e a veis. Embora cada uma tenha suas particularidades, todas tm os seguintes atributos: e 1. O escopo do projeto deve estar estabelecido. 2. Mtricas de software so utilizadas e o histrico usado como uma base e a o e a partir da qual estimativas so feitas. a 3. O projeto dividido em pequenas partes que so estimadas individuale a mente.
124
10.5.1
COCOMO (Constructive Cost Model)
O COCOMO o modelo de estimativa emp e rico mais utilizado na indstria. u Existem trs modelos neste mtodo: e e COCOMO Bsico. E um modelo esttico de valor simples que computa o a a esforo (e custo) de desenvolvimento de software como uma funo do c ca tamanho de programa expresso em linha de cdigo estimadas. o COCOMO Intermedirio. Computa o esforo de desenvolvimento de softa c ware como uma funo do tamanho do programa e de um conjunto de ca direcionadores de custo que incluem avaliaes subjetivas do produto, do co hardware, do pessoal e dos atributos do projeto. COCOMO Avanado. Incorpora todas as caracter c sticas da verso intera mediria, com uma avaliao do impacto dos direcionadores de custo sobre a ca cada passo (anlise, projeto, etc.) do processo de engenharia de software. a O COCOMO classica os projetos em trs tipos: e Modelo orgnico (ou convencional). Projetos de software simples, relatia vamente pequenos, nos quais pequenas equipes com boa experincia em e aplicaes trabalham num conjunto de requisitos no to r co a a gidos. Outras caracter sticas: ambiente estvel de desenvolvimento, algoritmos simples, a prmio relativamente baixo para trmino antes do prazo, tamanho relatie e vamente pequeno, projetos na faixa de 50.000 linhas de cdigo. o Modelo semidestacado (ou difuso). Projeto de software intermedirio (em a tamanho e complexidade) onde a equipe mescla grande e pouca experincia e com aplicaes, grande e pouca experincia com a tecnologia, o tamanho co e dos software varia at 300.000 linhas de cdigo. e o Modelo embutido (ou restrito). Um projeto que deve ser desenvolvido dentro de um conjunto r gido de restries operacionais, de hardware e de co software. O COCOMO II, assim como o seu predecessor na verdade uma hierarquia e de modelos que trata das seguintes reas: a Modelo de composio de aplicao. Usado durante os primeiros estgios ca ca a do processo.
Modelo do primeiro estgio de projeto. Usado aps os requisitos terem a o sido estabilizados e a arquitetura bsica do software ter sido estabelecida. a Modelo para o estgio aps a arquitetura. Usado durante a construo do a o ca software. O COCOMO II usa pontos por objeto. Como pontos por funo, o pontos por ca objeto uma medida indireta de software que calculada usando-se a contagem e e da quantidade de telas (na interface com o usurio, relatrios e componentes. a o Cada instncia de objeto em um dos trs n a e veis de complexidade (simples, mdio, e dif cil). Essencialmente, a complexidade funo da quantidade e fonte das e ca tabelas de dados do cliente e servidores, que so necessrias para gerar a tela ou a a
125
relatrio, e da quantidade de vistas ou sees apresentadas como parte da tela o co ou relatrio. o Deve-se notar que outros modelos de estimativa mais sosticados (usando FP e KLOC) tambm esto dispon e a veis como parte do COCOMO II.
126
Cap tulo 11
Testes
Teste um processo de execuo de um programa com a nalidade de encontrar e ca um erro. Os teses podem ser planejados e projetados antes que qualquer cdigo o 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 nalmente em todo o sistema. A testabilidade de software a facilidade com que o programa pode ser e testado. Existem mtricas que podem medir a testabilidade do software. e Quando o software para computador considerado, teste caixa-preta referee se a testes que so conduzidos na interface do software. a Um teste de caixa-branca baseado num exame rigoroso do detalhe proe cedimental. Caminhos lgicos internos do software so testados, denindo cao a sos de testes que exercitam conjuntos espec cos de condies ou ciclos. Teste co caixa-branca completo imposs e vel para grandes sistemas de software. Um teste caixa-branca no deve, no entanto, ser descartado como no prtico. Um a a a nmero limitado de caminhos lgicos importantes pode ser selecionado e exerciu o tado. H trs motivos importantes pelos quais se deve usar testes caixa-branca: a e Os erros tendem a ocorrer em condies ou controle que esto fora da co a funo principal. ca Freqentemente acreditamos que um caminho lgico no provcel de ser u o a e a executado quando, na realidade, ele pode ser executado em base regular.
E provvel que um erro tipogrco exista tanto num caminho lgico oba a o scuro quanto num caminho principal.
11.1
Teste de caminho bsico a
Teste de caminho bsico uma tcnica de teste caixa-branca proposta iniciala e e mente por Tom McCabe. O mtodo de caminho bsico permite ao projetista e a de casos de teste originar uma medida da complexidade lgica de um projeto o procedimental e usar essa medida como guia para denir um conjunto bsico a de caminhos de execuo. Casos de testes derivados para exercitar o conjunto ca bsico executam garantidamente cada comando programa pelo menos uma vez a durante o teste. 127
O grafo de uxo mostra mostra o uxo de controle lgico. Cada n do o o grafo de uxo representa um ou mais comando procedimentais. As arestas representam o uxo de controle. As reas dlimitadas por arestras e ns so a o a chamadas regies. Cada n que contm uma condio chamado de n predicado o o e ca e o e caracterizada por duas ou mais arestas saindo dele. e Complexidade ciclomtica a mtrica de software que fornce uma medida a e e quantitativa da complexidade lgica do programa. O valor calculado para a o complexidade ciclomtica dene o nmero de caminhos independentes no cona u 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 qualquer caminho ao longo do programa que e introduz pelo menos um novo conjunto de comandos de processamento ou uma nova condio. Um conjunto-base um conjunto de caminhos em que todo ca e comando do programa ter sido garantidamente executado pelo menos uma vez a e cada condio ter sido executada no seu lado verdadeiro e no seu lado falso. ca a A complexidade ciclomtica calculada de trs maneiras: a e e 1. O nmero de regies do grafo de uxo. u o 2. V (G) = E N + 2 em que E o nmero de arestas e N o nmero de ns. e u u o 3. V (G) = P + 1 em que P o nmero de ns predicados. e u o Os seguintes passos podem ser aplicados para derivao de casos de teste: ca 1. Usando o projeto ou cdigo como base, desenhe o grafo de uxo correo spondente. 2. Determine a complexidade ciclomtica do grafo de uxo resultante. a 3. Determine um conjunto-base de caminhos linearmente independentes. 4. Prepare casos de teste que vo forar a execuo de cada caminho do a c ca conjunto-base. Uma matriz de grafo uma matriz quadrada, cujo nmero de colunas e e u linhas igual ao nmero de ns do grafo de uxo. Adicionando um peso de e u o ligao a cada entrada da matriz, a matriz de grafo pode tornar-se uma possante ca ferramenta para avaliar a estrutura de controle do programa durante o teste. Em sua forma mais simples, o peso da ligao 1 (existe uma conexo) ou ca e a 0 (no existe uma conexo). Outros pesos podem ser atribu a a dos com outras propriedades: A probabilidade de que uma ligao (aresta) ser executada. ca a O tempo de processamento gasto durante o percurso de uma ligao. ca A memria necessria durante o percurso de uma ligao. o a ca Os recursos necessrios durante o percurso de uma ligao. a ca Existem algoritmos que podem ser aplicados `s matrizes de grafo. Usando a essaas tcnicas, a anlise necessria para projetar casos de teste pode ser parcial e a a ou totalmente automatizada. 128
11.2
Teste de estrutura de controle
A tcnica de teste de estrutura de controle ampliam a cobertura da tcnica de e e teste de caminho bsico e melhoram a qualidade do teste caixa-branca. a
11.2.1
Teste de condio ca
Teste de condio um mtodo de projeto de caso de teste que exercita as ca e e condies lgicas contidas em um mdulo de programa. Uma condio simples co o o ca uma varivel booleana ou uma expresso relacional, possivelmente precedida e a a por um operador de negao. Uma condio composta composta de duas ou ca ca e mais condies simples, operadores booleanos e parnteses. co e Diversas estratgias para teste de condio tm sido propostas. O teste de e ca e desvio provavelmente a estratgia de teste de condio mais simples. Para e e ca uma condio composta C, os ramos verdadeiro e falso de C e cada condio ca ca simples de C precisam ser executadas pelo menos uma vez. O teste de dom nio requer que trs ou quatro testes sejam derivados para e uma expresso relacional. Para uma expresso relacional da forma a a E1 < operador relacional > E2 trs testes so necessrios para tornar o valor de E1 maior que, igual a, ou menor e a a que o de E2 . Para uma expresso booleana com n variveis, todos os 2n poss a a veis testes so necessrios (n > 0), mas prtica somente quando n pequeno. a a e a e Caso uma expresso booleana seja singular (na qual cada varivel ocorre a a apenas uma vez), h como gerar um conjunto de testes com menos do que 2n a testes tal que esse conjunto de testes garante a deteco de erros de operadores ca booleanos mltiplos e tambm efetivo para detectar outros erros. Uma delas u e e e a tcnica de teste de desvio e operador relacional (branch and relational operator, e BRO). Ela usa restries de condio para uma condio C. Uma restrio de co ca ca ca condio para C com n condies simples denida como (D1 , D2 , . . . , Dn ), ca co e em que Di (0 < i n) um s e mbolo que especica uma restrio sobre o ca resultado da i-sima condio simples da condio C. Diz-se que uma restrio e ca ca ca de condio D para uma condio C coberta por uma execuo de C se, ca ca e ca durante a execuo de C, o resultado de cada condio simples de C satisfaz a ca ca correspondente restrio em D. No entendeu nada? Como exemplo, considere ca a a condio: ca
C1 : B1 &B2 em que B1 e B2 so variveis booleanas. A restrio de condio para C1 a a ca ca e da forma (D1 , D2 ), em que cada um de D1 e D2 t ou f . O valor (t, f ) e e uma restrio de condio para C1 . A estratgia de teste BRO exige que o ca ca e conjunto de restries {(t, t), (t, f ), (f, t)} seja coberto pelas execues de C1 . co co Se C1 est incorreto, pelo menos uma das condies do conjunto vai fazer C1 a co falhar. Outro exemplo: C2 : B1 &(E3 = E4 ) possui o conjunto de restries co {(t, =), (f, =), (t, <), (t, >)}, sendo E3 e E4 expresses aritmticas. o e
129
11.2.2
Teste de uxo de dados
O metdo de teste de uxo de dados seleciona caminhos de teste de um proo grama de acordo com a localizao das denies e do uso das variveis no ca co a programa. Para ilustrar a abordagem de teste de uxo de dados, considere que cada comando de um programa atribu um nmero de comando unico e e do u que cada funo no modica seus parmetros ou variveis globais. Para um ca a a a comando com S como seu nmero de comando, u DEF (S) = {X/comando S contm uma denio de X} e ca U SO(S) = {X/comando S contm um uso de X} e Se o comando S um comando se ou de ciclo, seu conjunto DEF vazio e e e seu conjunto USO baseado na condio do comando S. A denio da varivel e ca ca a X no comando S considerada como estando viva no comando S se existe um e caminho do comando S para o comando S que no contm qualquer outra a e denio de X. ca Uma cadeia denio-uso (DU) da varivel X da forma [X, S, S ] em que S ca a e e S so nmeros de comandos, X pertence a DEF (S) e U SO(S ), e a denio a u ca de X no comando S est viva no comando S . a A estratgia de teste DU exige que cada cadeia DU seja coberta pelo menos e uma vez. Foi mostrado que o teste DU no cobre todos os ramos em situaes a co raras. A abordagem de teste de uxo de dados efetiva para deteco de erros. e ca No entanto, os problemas de medida da cobertura e de seleo dos caminhos ca de teste so mais dif a ceis do que os problemas correspondentes para o teste de condio. ca
11.2.3
Teste de ciclo
Teste de ciclo uma tcnica de teste caixa-branca que focaliza exclusivamente e e a validade de construes de ciclo. Quatro diferentes classes de ciclos podem co ser denidas: Ciclos simples. O seguinte conjunto de teste pode ser aplicado a ciclos simples em que n o nmero mximo de passagens permitidas no ciclo. e u a 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 tcnicas de cice los simples neste caso. Uma abordagem sugerida: e 1. Comece no ciclo mais interno. Ajuste todos os outros cilos para o valores m nimos. 2. Conduze testes de ciclo simples para o ciclo mais interno enquanto mantm os ciclos externo nos seus valores m e nimos de iterao. ca 3. Trabalhe em direao ao extereior, conduzindo testes para o ciclo c seguinte. 4. Continue at que todos os ciclos tenham sido testados. e 130
Ciclos concatenados. A mesma abordagem para o ciclo simples a menos que o mesmo contador utilizado nos ciclos concatenados. Neste caso, ree e comendada a abordagem a ciclos aninhados. Ciclos desestruturados. Sempre que poss vel essa classe de ciclos deve ser reprojetada.
11.3
Teste caixa-preta
Um teste caixa-preta, tambm chamado de teste comportamental, focaliza os reqe uisitos funcionais do software. O teste caixa-preta tende a ser aplicado durante os ultimos estgios do teste. a
11.3.1
Mtodos de teste baseados em grafo e
Os objetos que esto modelados no software e as relaes que conectam esses a co objetos so utilizadas para criar um grafo. Os ns representam os objetos, as a o arestas representam as ligaes, os pesos de n descrevem as propriedade de um co o objeto, assim como os pesos das arestas representam propriedades das ligaes. co Uma ligao direcionada (representada por uma seta) indica que a relao se ca ca move em apenas uma direo. Ligaes paralelas so usadas quando diversas ca co a relaes so estabelecidas entre os ns. co a o Os mtodos de teste de comportamento que podem fazer usos de grafos so: e a Modelagem de uxo de transao. Os ns representam passos em alguma ca o transao e as arestam representam conexes lgicas. ca o o Modelagem de estado nito. Os ns representam diferentes estados do softo ware observveis pelo usurio e as aresta representam as transies. a a co Modelagem do uxo de dados. Os ns so objetos de daods e as ligaes o a co so transformaes que ocorrem para traduzir um objeto de dados em a co outro.
11.3.2
Particionamento de equivalncia e
O particionamento de equivalncia um mtodo de teste caixa-preta que divide e e e o dom nio de entrada de um programa em classes de dados, das quais casos de teste podem ser derivados. Uma classe de equivalncia representa um cone junto de estados vlidos ou invlidos para condies de entrada. Classes de a a co equivalncia podem ser denidas de acordo com as seguintes diretrizes: e 1. Se uma condio de entrada especica um intervalo, uma classe de equivalncia ca e vlida e duas invlidas so denidas. a a a 2. Se uma condio de entrada exige um valor espec ca co, uma classe de equivalncia vlida e duas invlidas so denidas. e a a a 3. Se uma condio de entrada especica um membro de um conjunto, uma ca classe de quivalncia vlida e uma invlida so denidas. e a a a 4. Se uma condio de entrada booleana, uma classe de equivalncia vlida ca e e a e uma invlida so denidas. a a 131
Um elemento pode ter mais de uma condio de entrada. Por exemplo, ca considere uma entrada de senha , h condio de entrada booleana (pode estar a ca ou no presente) e condio de entrada de valor (cadeia de seis caracteres). a ca
11.3.3
Anlise de valor limite a
Um grande nmero de erros tende a ocorrer nas fronteiras do dom u nio de en trada. E por essa razo que a anlise de valor-limite (boundary value analysis, a a BVA) foi desenvolvida como tcnica de teste. e A BVA leva ` seleo de casos de teste nas bordas da classe. Em vez de a ca focalizar somente as condies de entrada, a BVA deriva casos de teste tambm co e para o dom nio de sa da. Se uma condio de entrada especica um intervalo ou um valor limitado ca 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 condies de sa co da. Se as estruturas de dados tm limites prescritos, certique-se e de projetar um caso de teste para exercitar a estrutura de dados no seu limite.
11.3.4
Teste de comparao ca
Quando um software redundante desenvolvido (para aplicaes cr e co ticas), equipes de engenheiros de software separadas desenvolvem verses independentes de uma o aplicao usando a mesma especicao. Em tais situaes, cada verso pode ca ca co a ser testada com os mesmos dados de teste para garantir que todas fornecem sa idntica. Depois, todas as verses so executadas em paralelo com comda e o a parao em tempo real para garantir consistncia. Essas verses independentes ca e o formam a base da tcnica de teste caixa-preta chamada teste de comparao ou e ca teste de emparelhamento. Quando mltiplas implementaes da mesma especicao tivem sido prou co ca duzidas, casos de teste projetadados usando outras tcnicas de caixa-preta e fornecem entradas a cada verso do software. Se a sa de cada verso a a da a e mesma, considerado que todas as implementaes esto corretas. Se a sa e co a da e diferente, cada uma das aplicaes investigada para determinar se um defeito co e em uma ou mais verses responsvel pela diferena. o e a c O teste de comparao no a toda prova, se a especicao estiver errada, ca a e ca todas as verses iro provavelmente reetir o erro. Alm disso, se cada uma das o a e verses independentes produzir resultados idnticos mas incorretos, o teste de o e comparao vai falhar na deteco do erro. ca ca
11.3.5
Teste de matriz ortogonal
Teste de matriz ortogonal pode ser aplicado a problemas nos quais o dom nio de entrada relativamente pequeno, mas grande demais para acomodar teste e exaustivo. Quando o teste de matriz ortogonal ocorre, criada uma matriz e ortogonal L9 de casos de teste. A matriz ortogonal L9 tem uma propriedade de balanceamento (esto distribu a dos uniformemente pelo dom nio de teste). A abordagem de teste de matriz ortogonal nos possibilita obter boa cobertura de teste com muito menos casos de teste que a estratgia exaustiva. Outras e denies so importantes: co a
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 n veis espec cos de dois parmetros a ocorrem simultaneamente, ele chamado de falha de modo duplo. E a ine terao danosa entre dois parmetros de teste. ca a Matrizes ortogonais s podem garantir a deteco de falhas de modo sino ca gular e duplo. No entanto, muitas falhas de multimodo so tembm dea e tectadas por esses testes.
11.4
Teste de ambientes, arquiteturas e aplicaes co especializadas
Podemos citar as tcnicas especializadas de testes: e Teste de GUI. Como muitas GUI modernas tm a mesma aparncia e fune e cionamento, uma srie de testes padro pode ser derivada. Devido ao e a grande nmero de operaes GUI, o teste deve ser conduzido usando feru co ramentas automatizadas. Teste de arquiteturas cliente/servidor. A natureza distribu diculta muito, da os teste so consideravelmente mais dif que em aplicaes isoladas. a cil co Teste da documentao e dispositivos de ajuda. Pode ser abordado em ca duas fases. A primeira fase, reviso e inspeno, examina o documento a ca quanto ` clare editorial. A segunda fase, teste ao vivo, usa a documentao a ca em conjunto com o uso do programa real. Nesta fase, os vrios mtodos a e de caixa-preta podem ser utilizados. Teste de sistemas de tempo real. O projetista de casos de teste no tem a apenas que considerar casos de teste caixa-branca e caixa-preta, mas tambm manipulao de eventos (processamento de interrupes), a teme ca co pestividade dos dados e o paralelismo das tarefas que manipulam os dados. Uma estratgia global de quatro passoas pode ser proposta: e Teste de tarefa. Testes de caixa-branca e de caixa-preta so projetados a e executados para cada tarefa. Teste comportamental. E simulado o comportamento de um sistema de tempo real e examinado seu comportamento como conseqncia ue de eventos externos. Testes intertarefas. Tarefas ass ncornas que se comunicam so testadas a com diferentes taxas de dados e carga de processamento para detectar se erros de sincronizao entre tarefas vo ocorrer. ca a Teste de sistema. O software e o hardware so integrados e todo um a conjunto de testes de sistema conduzido numa tentativa de descobrir e erros na interface software-hardware.
133
11.5
Estratgia de teste de software e
O projeto efetivo de caso de testes importante, mas no suciente para o e a sucesso da atividade de testes. A estratgia, isto , a srie planejada de ree e e alizao de testes, tambm crucial. Basicamente, h trs grandes fases de ca e e a e teste: Teste de unidade. Tem por objetivo testar a menor unidade do projeto (um componente de software que no pode ser subdividido), procurando idena ticar erros de lgica e de implementao em cada mdulo separamente. o ca o Teste de integrao. Visa descobrir erros associados `s interfaces entre os ca a mdulos quando esses so integrados para formar a estrutura do produto o a de software. Teste de sistema. Tem por objetivo identicar erros de funes (requisitos co funcionais) e caracter sticas de desempenho (requisito no funcional) que a no estejam de acordo com as especicaes. a co Tipicamente, os primeiros testes focalizam componentes individuais e aplicam testes caixa-branca e caixa-preta. Na integrao, o foco o projeto e a arca e quitetura do sistema. Finalmente, uma srie de testes de alto n executada e vel e quando o sistema estiver operacional, visando descobrir erros nos requisitos. No teste de unidade, faz-se necessrio construir pequenos componentes para a permitir testar mdulos invidualmente, os ditos drivers e stubs. Um driver um o e programa responsvel pela ativao e coordenao do teste de uma unidade. Ele a ca ca responsvel por receber dados de teste fornecidos pelo testador, passar esses e a dados para a unidade que est sendo testada, obter os resultados produzidos e a apresent-los ao testador. Um stub uma unidade que substitui, na hora do a e teste, uma outra unidade chamada pela unidade que est sendo testada. Em a geral, um stub simula o comportamento de uma unidade chamada com o m nimo de computao ou manipulao de dados. ca ca A abordagem de integraao de mdulos pode ter impacto na quantidade de c o drivers e stubs a ser constru da. Sejam as seguintes abordagens: Integrao ascendente (bottom-up). Cada mdulo no n inferior da hica o vel erarquia testado individualmente. A seguir, so testados mdulos que e a o chamam os previamentes testados. Neste caso, apenas drivers so necessrios. a a Integrao descendente (top-down). Comea de cima para baixo. Apenas ca c stubs so necessrios. a a Sandu che. Considera uma camada alvo no meio da hierarquia e utiliza abordagens ascendente e descendente. Big-bang. Testar individualemte cada mdulo e depois integr-los de uma s o a o vez. Neste caso, tanto drivers quanto stubs so necessrios para cada a a mdulo. Trabalhoso e suicida. o Os testes de sistema incluem diversos tipos de testes, realizados na seguinte ordem: Teste funcional. Verica se o sistema integrado realiza as funes especico cadas nos requisitos. 134
Teste de desempenho. Verica se o sistema integrado atende os requisitos no funcionais do sistema (ecincia, segurana e conabilidade). a e c Teste de aceitao. Realizado pelos clientes. Assegura que o sistema solicica tado o que foi constru e do. Teste de instalao. Necessrio quando os testes de aceitao no so feitos ca a ca a a onde o software ser realmente instalado. a
135
Cap tulo 12
UML
12.1 Diagrama de caso de uso
Diagramas de caso de uso descrevem relacionamentos e dependncias entre um e 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 tang vel. Casos de uso so descries de a co interaes t co picas entre os usurios de um sistema e o sistema propriamente dito. a Eles representam a interface externa do sistema e especicam um conjunto de exigncias do que o sistema deve fazer. e Quando trabalhar com Casos de Uso, importante lembrar-se de algumas e regras simples: Cada Caso de Uso est relacionado com no m a nimo um ator Cada Caso de Uso possui um iniciador (isto um ator) e Cada Caso de Uso liga-se a um resultado relevante (um resultado com valor de negcio) o Casos de uso tambm podem ter relacionamentos com outros casos de uso. e Os trs tipos mais comuns de relacionamento entre casos de uso so: e a inclui-se que especica que um Caso de Uso toma lugar dentro de outro Caso de Uso
estende que especica que em determinadas situaes, ou em algum ponto co (chamado um ponto de extenso) um caso de uso ser estendido por outro. a a Generalizao especica que um caso de uso herda as caracter ca sticas do super caso de uso, e pode sobrepor algumas delas ou adicionar novas de maneira semelhante a herana entre classes. c
12.1.1
Ator
Um ator uma entidade externa (fora do sistema) que interage com o sistema e participando (e freqentemente iniciando) um caso de uso. Atores podem ser u pessoas reais (por exemplo usurios do sistema), outro sistema de computador a ou eventos externos. 136
Atores no representam as pessoa f a sica ou sistemas, mas sua regra. Isto signica que quando uma pessoa interage com o sistema de diferentes maneiras (assumindo diferentes regras) ela ser representada por diversos atores. Por exa 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
Descrio do caso de uso ca
Descrio do caso de uso so narrativas de texto do caso de uso. Elas usualmente ca a tomam a forma de uma nota ou um documento que de alguma maneira ligado e ao caso de uso, e explana o processo ou atividades que tomaro lugar no caso a 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 so chamados diagramas estticos a a porque mostram as classes, com seus mtodos e atributos bem como os relae cionamentos estticos entre elas: quais classes conhecem quais classes ou quais a classes so parte de outras classes, mas no mostram a troca de mensagens entre a a elas. Na UML, atributos so mostrados com pelo menos seu nome, e podem a tambm mostrar seu tipo, valor inicial e outras propriedades. Atributos poe dem tambm ser exibidos com sua visibilidade: e
137
Figura 12.2: Exemplo de um diagrama de classe + indica atributos pblicos. u # indica atributos protegidos. indica atributos privados As operaes tambm so exibidas com pelo menos seu nome, e podem co e a tambm mostrar seus parmetros e valores de retorno. e a Classes podem ter modelos, um valor que usado para uma classe ou tipo no e a especicado. O tipo de modelo especicado quando uma classe iniciada (isto e e um objeto criado). Modelos existem no C + + moderno e foram introduzidos e e no Java 1.5 onde eles so chamados de genricos. a e
12.2.1
Associaes de classe co
Classes podem relacionar-se (ser associada com) com outras de diferentes maneiras: Generalizao ca EM UML, uma generalizao entre duas classes coloca-as numa hierarquia repca resentando o conceito de herana de uma classe derivada de uma classe base. c Em UML, Generalizaes so representadas por uma linha conectando duas co a classes, com uma seta no lado da classe base. Associaes co So o mecanismo que permite objetos comunicarem-se entre si. Elas descrevem a a conexo entre diferentes classes (a conexo entre os objetos atuais chamada a a e 138
Figura 12.3: Exemplo de generalizao ca conexo do objeto, ou link. Associaes podem ter um regra que especica o a co propsito da associao e pode ser uni ou bidirecional (indicadando se os dois o ca objetos participantes do relacionamento podem mandar mensagens para o outro, ou se apenas um deles sabe sobre o outro). Cada ponta da associao tambm ca e possui uma valor de multiplicidade, que dita como muitos objetos neste lado da associao pode relacionar-se com o outro lado. ca Em UML, associaes so representadas como linhas conectando as classes co a participantes do relacionamento, e podem tambm mostrar a regra e a mule tiplicidade de cada um dos participantes. A multiplicidade exibida como e um intervalo [min . . . max] de valores no negativos, com um asterisco no lado a mximo representando innito. a
Figura 12.4: Exemplo de associao ca
Agregao ca Agregaes so um tipo especial de associao no qual as duas classes particico a ca pantes no possuem em n igual, mas fazem um relacionamento todo-parte. a vel Uma agregao descreve como a classe que possui a regra do todo, composta ca e (tem) de outras classes, que possuem a regra das partes. Para agregaes, a co classe que age como o todo sempre tem uma multiplicidade de um. Em UML, agregaes so representadas por uma associao que mostra co a ca um rombide no lado do todo. Representao visual de um relacionamento o ca Agregao em UML. ca
Figura 12.5: Exemplo de agregao ca
Composio ca Composies so associaes que representam agregaes muito fortes. Isto co a co co signica que composies formam relacionamentos todo-parte tambm, mas o co e relacionamento to forte que as partes no pode existir independentes. e a a Em UML, composies so representadas por um rombide slido no lado co a o o do todo.
139
Figura 12.6: Exemplo de composio ca
12.3
Diagramas de seqncia ue
Diagramas de seqncia mostram a troca de mensagens entre diversos objetos, ue numa situao espec ca ca e delimitada no tempo. Diagramas de seqncia coloue cam nfase especial na ordem e nos momentos nos quais mensagens para os e objetos so enviadas. a Em diagramas de seqncia, objetos so representados atravs de linhas ue a e verticais tracejadas, com o nome do objeto no topo. O eixo do tempo tambm e e vertical, aumentando para baixo, de modo que as mensagens so enviadas de um a objeto para outro na forma de setas com a operao e os nomes dos parmetros. ca a
Figura 12.7: Exemplo de diagrama de seqncia ue
Mensagens podem ser s ncronas, o tipo normal de mensagem de chamada em que o controle passado para o objeto chamado at o mtodo ter terminado e e e sua execuo, ou ass ca ncronas, em que o controle passado diretamente para o e objeto chamado. Mensagens s ncronas possuem uma caixa vertical no lado do objeto chamado para mostrar o controle do uxo do programa.
12.4
Diagramas de colaborao ca
Diagramas de colaborao mostram as interaes que ocorrem entre os objetos ca co participantes numa situao espec ca ca. A informao parecida com a mostrada ca e
140
pelos diagramas de seqncia, mas neste, a nfase colocada em como as inue e e teraes ocorrem no tempo, enquanto os diagramas de colaborao colocam os co ca relacionamentos entre os objetos e sua topologia em destaque. Em diagramas de colaborao, as mensagens enviadas de um objeto para ca outro so representadas por setas, mostrando o nome da mensagem, parmetros, a a e a seqncia da mensagem. Diagramas de colaborao so especialmente inue ca a dicados para mostrar um uxo ou situao espec ca ca do programa e podem, rapidamente, demonstrar ou explanar um processo na lgica do programa. o
Figura 12.8: Exemplo de diagrama de colaborao ca
12.5
Diagramas de estado
Diagramas de Estado mostram os diferentes estados de um objeto durante sua vida, e o est mulo que faz com que o objeto mude seu estado. Diagramas de estado vem objetos como mquinas de estado. e a Estados so os blocos constru a dos dos Diagramas de estado. Um estado pertence 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 mudana em um dos atributos de um objeto pode ser c representada por um estado, mas somente aquelas mudanas que podem afetar c signicativamente o trabalho do objeto. Existem dois tipos especiais de estados: inicial e nal. Eles so especiais a 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 nal, uma vez que ele j o tenha alcanado. a c
141
Figura 12.9: Exemplo de diagrama de estado
142
12.6
Diagramas de atividade
Uma atividade um passo simples num processo. Uma atividade um estado no e e sistema com atividade interna e, pelo menos, uma transio de sa ca da. Atividades podem tambm ter mais de uma transio de sa se elas possuem condies e ca da co diferentes. O diagrama de atividade descreve a seqncia de atividades num sistema ue com a ajuda das atividades. Diagramas de atividade so uma forma especial de a diagramas de estado, que somente (ou principalmente) contm atividades. e Diagramas de atividade so similares aos diagramas de uxo de procedia mentos, com a diferena de que todas as atividades so claramente anexas aos c a objetos. Diagramas de atividade so sempre associados a uma classe, uma operao a ca ou um caso de uso. Diagramas de atividade suportam atividades seqenciais bem como paraleu las. A execuo paralela representada pelos ca e cones Forquilha/Esperar, e para as atividades executadas em paralelo, no importante a ordem na qual elas se a e executam (elas podem ser executadas ao mesmo tempo ou uma aps a outra). o Atividades podem formar hierarquias, isto signica que uma atividade pode ser composta por diversas atividades em detalhe, na qual as transies de enco trada e sa devem corresponder `s transies de entrada e sa do diagrama da a co da de detalhe.
Figura 12.10: Exemplo de diagrama de atividade
143
12.7
Elementos auxiliares
Existem dois elementos em UML que no possuem nenhum valor real semntico a a para o modelo, mas auxiliam a elucidar partes do diagrama. Estes elementos so: a Linhas de texto. So uteis para adicionar informaes curtas de texto ao dia co agrama. So textos livres. a Notas. So uteis para adicionar informaes mais detalhadas sobre um objeto a co ou situao espec ca ca. Elas possuem a grande vantagem de poderem ser ancoradas a elementos UML para mostrar que a nota pertence a um objeto espec co ou situao. ca Caixas. So retngulos de forma livre que podem ser usados para agrupar itens, a a tornando os diagramas mais leg veis.
12.8
Diagramas de componente
Diagramas de componente mostram os componentes do software (sejam componentes de tecnologias como KParts, componentes CORBA ou Java Beans ou apenas sees do sistema que so claramente distintas) e os artefatos de que eles co a so feitos como arquivos de cdigo fonte, bibliotecas de programao ou tabelas a o ca de bancos de dados relacionais. Componentes podem possui interfaces (isto classes abstratas com operaes) e co que permitem associaes entre componentes. co
12.9
Diagramas de distribuio ca
Diagramas de distribuio mostram as instncias dos componentes de tempo ca a de execuo e suas associaes. Eles incluem ns que so recursos f ca co o a sicos, tipicamente um computador simples. Eles tambm mostram interfaces e objetos e (instncias da classe). a
144
Cap tulo 13
Gerncia de Congurao e e ca Mudanas c

A gesto da congurao do software uma atividade guarda-chuva e aplicada a ca e e ao longo de todo o processo de software. O gerenciamento de congurao e de ca solicitaes de mudana envolve os seguintes itens: co c Identicao dos itens de congurao; ca ca Restrio das mudanas nesses itens; ca c Auditoria das mudanas nesses itens; c Denio e o gerenciamento das conguraes desses itens. ca co Os mtodos e ferramentas utilizadas para o controle das mudanas conside c e erado com o Sistema de Gerenciamento de Mudanas de uma organizao. Ele c ca contem informaes chaves sobre os processos de desenvolvimento, promoo, e co ca implantao e manuteno de produtos da organizao e armazenam a base de ca ca ca ativos e de artefatos potencialmente reutilizveis resultantes da execuo desses a ca processos. Sendo assim, ele parte integrante dos processos gerais de desene volvimento. Sem o controle dos inmeros artefatos produzidos pelas muitas pessoas que u trabalham em um projeto, so criados artefatos conitantes, gerando um grande a desperd cio para a organizaao. Os principais problemas so a atualizao sic a ca multnea, a noticao limitada e a existncia de vrias verses. A seguir, cada a ca e a o uma delas descrita em detalhes. e Atualizao simultnea: ca a Quando dois ou mais membros da equipe trabalham separadamente no mesmo artefato, o ultimo membro a fazer mudanas desfaz o trabalho rec alizado pelo anterior. O problema bsico que se um sistema no permite a a e a atualizao simultnea, isso leva as mudanas em srie e diminui o ritmo do ca a c e processo de desenvolvimento. Entretanto, com a atualizao simultnea, ca a o desao e detectar se ocorreram atualizaes simultaneamente e resolver co 145
quaisquer problemas de integrao quando essas mudanas forem incorca c poradas. Noticao limitada: ca Quando um problema corrigido nos artefatos compartilhados por vrios e a desenvolvedores e alguns deles no so noticados da mudana. a a c Vrias verses: a o A maioria dos programas de grande porte desenvolvida em vrias verses e a o evolutivas. Uma verso pode estar sendo usada pelo cliente, enquanto a outra est em teste e uma terceira ainda est em desenvolvimento. Se a a forem encontrados problema em qualquer uma das verses, as correes o co devem ser propagadas entre elas. Isso pode levar a confuses que levam o a confuses dispendiosas. Um sistema de Gerencia de Congurao util o ca e para gerenciar as diversas variantes de sistemas de software em desenvolvimento pois controla as verses que so utilizadas em determinadas builds o a do software ao compilar builds de programas individuais ou de uma nova verso do software de acordo com a especicao denida pelo usurio e ao a ca a impor pol ticas de desenvolvimento do sistema. Os principais benef cios do gerenciamento da mudana so: c a Suporte a diversos mtodos de desenvolvimento; e Preservao da integridade do produto; ca Garantia da abrangncia e preciso do produto congurado; e a Ambiente estvel no qual o produto ser desenvolvido; a a Restrio das mudanas feitas nos artefatos com base nas pol ca c ticas do projeto; Trilha de auditoria indicando por que, quando e por quem um artefato foi alterado. Alm disso, ele armazena dados detalhados sobre as alteraes, tais como, e co quem criou uma verso especica, quais verses dos cdigo fonte foram a o o utilizadas em determinado build, alem de outras informaes relevantes. co
13.1
As Atividades
Na disciplina de Gerencia de Congurao as principais atividades so: ca a Congurar ambiente; Estabelecer pol ticas; Escrever plano; Criar unidade de implantao; ca Relatar status de congurao; ca Realizar auditorias de congurao; ca 146
Estabelecer processo de controle de mudanas; c Revisar solicitao de mudana; ca c Conrmar, duplicar ou recusar requisio de mudana; ca c Crias espaos de trabalho de integrao; c ca Criar baselines; Promover baselines ( de desenvolvimento para testes, de testes para homologao, etc.); ca Criar espao de trabalho de desenvolvimento; c Fazer mudanas; c Liderar mudanas; c Atualizar espao de trabalho; c Enviar solicitao de mudana; ca c Atualizar solicitao de mudana. ca c
13.2
Artefatos
Na disciplina de Gerencia de Congurao os principais artefatos so: ca a Repositrio do projeto; o Plano de gerenciamento da congurao; ca Unidade de implantao; ca Mtricas do projeto; e Registro da auditoria de congurao. ca
13.3
Papis e Responsabilidades e
Na disciplina de Gerencia de Congurao os principais papis e responsabilica e dades so: a Gerente de congurao ca Congurar ambiente; Estabelecer pol ticas; Escrever plano; Criar unidades de implantao; ca Relatar status de congurao; ca Realizar auditoria de congurao. ca
147
Gerente de controle de mudana c Estabelecer processo de controle de mudanas; c Revisar solicitao de mudana; ca c Conrmar, duplicar ou recusar solicitao de mudana. ca c Integrador Criar espaos de trabalho de integrao; c ca Criar baselines; Promover baselines. Outros papeis Criar espao de trabalho de desenvolvimento; c Fazer mudanas; c Liderar mudanas; c Atualizar espao de trabalho; c Enviar solicitao de mudana; ca c Atualizar solicitao de mudana. ca c
148
Cap tulo 14
CMM - Capability Maturity Model

CMM, do acrnimo em ingls de Capability Maturity Model, uma metodoloo e e gia de diagnstico e avaliao de maturidade do desenvolvimento de softwares o ca em uma organizao. ca Ele descreve os principais elementos de um processo de desenvolvimento de software. O CMM descreve os estgios de maturidade atravs dos quais orgaa e nizaes passam enquanto evoluem o seu ciclo de desenvolvimento de software, co atravs de avaliao cont e ca nua, identicao de problemas e aes corretivas denca co tro de uma estratgia de melhoria dos processos. Este caminho de melhoria e e denido por cinco n veis de maturidade: 1. Inicial 2. Repetitivo 3. Denido 4. Gerenciado 5. Em Otimizao ca O CMM fornece `s organizaes orientao sobre como ganhar controle do a co ca processo de desenvolvimento de software e como evoluir para uma cultura de excelncia na gesto de software. O objetivo principal nas transies desses e a co n veis de maturidade a realizao de um processo controlado e mensurado e ca como a fundao para melhoria cont ca nua. Cada n de maturidade possui um vel conjunto de prticas de software e gesto espec a a cas, denominadas reas-chave a do processo (KPA). Estas devem ser implantadas para a organizao atingir o ca n de maturidade em questo. vel a O CMM identica os n veis atravs dos quais uma organizao deve evoluir e ca para estabelecer uma cultura de excelncia na engenharia de software. Como e cada n vel de maturidade do CMM forma a base necessria sobre a qual o a prximo n ser constru o vel a do, normalmente tentar pular n veis improdutivo, e 149
porque no haver estabilidade na melhoria do processo, justamente pela falta a a da base que a sustentaria.
Figura 14.1: Modelo CMM
14.1
14.1.1
Os n veis de maturidade no CMM

N vel 1 - Inicial
No n 1 de maturidade os processos so geralmente ad hoc e a organizao vel a ca geralmente no dispe de um ambiente estvel. O sucesso nestas organizaes a o a co depende da competncia e hero e smo dos funcionrios e no no uso de processos a a estruturados. Devido ao imediatismo, um ambiente catico, o n o vel 1 de maturidade raramente produz um produto ou servio que funcione; assim, freqenc u temente eles excedem o oramento e o prazo em seus projetos. c
14.1.2
N vel 2 - Repetitivo
No n 2 de maturidade, o desenvolvimento do software repetido. O processo vel e pode no se repetir para todos os projetos da organizao. A organizao pode a ca ca usar ferramentas de Gerncia de Projetos para mapear os custos e o prazo do e projeto. A adoo de um processo de desenvolvimento ajuda a garantir que prticas ca a existentes so utilizadas em momentos de stress. Quando estas prticas so adoa a a tadas, os projetos decorrem e so gerenciados de acordo com o planejamento a inicial. O status do projeto e os servios entregues so vis c a veis ao gerenciamento (por exemplo: poss e vel a visualizao de marcos do projeto e o trmino da ca e maioria das tarefas). Tcnicas de gerenciamento de projetos so estabelecidas para mapear custos, e a prazos, e funcionalidades. Um m nimo de disciplina nos processos estabelecido e para que se possa repetir sucessos anteriores em projetos com escopo e aplicao ca similar. Ainda h um risco signicante de exceder os custos e estimativas de a prazo de desenvolvimento.
150
As reas chaves de processo desse n de maturidade so: a vel a Gerncia de Requisitos (RM); e Planejamento de Projeto de Software (SPP); Acompanhamento e Superviso de Projeto de Software (SPTO); a Gerncia de Subcontratato de Software (SSM); e Garantia da Qualidade de Software (SQA); Gerncia da Conguraao de Software (SCM). e c
14.1.3
N vel 3 - Denido
A organizao possui um conjunto de processos padres, os quais so a base ca o a do n vel 3. Estes esto estabelecidos e so melhorados periodicamente. Estes a a processos padres so usados para estabelecer uma consistncia dentro da orgao a e nizao. Projetos estabelecem seus processos denidos pelo conjunto de padres ca o processuais da organizao. ca O gerenciamento da organizao estabelece os objetivos dos processos baseado ca no conjunto de padres pr-denidos e garante que estes objetivos sejam encamo e inhados de forma apropriada. Uma cr tica distino entre os n ca veis 2 e 3 o escopo dos padres, descrio e o ca dos processos e procedimentos. No n vel 2, os padres, descries de proceso co sos e procedimentos podem ser bem diferentes em cada instncia espec a ca do processo (por exemplo, em um projeto particular). No n 3, os padres, devel o scries de processo e procedimentos para o projeto so guiados pelo conjunto co a padro de processos da organizao. a ca As reas chaves de processo desse n de maturidade so: a vel a Foco no Processo da Organizao (OPF); ca Denio do Processo da Organizao (OPD); ca ca Programa de Treinamento (TP);
Gerncia Integrada de Software (ISM); e Engenharia de Produto de Software (SPE); Coordenao entre Grupos (IC); ca Revises Tcnicas Formais (PR). o e
151
14.1.4
N vel 4 - Gerenciado
Utilizando mtricas precisas, o gerenciamento pode efetivamente controlar os ese foros para desenvolvimento de software. Em particular, o gerenciamento pode c identicar caminhos para ajustar e adaptar o processo para projetos particulares sem perda de mtricas de qualidade ou desvios das especicaes. e co Organizaes neste n co vel conseguem metas qualitativas para o processo de desenvolvimento de software e de manuteno. ca Subprocessos so selecionados conforme a importncia na performance total a a do processo. Esses subprocessos selecionados so controlados usando tcnicas a e estat sticas e qualitativas. Uma cr tica distino entre o n de maturidade 3 e 4 a previsibilidade ca vel e do desempenho do processo. No n 4, o desempenho do processo controlado vel e usando tcnicas estat e sticas e qualitativas, e previs qualitativamente. No e vel n 3, os processos so somente previs vel a veis qualitativamente. As reas chaves de processo desse n de maturidade so: a vel a Gerncia Quantitativa do Processo (QPM); e Gerncia de Qualidade de Software (SQM). e
14.1.5
N vel 5 - Otimizado
O n de maturidade 5 foca no cont vel nuo aumento do desempenho dos processos atravs de melhoras de inovao tecnolgica e incremental. Objetivos de e ca o melhoria quantitativa dos processos para a organizao so estabelecidos, conca a tinuamente revisados, reetindo os objetivos da organizao, e usando critrios ca e de gerncia de processos. e Os efeitos da melhora da reviso dos processos so medidas e acompana a hadas utilizando-se de processos de melhoria de qualidade. Ambos, os processo denidos e o conjunto de processos padres da organizao so alvos de melhoria o ca a de mtricas. e As reas chaves de processo desse n de maturidade so: a vel a
Preveno de Defeitos (DP); ca Gerncia da Mudana Tecnolgica (TCM); e c o Gerncia da Mudana do Processo (PCM). e c
14.2
Um pouco mais sobre KPAs
As reas-chave de processo do N 2 esto focadas nas questes do projeto de a vel a o software relacionadas ao estabelecimento de controles bsicos de gerenciamento a do projeto, e tm os seguintes objetivos: e 152
Gerncia de Requisitos ` Estabelecer um entendimento comum entre o e a cliente e os requisitos (desejos, necessidades) do cliente que sero atendidos a pela soluo a ser desenvolvida; ca Planejamento de Projeto de Software ` Estabelecer planos coerentes para a realizar a engenharia de software e o gerenciamento do projeto; Acompanhamento e Superviso de Projeto de Software ` Estabelecer uma a a adequada visibilidade do andamento (progresso) do software, de forma que o gerenciamento possa tomar aes corretivas se o planejamento original co no estiver sendo seguido; a Gerncia de Subcontratato de Software ` Selecionar fornecedores qualie a cados e gerenci-los de forma eciente; a Garantia da Qualidade de Software ` Fornecer ao gerenciamento visibilia dade do processo em uso e dos produtos em construo; ca Gerncia da Conguraao de Software ` Estabelecer e manter a integridade e c a dos produtos durante todo o ciclo de vida do software. As reas-chave do N 3 esto focadas tanto nas questes do projeto, quanto a vel a o da organizao, conforme a organizao estabelece uma infra-estrutura que efeca ca tivamente institucionaliza os processos de engenharia de software e de gerenciamento de todos os projetos. As reas-chave do N a vel 4 esto focadas no estabelecimento quantitativo a tanto do processo de software, quanto dos produtos em construo. ca As reas-chave do N 5 cobrem questes que tanto a organizao, quanto a vel o ca os projetos devem considerar para implementar melhorias no processo de software que sejam cont nuas e mensurveis. a
Figura 14.2: Areas-chave de processo no modelo CMM
14.3
Efeitos da evoluo do n ca vel de maturidade
A evoluo no n de maturidade causa efeitos nas pessoas, nas tecnologias e ca vel nas prticas de medidas. A seguir so apresentados esses efeitos em cada n a a vel 153
de maturidade. Pessoas N 1: Sucesso depende de indiv vel duos e heris. Regime constante o de emergncia (apagar incndio). Relacionamento entre grupos e e e descoordenado e muitas vezes conitante; N 2: Sucesso ainda depende de indiv vel duos, mas passam a contar com apoio gerencial. Os compromissos so compreendidos e gerencia ados. Existe treinamento para algumas funes; co N vel 3: Grupos de projeto trabalham de maneira coordenada. O treinamento planejado de acordo com as necessidades de cada papel e e aplicado convenientemente; N 4: Existe um forte sentido de trabalho em equipe; vel N 5: Todos esto engajados em atividades de melhoria cont vel a nua. Tecnologia N 1: A introduo de novas tecnologias arriscada; vel ca e N vel 2: Atividades bem denidas facilitam a introduo de novas ca tecnologias; N 3: Novas tecnologias so avaliadas qualitativamente; vel a N 4: Novas tecnologias so avaliadas quantitativamente; vel a N vel 5: Novas tecnologias so planejadas e introduzidas com total a controle. Medidas N 1: Coleta de dados feita de maneira ad hoc; vel e N 2: Coleta de dados de atividades de planejamento e acompanvel hamento feita de maneira sistemtica; e a N 3: Todos os processos denidos tm coleta sistemtica de dados, vel e a os quais so compartilhados por todos os projetos da organizao; a ca N vel 4: A denio e coleta de dados so padronizadas na orgaca a nizao e os dados so usados para entender os processos de maneira ca a quantitativa e estabiliz-los; a N vel 5: Os dados coletados so usados para avaliar e selecionar a possibilidades de melhoria de processos.
154
Parte IV
Linguagem de Programao ca Java
155
Cap tulo 15
Conceitos Bsicos de Java a

15.1 Pacotes
Em projetos pequenos comum colocar todos os arquivos java em um unico e diretrio. Essa uma abordagem rpida, simples. No entanto, se o pequeno o e a projeto comear a crescer, o nmero de arquivos aumentar e administr-los em c u a a um unico diretrio pode se tornar um problema. o Pacotes no so nada mais que uma forma de organiza os arquivos que intea a gram o projeto em diferentes diretrios de acordo com suas funcionalidades ou o categoria a qual eles pertenam. c Por exemplo, os arquivos no pacote java.io so todos relacionados com funa cionalidades de I/O, enquanto os arquivos do pacote java.net fornecem funcionalidades para tratar de redes. Em aplicaes com interface grca, por co a exemplo, muito comum encontrar um diretrio chamado ui (user interface). e o Alm de melhorar a organizao dos arquivos que compe o projeto, a utie ca o lizao de pacotes ajuda a evitar coliso de nomes entre classes. Por exemplo: ca a Se um programador denir uma classe chamada Vector, esse nome iria colidir com a classe Vector da JDK. No entanto, isso no ocorre por que a JDK usa a java.util como um nome de pacote para a classe Vector. Dessa forma, a classe implementada pelo programador pode se chamar Vector. A gura 15.1 mostra uma estrutura de diretrios criada pela utilizao de pacotes. o ca
156
Para indicar que uma classe pertence a um determinado pacote basta inciar o arquivo java como mostrado no exemplo a seguir. //Somente cdigo pode vir antes dessa linha o package world; public class HelloWorld { public static void main(String[] args) { System.out.println("Hello World"); } }
15.2
Modicadores de Acesso
Os modicadores de acesso so keywords adicionadas ao cdigo para determinar a o se atributos, mtodos ou classes poderam ser acessados a partir de outras classes. e Os modicadores de acesso presentes na linguagem Java so: public, private, a protected e package-private (impl cito quando no usado nenhum modicador a e na declarao da classe, atributo ou mtodo). ca e Uma classe pblica pode ser acessada por qualquer outra classe. Caso seja u declarada sem o modicador public, a classe ser package-private, ou seja, s a o poder ser acessada por classes do mesmo pacote. a Os mtodos e atributos aceitam outros modicadores alm do public. O e e modicador private d acesso somente dentro da classe, enquanto o modicador a protected permite acesso dentro do pacote e `s subclasses. a Assim como nas classes, caso nenhum modicador seja declarado, ca impl cito o modicador package-private. A tabela 15.1 abaixo resumo as permies de acesso impostas por cada um co dos modicadores: Modicador public private protected nenhum Pacote sim no a sim sim Subclasse sim no a sim no a Todos sim no a no a no a
Tabela 15.1: Modicadores de Acesso
15.3
Variveis a
Na linguagem de programao Java so denidos os seguintes tipos de variveis: ca a a Variveis de Instncia (Atributos no estticos): Um objeto armazena seu a a a a estado individual em atributos no estticos, ou seja, declarados sem o a a 157
modicador static. Atributos no estticos so conhecidos com variveis a a a a de instncia por que seus valores so unicos para cada instncia de uma a a a classe; Variveis de Classe (Atributos estticas): Uma varivel de classe todo a a a e atributo declarado com o modicador static. Isso indica ao compilador que existe apenas uma cpia da varivel, no importando o nmero de o a a u vezes que essa classe foi instanciada. Portanto, quando o valor de uma varivel de classe alterada em um dos objetos, o novo valor se torna a e vis para todos os outros objetos da mesma classe. Para impedir que vel uma varivel de classe tenha seu valor alterado ela deve ser declarada com a o mocador nal. Variveis Locais: As variveis locais so utilizadas para armazenar o esa a a tado temporrio dos mtodos. A sintaxe de declarao de uma varivel a e ca a local similar a de declarao de uma varivel de instncia. O que detere ca a a mina se uma varivel local a parte do cdigo em que ela declarada a e e o e - entre as chaves que determinam o in cio e o m de um mtodo. Uma e varivel vis a e vel apenas para o mtodo no qual foi declarada; no pode e a ser acessada do resto da classe. public class Bicicleta { // Varivel de Inst^ncia a a public int velocidade = 0; // Varivel de Classe a public static int qtdRodas = 2; // Varivel de Classe com valor constante a public static final String marca = "Caloi"; public void aumentaVelocidade (int incremento){ // Varivel Local a int novaVelocidade; = velocidade + incremento; velocidade = novaVelocidade; } }
15.4
Operadores
A lista abaixo sumariza os operadores suportados pela linguagem Java: Operador de Atribuio Simples ca = Operador de Atribuio Simples ca
158
Operadores aritmticos e + / % Adio (Tambm utilizado para concatenao de Strings) ca e ca Subtrao ca Multiplicao ca Diviso a Resto da Diviso a
Operadores Unrios a + ++ ! Operador Operador Operador Operador Operador unrio mais a unrio menos; Inverte o sinal de uma varivel a a de Incremento; Incrementa um valor de 1 de Decremento; Decrementa o valor de 1 Lgico de complemento; Inverte o valor de um boolean o
Operadores de Comparao ca == != > >= < <= instanceof Igual Diferente Maior Maior ou Igual Menor Menor ou Igual Compara um objeto a um tipo espec co
Operadores Condicionais && || ?: AND Condicional OR Condicional Ternrio (Forma curta para if-then-else) a
Operadores Bit a Bit e de Deslocamento (Shift)
<< >> >>> & |
Complemento bit a bit unrio a 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
Expresses, Sentenas e Blocos o c
Uma expresso uma construo feita de variveis, operadores e chamadas de a e ca a mtodos, descrita de acordo com a sintaxe da linguagem. A seguir, exemplos e de expresses: o //Declara~o e inicializa~o de uma vrivel do tipo int ca ca a a int cadence = 0; //Atribui~o de valor a uma posi~o de um vetor de int ca ca anArray[0] = 100; //Imprimindo um valor na tela System.out.println("Element 1 at index 0: " + anArray[0]); //Atribui~o de valor baseado no resultado de uma opera~o de adi~o ca ca ca result = 1 + 2; //Utiliza~o de par^ntesis para explicitar ordem de execu~o das opera~es ca e ca co zaz = x / (y+10); Em java uma sentena (statements) denida como uma unidade completa c e de execuo. Os seguintes tipos de expresses podem se tornar sentenas quando ca o c terminadas com um ponto e v rgula: (i) Expresses de Atribuio; (ii) Exo ca presses com ++ ou ; (iii) Chamada de mtodos e (iv) Expresses de Criao o e o ca de objetos. // Statement de atribui~o ca aValue = 8933.234; // Statement de incremento aValue++; // Statement de chamada de mtodo e System.out.println("Hello World!"); // Statement de cria~o de objeto ca Bicycle myBike = new Bicycle(); Essas so as chamadas statements de expresso. Existem ainda as statea a ments de declarao de varivel e de controle de uxo. ca a Um bloco um grupo de zero ou mais statements entre um par de chaves. e O exemplo a seguir ilustra o uso de blocos em Java:
class BlockDemo { public static void main(String[] args) { 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 cdigo geralmente so executadas na medida na ordem em o a aparecem. No entanto, os comandos de controle de uxo podem ser utilizadas ara interromper o uxo de execuo empregando decises, looping e desvios, ca o permitindo que ao programa executar condicionalmente blocos de cdigo paro ticulares. Os principais comandos de controle de uxo da linguagem Java so a 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 { public static void main(String[] args) { int testscore = 76; char grade; if (testscore >= 90) { grade = A; } else if (testscore >= 80) { grade = B; } else if (testscore >= 70) { grade = C; } else if (testscore >= 60) { grade = D; } else { grade = F; } //O resultado ser C pois, uma vez que a condi~o atendida, a ca e //o restante do cdigo If-Then-Else n~o mais avaliado o a e System.out.println("Grade = " + grade); 161
} } Switch class SwitchDemo { public static void main(String[] args) { 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 ser 29 a 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~o do bloco de cdigo ca o 162
//Pode acontecer do codigo n~o ser executado nenhuma vez a while (count < 11) { System.out.println("Count is: " + count); count++; } } } //Exemplo Do-While class DoWhileDemo { public static void main(String[] args){ int count = 1; do { System.out.println("Count is: " + count); count++; //Teste ao fim da execu~o do bloco de cdigo ca o //Cdigo executado ao menos uma vez o e } while (count <= 11); } } For //Exemplo 1 class ForDemo { public static void main(String[] args){ for(int i=1; i<11; i++){ System.out.println("Count is: " + i); } } } //Exemplo 2 for ( ; ; ) { //infinite loop // cdigo o } //Exemplo 3 class EnhancedForDemo { public static void main(String[] args){ 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
public static void main(String[] args) { 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 { public static void main(String[] args) { int[][] arrayOfInts = {{32,87,3,589}, {12,1076,2000,8}, {622,127,77,955}}; int searchfor = 12; int i; int j = 0; boolean foundIt = false; 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 { public static void main(String[] args) { 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 prximo loop sem executar o //o restante do cdigo do bloco for o continue; } //process ps numPs++; } System.out.println("Found " + numPs + " ps in the string."); } }
//Exemplo 2 class ContinueWithLabelDemo { public static void main(String[] args) { String searchMe = "Look for a substring in me"; String substring = "sub"; boolean foundIt = false; 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~o do loop while e vai ca //para proxima itera~o do loop for, ca //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 denir classes dentro de outra classe, como se fossem atributos ou mtodos. Algumas das vantagens de se utilizar esse e recurso do Java so: a 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 deniu e vice-versa. Na verdade, o recurso de classes internas surgiu no Java 1.1 com esse propsito. o Como so denidas dentro de outras classes, o cdigo fonte ca no mesmo a o arquivo .java. Ao compilar, gera-se vrios arquivos .class, compondo o nome da a classe externa e interna. Exemplo: Externa.java contm a classe Externa, que e dene uma classe interna chamada Interna. Ao compilar, gera-se Externa.class e Externa$Interna.class. E importante ressaltar que a classe interna no pode a ter o mesmo nome da classe externa que a dene. No Java existem os seguintes tipos de classes internas: Classes Aninhadas Classes Instanciadas Classes Membro Classes Locais Classes Annimas o
As classes aninhadas so os tipos mais simples de classes internas. Uma a classe denida dentro da outra como se fosse um membro static. Elas permitem e denir acesso privado ou protegido e agrupa classes logicamente relacionadas. So referenciadas via Externa.Interna, como se fosse um atributo esttico. A a a seguir um exemplo de classe aninhada e de como referenci-la: a //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~o de acesso ca protected static class Valor { private int valor; public Valor(int valor) { this.valor = valor; } } } public class Teste { public static void main(String[] args) { 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 so aqueles que possuem um conjunto nitos de valores que a as variveis podem assumir. Por exemplo: estaes do ano, naipes ou cartas do a co baralho, planetas do sistema solar etc. Originalmente, a forma padro utilizada a para representar tipos enumerados era o chamado int Enum Pattern (tipos enumerados baseados em inteiros). // int public public public public Enum Pattern static final static final static final static final
int int int int
SEASON_WINTER SEASON_SPRING SEASON_SUMMER SEASON_FALL
= = = =
0; 1; 2; 3;
167
Esse tipo de padronizao apresentava os seguintes problemas: ca No seguro quanto ao tipo: Como uma season representada por um a e int, pode-se passar qualquer valor inteiro (inclusive diferente de 0,1,2,3) quando uma season for requerida; Sem namespace: E necessrio criar um padro de nomenclatura para evia a tar coliso com outros tipos enumerados. (Exemplo: SEASON ). a Valores imprimidos no so explicativos: Como os valores so int, quando a a a impressos no apresentam a informao que representam diretamente. a ca 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 cdigo abaixo mostra o uso do novo padro para tipos o a enumerados: public class Weather { //Define tipo enumerado Refrigerante public enum Season = {winter, spring, summer, fall}; private printSeasons() { //Loop recuperando cada um dos valores possveis de Season for (Season s : Season.values()){ System.out.println(s); } } }
15.9
Anotaes co
Anotaes (annotations) provem dados sobre o programa mas no so parte do co e a a do programa propriamente dito. Elas no possuem efeito direto na operaes do a co cdigo com o qual esto relacionadas. Esse recurso da linguagem Java permite o a que o programador no se preocupe em escrever cdigo auxiliar (arquivos de a o congurao, por exemplo). A idia que o programador diga o que tem que ca e e ser feito utilizando as anotaes e ferramentas auxiliares faam o restante do co c trabalho. Alguns exemplos do uso de anotaes so: co a Informaes para o compilador: Anotaes podem ser utilizadas pelo comco co pilador para detectar erros ou sumprimir mensagens de warning; Processamento em tempo de Compilao ou Deploy: Ferramentas auxca iliares podem processar as anotaes para gerar cdigo, arquivos XML co o etc; Processamento em tempo de Execuo: Algumas anotaes podem ser ca co processsadas em tempo de execuo; ca
168
Documentao: Anotaoes podem ser utilizadas para substituir comentrios ca c a no cdigo. o Os trs pr-dendos de anotaes utilizadas pelo compilador so: e e co a @Deprecated: Indica que o elemento marcado est deprecated e no deve a a ser mais utilizado. O compilador gera um warning sempre que um programa utilizar um uma classe, um mtodo ou um atributo marcado como e @Deprecated; @Override: Informa ao compilador que o elemento marcado deve sobrescrever o elemento de mesmo nome declarado na superclasse. Embora a anotao no seja obrigatrio para sobrescrever um mtodo, utiliz-la ca a o e a ajuda a prevenir erros; @SuppressWarnings: Indica ao compilador situaes em que os warnings co devem ser suprimidos; A seguir alguns exemplos de utilizao das anotaes descritas. ca co //Marca o mtodo como deprecated e @Deprecated static void deprecatedMethod() { //cdigo } o //Indica que o mtodo ir sobrescrever o mtodo da superclasse e a e @Override int overriddenMethod() { //cdigo } o //Indica ao compilador para suprimir warning gerados pelo uso //de mtodos deprecated e @SuppressWarnings("deprecation") void useDeprecatedMethod() { //O uso de um mtodo deprecated geraria um warning e objectOne.deprecatedMethod(); }
15.10
Genricos e
Os genricos so um recurso introduzido a partir Java 5 e permite ao prograe a mador escrever cdigo abstraindo tipos de dados. Os genricos so tipicamente o e a utilizados em conjunto com interfaces ex: List) que herdam da interface Collection ou de classes que a implementam (ex: AbstractList, ArrayList, LinkedList, Vector) Quando um elemento retirado de uma Collection necessrio realizar um e e a cast para o tipo do elemento armazenado na Collection. Alm de incoveniente, e isso inseguro. O compilador no checa se o cast realizado do mesmo tipo do e a e armazenado na coleo. Dessa forma, o cast pode falhar em tempo de execuo. ca ca
169
//Cria~o de uma collection do tipo LinkedList ca List myIntList = new LinkedList(); //Adi~o de um elemento do tipo Integer a collection ca myIntList.add(new Integer(0)); //Recuperando um elemento da collection. Cast para Integer necessrio e a Integer x = (Integer) myIntList.iterator().next(); Os genricos provem uma forma de comunicar ao compilador o tipo are e mazenado na coleo, permitindo que a checagem seja feita em tempo de comca pilao. Alm de evitar erros em tempo de execuo, a utilizao de genricos ca e ca ca e elimina a necessidade de casts. //Cria~o de uma collection LinkedList para armazenar objetos do tipo Integer ca List<Integer> myIntList = new LinkedList<Integer>(); //Adi~o de um elemento do tipo Integer a collection ca myIntList.add(new Integer(0)); ////Recuperando um elemento da collection. Cast n~o necessrio a e a Integer x = myIntList.iterator().next(); Os tipos genricos tm como grande vantagem o aproveitamento de cdigo. e e o A interface Collection um exemplo disso. As operaes de adicionar ou ree co mover um novo elemento, determinar o tamanho, vericar se a collection est a vazia ou recuperar o ndice de um determinado elemento, por exemplo, certamente so aplicveis a collections do tipo Integer, String ou de outra classe a a qualquer. Exemplos de interfaces genricas so List e Iterator. A seguir, alguns e a trechos dessas duas interfaces como denidas no pacote java.util. public interface Iterator<E> { E next(); boolean hasNext(); //mais cdigo ... o } public interface List<E> { void add(E x); Iterator<E> iterator(); //mais cdigo ... o } Genricos permitem implementaes mais sosticadas como: e co //Wildcards ou Coringas //Mtodo com par^metro Casulo. Aceita Casulo de qualquer tipo e a void imprimir (Casulo<?> c) { // cdigo do mtodo ... o e } //Limitando o tipo genrico aceito pelo mtodo e e //Mtodo s aceita Casulo de Forma ou Casulos de subclasses de Forma e o 170
void desenhar (Casulo<? extends Forma> c){ // cdigo do mtodo ... o e }
15.11
Reexo a
A Reection permite um programa Java examinar ou fazer a introspeco nele ca mesmo, ou seja, olhar e examinar suas propriedades e estrutura. Com isso, voc e pode, por exemplo obter o nome de todos os membros de uma classe, como atributos e mtodos, bem como executar um mtodo usando a Introspection. e e Esse recurso utilizado, por exemplo, pelos ambientes de desenvolvimento (as e IDEs) para examinar e exibir a estrutura e contedo das classes e beans. A u 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 mtodos da classe e Method methlist[] = cls.getDeclaredMethods(); //Imprime informa~es (mtodos, modificadores, exce~es) co e co //sobre cada um dos mtodos da classe e 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^metros do mtodo a e Class pvec[] = m.getParameterTypes(); for (int j = 0; j < pvec.length; j++) System.out.println("par^metro #" + j + " " + pvec[j]); a //Recupera a lista de excess~es do mtodo o e Class evec[] = m.getExceptionTypes(); for (int j = 0; j < evec.length; j++)
171
System.out.println("exce~o #" + j + " " + evec[j]); ca //Recupera o tipo de retorno do mtodo e System.out.println("tipo de retorno = " + m.getReturnType()); } } catch (Throwable e) { System.err.println(e); } } } //Sada da execu~o da classe Classe1: ca //Lista de mtodos da Classe1 com todas as suas propriedades e ------------------------------------nome = funcao1 ------------------------------------membro de:class Classe1 modificador:private par^metro #0 class java.lang.Object a par^metro #1 int a exce~o #0 class java.lang.NullPointerException ca tipo de retorno = int ------------------------------------nome = main ------------------------------------membro de:class Classe1 modificador:public static par^metro #0 class [Ljava.lang.String; a tipo de retorno = void
172
Cap tulo 16
Classes Essenciais
16.1 Exception e Controle de Excees co
Uma exceo um evento que ocorre durante a execuo de um programa inca e ca terrompendo seu uxo normal de execuo. ca Quando um erro ocorre dentro de um mtodo, o mtodo cria um objeto e e chamado exception e o entrega ao controle de execuo (runtime system), que ca contm informaes sobre o erro, incluindo seu tipo e o estado do programa e co quando o erro ocorreu. O ato de criar um objeto exception e a entreg-lo ao a runtime system chamado lanamento de uma exceo (throwing an exception). e c ca O runtime system ento pesquisa na pilha de chamadas por um mtodo que a e contenha um bloco de cdigo capaz de tratar a exceo. Esse bloco de cdigo o ca o chamado tratador de excees (exception handler). A pesquisa comea no e co c mtodo onde o erro ocorreu e procede na pilha na ordem reversa em que os e mtodos foram chamados. Quando um tratador adequado encontrado, o rune e time syste o entrega a exceo. Um tratador considerado adequado quando o ca e tipo da exceo lanada coincide com o tipo denido no tratador (IOException, ca c ClassNotFoundException, etc.). Quando um tratador escolhido diz-se que ele capturou a exceo (catches e ca the exception). Se o runtime system pesquisa em toda a pilha de mtodos e e no encontrar um tratador adequado, o programa ser encerrado. A gura 16.1 a a mostra a ordem de pesquisa por um tratador para a exceo. ca
16.1.1
Excees t co picas
Em Java excees so objetos. A classe Exception a superclasse de todas as co a e excees. Exemplos t co picos de excees so: co a Indice de uma array fora do intervalo permitido (ArrayIndexOutOfBoundsException); Problemas em operaes aritmticas, como overows e divises por zero co e o (ArithmeticException); 173
Figura 16.1: Procura pelo tratador de excees co Argumentos invlidos numa chamada a um mtodo (IllegalArgumentExa e ception); Uso de uma referncia que no aponta para nenhum objeto (NullPointe a erException); Acesso a um arquivo inexistente (FileNotFoundException); Erros de banco de dados (SQLException); A classe Exception, por sua vez, subclasse de Throwable, o que permite e que as excees sejam lanadas. Se o programador desejar que a exceo assim co c ca lanada seja tratada fora do mtodo que a gerou, ele deve explicitar isto usando c e a palavra chave throws seguida do tipo de exceo, na declarao do mtodo. ca ca e //Exemplo 1: Mtodo indica que todas exce~es ser~o lanadas, ou seja, e co a c // n~o ser~o tratadas internamente. a a public void simpleMethod1 (String x) throws Exception { //... if (problema1) throw Exception; //... } //Exemplo 2: Mtodo indica que as exce~es do tipo excecao1 e o // e excecao2 nao ser~o tratadas internamente. a public void simpleMethod2 (int a, int b) throws excecao1, excecao2 { //... if (problema1) throw excecao1; if (problema2) throw excecao2; //... } Na verdade, existe uma classe de excees, a RuntimeException, que no co a precisam ser lanada explicitamente. RuntimeException uma superclasse das c e excees que podem ocorrer durante a operao normal da mquina virtual Java. co ca a 174
Uma vez que a exceo foi lanada, a execuo do mtodo interrompida e o ca c ca e e controle volta ao objeto que chamou este mtodo. Exemplos de classes que here dam de RuntimeException so ArithmeticException, BuerOverowException, a ClassCastException, IllegalArgumentException, IndexOutOfBoundsException, NullPointerException, SystemException, etc. A gura 16.2 mostra como as excees esto organizadas na hierarquia de co a classes da linguagem Java.
Figura 16.2: Exceptions e Errors Alm das excees t e co picas, a gura 16.2 mostra tambm a classe Error. Ere ror uma subclasse de Throwable que indica situaes excepcionais externas a e co aplicao, das quais a aplicao nem sempre capaz de se recuperar, por exemca ca e plo, um problema de hardware. Uma aplicao pode decidir por capturar um ca erro com objetivo de noticar o usurio sobre o problema, no entanto, quase a sempre faz mais sentido para o programa imprimir um stack trace e encerrar. A classe VirtualMachineError um exemplo de subclasse de Error, que ene globa problemas como falta de memria (OutOfMemoryError) e estouro de pilha o (StackOverowError).
16.1.2
Capturando Excees co
Para capturar uma exceo utilizada a seguinte estrutura de cdigo: ca e o
try { // Cdigo que pode gerar exce~es dos tipos o co // ExceptionType1 e ExceptionType2 }catch(ExceptionType1 opa1){ // Cdigo para lidar com uma exce~o do tipo o ca // ExceptionType1 }catch( ExceptionType2 opa2 ){ // Cdigo para lidar com uma exce~o do tipo o ca // ExceptionType2
175
}finally{ // Cdigo que deve ser executado em qualquer caso o } Quando ocorre uma exceo, os blocos catch so examinados sucessivamente ca a at que o argumento corresponda ao tipo da exceo. No exemplo acima, se e ca ExceptionType2 for uma subclasse de ExceptionType1, o segundo bloco catch nunca ser alcanado. Neste caso, deve-se inverter a ordem dos blocos catch. a c O bloco nally opcional, e normalmente usado para realizar aes que e e co independem da ocorrncia de uma exceo em um dado bloco de comandos. e ca Por exemplo, em um sistema que escreve informaes em um banco de dados, co necessrio fechar a conexo com este ultimo ao nal da operao de escrita, e a a ca independentemente da operao ter sido bem-sucedida ou no. Tendo isso em ca a vista, o comando responsvel por fechar a conexo deve car dentro de um bloco a a nally.
16.2
Threads e Concorrncia e
Em programao concorrente existem duas unidades bsicas de execuo: proca a ca cessos e threads. Em java, os recrsos para programao concorrente so mais ca a voltados para o uso de threads. Threads so comumente chamadas de processos leves. Processos e threads a provem um ambiente de execuo, mas criar uma thread requer menos recursos e ca que criar um processo. As threads existem dentro dos processos - cada processo possui pelo menos uma. As threads compartilham os recursos do processo, incluindo memria e arquivos abertos, favorecendo a ecincia da comunicao, o e ca porm a tornando potencialmente problemtica. e a Cada aplicao possui pelo menos uma thread - ou vrias, se considerarmos ca a a threads de sistema. Do ponto de vista do programador, uma aplicao comea ca c com apenas uma unica thread chamada main, e essa possui a habilidade para criar novas threads.
16.2.1
Denindo e Iniciando uma Thread
Existem duas formas bsicas de se denir uma thread em Java: implementar a a interface Runnable ou extender a classe Thread. O cdigo para cada um das o formas segue abaixo: //Implementando a interface Runnable public class HelloRunnable implements Runnable { public void run() { System.out.println("Hello from a thread!"); } 176
public static void main(String args[]) { (new Thread(new HelloRunnable())).start(); } } //Extendendo a classe Thread public class HelloThread extends Thread { public void run() { System.out.println("Hello from a thread!"); } public static void main(String args[]) { (new HelloThread()).start(); } } A primeira forma mais geral e ex e vel, porque objetos Runnable podem herdar de outras classes diferentes de Thread. No entanto, a segunda forma e mais simples e funciona bem para aplicaes que pouco complexas. co Em ambos os casos, a tarefa executada pela thread deve ser implementada no mtodo Thread.run e para inici-la deve ser utilizado o mtodo Thread.start. e a e
16.2.2
Pausando a execuo com sleep ca
Thread.sleep faz com que a thread corrente suspenda sua execuo por um ca per odo de tempo espec co. Essa uma forma de liberar o processador para outras threads ou processos que estejam rodando no sistema. O parmetro do a mtodo Thread.sleep o tempo em milissegundos. e e 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
Interrupes co
Uma interrupo indica que a thread deve parar o que est fazendo e comear ca a c a fazer outra coisa. E o programador quem deve denir como a thread deve responder a uma interrupo. O uso mais comum de interrupes nalizar a ca co e execuo de uma thread. ca 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 mtodo join usado para fazer com que uma thread aguarde at que outra e e e thread termine. Em geral, o join utilizado para a thread esperar pelo trmino e e da execuo de suas threads lhas. Imagine uma aplicao que dependa da ca ca execuo de trs tarefas independentes A, B e C. A aplicao s pode continuar ca e ca o quando cada uma das tarefas estiver sido completada. Portanto, a aplicao ca (thread principal) deve executar o mtodo join para cada uma das tarefas A,B e e C. O cdigo java para essa situao teria a seguinte estrutura: o ca public static void main(String args[]) { System.out.println("Thread main iniciada"); //Cdigo inicial da thread main o //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(); //Cdigo restante da thread main o 178
System.out.println("Thread main encerrada"); }
16.2.5
Sincronizao ca
As threads se comunicam entre si essencialmente por meio de compartilhamento no acesso de atributos e referncias a objetos. Essa uma forma de comunicao e e ca eciente, porm permite a ocorrncia de dois tipos de erros: interferncia entre e e e threads e erros de consistncia de memria. Para contornar esses problemas o e o Java oferece o recurso de sincronizao. ca O problema da interferncia ocorre quando duas operaes, rodando em e co threads diferentes, mas atuando sobre o mesmo dado, se intercalam.
//Interfer^ncia entre threads e //Tr^s threads que atuam sobre o mesmo dado e //N~o possvel garantir a ordem de execu~o das opera~es a e ca co //pois em princpio, as threads s~o iniciadas ao mesmo tempo. a int a = 0; thread_incrementa_a.start(); thread_decrementa_a.start(); thread_imprime_a.start(); Os erros de inconsistncia de memria ocorrem quando diferentes threads e o tm diferentes vises daquilo que deveria ser o mesmo dado. As causas dos e o erros de inconsistncia de memria so complexas e esto fora do escopo dessa e o a a seo. ca A chave para evitar esse tipo de erro est em entender o que o Java chama de a relacionamento happens-before. Esse relacionamento consiste em garantir que a memria escrita por uma statement espec o ca est vis para uma outra statea vel ment. Para criar esse tipo de relacionamento entre threads pode ser utilizado o mtodo Thread.join, como discutido anteriormente. A linguagem Java tambm e e prov outros dois idiomas para sincronizao que so: mtodos sincronizados e e ca a e statements sincronizadas. Com os mtodos sincronizados no poss e a e vel realizar duas chamadas simultneas do mtodo sobre um unico objeto. Quando uma thread est execua e a tando um mtodo sincronizado sobre um objeto, todas as outras threads que e invocam mtodos sincronizados para o mesmo objeto suspendem sua execuo e ca at que a primeira thread libere o objeto. Alm disso, os mtodos sincronizae e e dos estabelecem automaticamente uma relao de happens-before com todas as ca chamadas subsequentes de mtodos sincronizados. Isso garante que a as mue danas no estado do objeto estaro vis c a veis para todas as threads. public class SynchronizedCounter { 179
private int c = 0; //Mtodos sincronizados para manipular um contador e public synchronized void increment() {c++;} public synchronized void decrement() {c--;} public synchronized int value() {return c;} } Ao contrrio dos mtodos sincronizados, as statements sincronizadas devem a e espec car para qual objeto dever ser obtido o lock. Essa tcnica pode ser util a e quando implementar concorrncia com uma granularidade mais na. Uma e e exemplo de cdigo para criao de statements sincronizadas mostrado abaixo: o ca e public class MsLunch { private private private private long c1 = 0; long c2 = 0; Object lock1 = new Object(); 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 conexo direta entre a tarefa executada a por uma nova thread, como denida no objeto Runnable, e a nova thread em sim, denida por um objeto Thread. Isso funciona bem para aplicaes peco quenas. Em aplicaes de grande porte mais apropriado separar a criao e co e ca gerenciamento da threads do resto da aplicao. Os objetos que encapsulam as ca funes de gerenciamento de threads so chamados executores (executors). co a O pacote java.util.concurrency dene trs interfaces executoras que so Exe a ecutor, ExecutorService e ScheduledExecutorService. Essas interfaces denem mtodos para gerenciamento de threads na aplicao. Exemplo: Se r um e ca e objeto do tipo Runnable, e e um objeto do tipo Executor o trecho de cdigo e o (new Thread(r)).start(); poderia ser substitu por do e.execute(r); 180
Na primeira forma, uma nova thread seria criada para realizar a tarefa denida em r, enquanto na segunda, isso dependeria da implementao da inca terface executora. Geralmente, as interfaces executoras so criadas utilizando as chamadas a ThreadPools, que consistem de um conjunto de threads (worker threads) responsveis pela execuo das tarefas. Quando o mtodo execute chamado a ca e e sobre o objeto r, uma worker thread alocada para rodar a tarefa denida em e r. Caso no exista nenhuma worker thread dispon no momento, r colocada a vel e em uma la de espera at que uma worker thread seja liberada. e Usando pools de threads poss e vel minimizar o overhead de criao de ca threads e otimizar o gerenciamento de memria, uma vez que poss denir o o e vel nmero mximo de threads no pool de acordo com as necessidades da aplicao u a ca e quantidade de recursos do sistema.
16.3
16.3.1
Streams e Serializao ca
I/O Streams
Um I/O stream pode representar diferentes tipos de fonte e destino, incluindo arquivos em discos, dispositivos, outros programas e memria. Os streams suo portam diversos tipos de dados, como simples bytes, tipos de dados primitivos e at mesmo objetos complexos. Alguns streams simplesmente passam os dados, e enquanto outros realizam algum tipo de manipulao e transformao conforme ca ca necessrio. A seguir sero mostrados alguns exemplos da utilizao de streams. a a ca Streams de Bytes Byte streams so utilizados para realizar input e output de bytes. Todas a as classes byte stream herdam de InputStream e outputStream. Os streams de bytes representam o n vel mais baixo que pode ser alcanado, e devem evitac dos. Todas as outras classes de stream so constru a das com base na operaes co denidas 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 conveo ca Unicode. As operaes de com streams de caracteres automaticamente conco 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; import java.io.IOException; public class CopyCharacters { public static void main(String[] args) throws IOException { 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 um conjunto de caracteres terminada por um caracter especial de m de linha. e O cdigo a seguir executa a mesma tarefa do exemplo 1, porm copia o arquivo o e linha a linha e utiliza estratgias de buering. e //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 import import import
java.io.FileWriter; java.io.BufferedReader; java.io.PrintWriter; java.io.IOException;
public class CopyLines { public static void main(String[] args) throws IOException { 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 cdigo utiliza operae de I/O no buerizadas. Isso signica o co a que a cada requisio de leitura ou escrita expressa no cdigo prontamente ca o e 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 buerizados. Os input streams lem dados de uma rea de buer; a API ine a put nativa s chamada quando esse buer est vazio ou no contm os dados oe a a e procurados. Similarmente, os output streams escrevem dados para uma rea de a buer, enquanto a API nativa de output s chamada quando o buer de esoe crita est cheio ou quando algum comando que implique no ushing utilizado, a e por exemplo, println.
16.3.2
Serializao - Streams de Objetos ca
Os streams apresentados at agora so chamados data streams. Assim como e a os data streams suportam I/O de tipos primitivos de dados, os object streams suportam I/O para objetos. A maioria das classes padro do java suportam a a serializao de seus objetos. Para que uma objetos de uma classe possam ca ser serializados a classe deve implementar a interface Serializable. A interface Serializable no dene mtodos ou atributos, servindo apenas para indicar que a e uma classe serializvel. e a As classes de streams de objetos so ObjectInputStream e ObjectOutputa Stream. Essas classes implementam as interfaces ObjectInput e ObjectOutput, que por sua ve so subitnerfaces de DataInput and DataOutput. Isso signica a dizer que todos os mtodos para I/O de tipos de dados primitivos tambm so e e a 183
implementados nas classes de stream para objetos. A seguir, um exemplo simples para serializao de objetos em Java. ca 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 serializa~o ou desserializa~o ca ca System.out.println(e.getMessage()); }catch (ClassNotFoundException e) { //Pode ser gerado desserializa~o ca System.out.println(e.getMessage()); } } 184
} Embora as classes ObjectInputStream e ObjectOutputStream sejam sucientes para serializar e desserializar a maioria dos objetos no Java, ela possui o incoveniente de utilizar arquivos binrios, o que diculta a leitura direta por a um usurio ou por outras aplicaes (escritas em outras linguagens, por exema co plo). Muitas aplicaes realizo serializao com arquivos XML, o que permite co a ca contornar os problemas da legibilidade e integrao mais facilmente. ca Existem inmeros pacotes para serializao de objetos em arquivos XML. u ca Quando se est trabalhando com java beans, por exemplo, duas classes muito a utilizadas para serializao de objetos em XML so java.beans.XMLEncoder e ca a java.beans.XMLDecoder. A seguir, um trecho de cdigo exemplicando o uso o 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 Operaes de I/O co Classes para manipulao de propriedades ca
16.5
Boa parte das aplicaes necessitam de algum tipo de congurao adicional que co ca no pode ser embutida diretamente no cdigo. Em java, uma forma tradicional a o de se fazer isso envolve a utilizao ddos chamados arquivos de propriedades, ca que podem ser manipulados a partir da classe java.util.Properties, que uma e extenso da classe java.util.Hashtable. a Um arquivo de propriedades guarda conjunto de pares nome/valor, que podem ser lidos ou alterados. O formato t pico de um arquivo de propriedades e motrado a seguir:
185
#Esta uma linha de comentrio e a #Mon Jun 11 22:37:16 BRT 2007 app.diretorio=/zaz/traz/bin app.usuario=camatchones app.mododeoperacao=producao E a seguir mostrado um exemplo de cdigo Java para manipulao de um e o ca 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 um comentrio!"); e a out.close();
}catch(Exception e){ System.out.println(e.getMessage()); } } } Uma observao importante que o mtodo getProperty sempre retorna ca e e uma String, de modo que se uma propriedade de algum outro tipo, essa deve e ser convertida no momento da leitura. Atualmente o uso de arquivos XML para armazenamento de conguraes co
186
vem ganahando popularidade, no entanto, os arquivos de propriedades continuam ser uma forma simples e ecaz de gerenciar conguracoes simples.
187
Cap tulo 17
Colees co
Uma coleo simplesmente um grupo de objetos em uma unica unidade. As ca e colees so usadas para armazenar, recuperar, manipular e comunicar dados co a agregados. Tipicamente, representam itens de dados que do forma a um grupo a natural, tal como uma mo do poker (uma coleo dos cartes) e uma pasta de a ca o correspondncia (uma coleo das letras). e ca Uma framework de colees uma arquitetura unicada para representao e co e ca manipulao das colees, permitindo que elas sejam manipuladas independenca co temente dos detalhes de sua implementao. Todos os frameworks de colees ca co contm: e Interfaces: Estes so os tipos de dados abstratos que representam as a colees. As interfaces permitem que as colees sejam manipuladas indeco co pendentemente dos detalhes de sua representao. Em linguagem orienca tadas ` objeto as interfaces do forma geralmente a uma hierarquia; a a Implementaes: Estas so as implementaes concretas das relaes da co a co co coleo. Essencialmente, so estruturas de dados reusveis; ca a a Algoritmos: Estes so os mtodos que executam computaes uteis, tais a e co como procurar e ordenar objetos de uma determinada coleo. Os algoritca mos so polimrcos, isto , o mesmo mtodo pode ser usado em diferentes a o e e implementaes. co
As principais vantagens do framework de colees (collection framework) co so: a Reduo do esforo de programao, fornecendo estruturas de dados e ca c ca algoritmos uteis, para que no seja necessrio reescrev-los; a a e Aumento da performance: fornecendo implementaes de alta perforco mance. Como as vrias implementaes de cada interface so substitu a co a veis, os programas podem ser facilmente renados trocando-se as implementaes; co Interoperabilidade entre APIs no relacionadas, estabelecendo uma lina guagem comum para passagem de colees; co
188
Reduo do esforo de aprendizado de APIs, eliminando a necessidade de ca c se aprender vrias APIs de colees diferentes; a co Reduo do esforo de projetar e implementar APIs, eliminando a necesca c sidade de se criar APIs de colees prprias; co o Promover o reso de software, fornecendo uma interface padro para u a colees e algoritmos para manipul-los. co a As colees so necessrias, devido o uso dos arrays possuir uma srie de co a a e limitaes, como por exemplo: co Um array no pode ter o tamanho modicado depois de criado; a Somente pode conter elementos de um mesmo tipo; Para inserir ou retirar um elemento necessrio modicar a posio de e a ca outros elementos.
Figura 17.1: Interfaces Collection
17.1
Interface Collection
Interface base para todos os tipos de coleo. Ela dene as operaes mais ca co bsicas para colees de objetos, como adio (add) e remoo (remove) aba co ca ca stratos (sem informaes quanto ` ordenao dos elementos), esvaziamento co a ca (clear), tamanho (size), converso para array (toArray), objeto de iterao (ita ca erator), e vericaes de existncia (contains e isEmpty). A seguir mostada a co e e 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 Iterator<E> iterator(); // Bulk operations boolean containsAll(Collection<?> c); boolean addAll(Collection<? extends E> c); //optional 189
boolean removeAll(Collection<?> c); boolean retainAll(Collection<?> c); void clear(); // Array operations Object[] toArray(); <T> T[] toArray(T[] a); }
//optional //optional //optional
17.2
Interface Set
Interface que dene uma coleo, ou conjunto, que no contm objetos duplica a e cados. Isto , so ignoradas as adies caso o objeto ou um objeto equivalente e a co j exista na coleo. Por objetos equivalentes, entenda-se objetos que tenham a ca o mesmo cdigo hash (retornado pelo mtodo hashCode()) e que retornem vero e dadeiro na comparao feita pelo mtodo equals(). ca e No garantida a ordenao dos objetos, isto , a ordem de iterao dos a e ca e ca objetos no necessariamente tem qualquer relao com a ordem de insero dos a ca ca objetos. Por isso, no poss a e vel indexar os elementos por ndices numricos, e como em uma List. A seguir mostada a Interface Set: e public interface Set<E> extends Collection<E> { // Basic operations int size(); boolean isEmpty(); boolean contains(Object element); boolean add(E element); //optional boolean remove(Object element); //optional Iterator<E> iterator(); // 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 implementaes da interface Set: co
190
HashSet: Implementao de Set que utiliza uma tabela hash para guardar ca seus elementos. No garante a ordem de iterao, nem que a ordem pera ca manecer constante com o tempo (uma modicao da coleo pode ala ca ca terar a ordenao geral dos elementos). Por utilizar o algoritmo de tabela ca hash, o acesso rpido, tanto para leitura quanto para modicao. e a ca LinkedHashSet: Implementao de Set que estende HashSet, mas adica ciona previsibilidade ` ordem de iterao sobre os elementos, isto , uma a ca e iterao sobre seus elementos (utilizando o Iterator) mantm a ordem de ca e insero (a insero de elementos duplicados no altera a ordem anterior). ca ca a Internamente, mantida uma lista duplamente encadeada que mantm e e esta ordem. Por ter que manter uma lista paralelamente ` tabela hash, a a modicao deste tipo de coleo acarreta em uma leve queda na perforca ca mance em relao ` HashSet, mas ainda mais rpida que uma TreeSet, ca a e a que utiliza comparaes para determinar a ordem dos elementos. co TreeSet: Implementao de SortedSet. SortedSet uma interface que esca e tende Set, adicionando a semntica de ordenao natural dos elementos. a ca A posio dos elementos no percorrimento da coleo determinado pelo ca ca e retorno do mtodo compareTo(o), caso os elementos implementem a intere face Comparable, ou do mtodo compare(o1,o2) de um objeto auxiliar que e implemente a interface Comparator. A TreeSet utiliza internamente uma TreeMap, que por sua vez utiliza o algoritmo Red-Black para a ordenao ca da rvore de elementos. Isto garante a ordenao ascendente da coleo, de a ca ca acordo com a ordem natural dos elementos, denida pela implementao ca da interface Comparable ou Comparator. Use esta classe quando precisar de um conjunto (de elementos unicos) que deve estar sempre ordenado, mesmo sofrendo modicaes. co A seguir so mostrados alguns exemplos: a import java.util.*; public class FindDups { public static void main(String[] args) { 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 sada produzida ser: a 191
Duplicate detected: i Duplicate detected: i 4 distinct words: [i, left, saw, came] O tipo de implementao Set no exemplo anterior HashSet, que como dito ca e anteriormente no faz nenhuma garantia a respeito da ordem dos elementos no a Set. Caso seja necessrio imprimir a lista em ordem alfabtica basta mudar o a e tipo de implementao de HashSet para TreeSet. A nova sa do programa ca da anterior para TreeSet seria a seguinte: Rodando o programa: prompt#> java FindDups i came i saw i left A sada produzida ser: a Duplicate detected: i Duplicate detected: i 4 distinct words: [came, i, left, saw] Caso fosse utilizado uma LinkedHashSet a sa seria a seguinte: da Rodando o programa: prompt#> java FindDups i came i saw i left A sada produzida ser: a Duplicate detected: i Duplicate detected: i 4 distinct words: [i, came, saw, left]
E agora um outro exemplo, modicando a classe FindDups: import java.util.*; public class FindDups2 { public static void main(String[] args) { 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 cdigo anterior com os mesmos argumentos dos programas o anteriores (i came i saw i left) a sa deste programa seria: da Unique words: [left, saw, came]
Duplicate words: [i] H duas implementaes Set com nalidades especiais: EnumSet e CopyOna co WriteArraySet.
17.3
Interface List
Interface que extende Collection, e que dene colees ordenadas (seqncias), co ue onde se tem o controle total sobre a posio de cada elemento, identicado por ca um ndice numrico. Na maioria dos casos, pode ser encarado como um array e de tamanho varivel, pois, como os arrays primitivos, acess por a e vel ndices, mas alm disso possui mtodos de insero e remoo. A seguir mostada a e e ca ca e Interface List: public interface List<E> extends Collection<E> { // Positional access E get(int index); E set(int index, E element); boolean add(E element); void add(int index, E element); E remove(int index); boolean addAll(int index, Collection<? extends E> c); // 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
//optional //optional //optional //optional //optional
} Existem 2 implementaes da interface List: co ArrayList: Implementao de List que utiliza internamente um array de ca objetos. Em uma insero onde o tamanho do array interno no suca a e ciente, um novo array alocado (de tamanho igual a 1.5 vezes o are ray original), e todo o contedo copiado para o novo array. Em uma u e insero no meio da lista o contedo posterior ao ca u ndice deslocado em e uma posio. Esta implementao a recomendada quando o tamanho ca ca e da lista previs e vel (evitando realocaes) e as operaes de insero e co co ca remoo so feitas, em sua maioria, no m da lista (evitando deslocamenca a tos), ou quando a lista mais lida do que modicada (otimizado para e leitura aleatria). o LinkedList: Implementao de List que utiliza internamente uma lista ca encadeada. A localizao de um elemento na n-sima posio feita ca e ca e percorrendo-se a lista da ponta mais prxima at o o e ndice desejado. A insero feita pela adio de novos ns, entre os ns adjacentes, sendo ca e ca o o que antes necessria a localizao desta posio. Esta implementao e a ca ca ca e recomendada quando as modicaes so feitas em sua maioria tanto no co a in quanto no nal da lista, e o percorrimento feito de forma seqencio e u cial (via Iterator) ou nas extremidades, e no aleatria (por a o ndices). Um exemplo de uso como uma la (FIFO - First-In-First-Out), onde os elee mentos so retirados da lista na mesma seqncia em que so adicionados. a ue a A seguir so mostrados alguns exemplos: a import java.util.*; public class ExemploArrayList { public static void main(String[] args) { 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 sa produzida ser: da a Maria Joao Ana Joao Jose Ana [Maria, Joao, Ana, Joao, Jose] ArrayList e LinkedList tem algumas diferenas, entre elas temos os mtodos c e addFirst, addLast, getFirst, getLast, removeFirst e removeLast para LinkedList que inserem, retornam e retiram um elemento no inicio ou no m de uma lista , com estes mtodos podemos simular pilhas e las. e H uma implementao List com nalidades especiais: CopyOnWriteAra ca rayList.
17.4
Interface Map
Interface que dene um array associativo, isto , ao invs de nmeros, objetos e e u so usados como chaves para se recuperar os elementos. As chaves no podem se a a repetir (seguindo o mesmo princ pio da interface Set), mas os valores podem ser repetidos para chaves diferentes. Um Map tambm no possui necessariamente e a uma ordem denida para o percorrimento. A seguir mostada a Interface Map: e 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
} Existem 3 implementaes da interface Map: co HashMap: Implementao de Map que utiliza uma tabela hash para arca mazenar seus elementos. O tempo de acesso aos elementos (leitura e modicao) constante (muito bom) se a funo de hash for bem distribu ca e ca da, isto , a chance de dois objetos diferentes retornarem o mesmo valor pelo e mtodo hashCode() pequena. e e TreeMap: Implementaao de SortedMap. SortedMap uma Interface que c e estende Map, adicionando a semntica de ordenao natural dos elemena ca tos, anlogo ` SortedSet. Tambm adiciona operaes de partio da a a e co ca coleo, com os mtodos headMap(k) - que retorna um SortedMap com ca e 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 posteriores a k. A TreeMap utiliza o algoritmo Red-Black para a ordenao da ca a rvore de elementos. Isto garante a ordenao ascendente da coleo, de ca ca acordo com a ordem natural dos elementos, denida pela implementao ca da interface Comparable ou Comparator. Use esta classe quando precisar de um conjunto (de elementos unicos) que deve estar sempre ordenado, mesmo sofrendo modicaes. co LinkedHashMap: Implementao de Map que estende HashMap, mas adica ciona previsibilidade ` ordem de iterao sobre os elementos, isto , uma a ca e iterao sobre seus elementos (utilizando o Iterator) mantm a ordem de ca e insero (a insero de elementos duplicados no altera a ordem anterior). ca ca a Internamente, mantida uma lista duplamente encadeada que mantm e e esta ordem. Por ter que manter uma lista paralelamente ` tabela hash, a a modicao deste tipo de coleo acarreta em uma leve queda na perforca ca mance em relao ` HashMap, mas ainda mais rpida que uma TreeMap, ca a e a que utiliza comparaes para determinar a ordem dos elementos. co A seguir so mostrados alguns exemplos: a import java.util.*;
public class Freq { public static void main(String[] args) { 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 sada 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 invs de HashMap a sa seria: e da 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 sa seria: da 8 distinct words: {if=1, it=2, is=2, to=3, be=1, up=1, me=1, delegate=1} H duas implementaes Map com nalidades especiais: EnumMap, WeakHashMap a co e IdentityMap.
17.5
Interface Queue
Uma queue uma coleo para prender elementos antes de processarem. Alm e ca e das operaes bsicas da coleo, as las fornecem a insero, a remoo e co a ca ca ca operaes adicionais de inspeo. A seguir mostrada a Interface Queue: co ca e public interface Queue<E> extends Collection<E> { E element(); boolean offer(E e); E peek(); E poll(); E remove(); } Queue tipicamente, mas no necessariamente, manipulam os elementos como a uma FIFO (rst-in-rst-out). Entre as excees esto as priority queues (las co a com prioridades), que requisitam elementos de acordo com algum de seus valores. O primeiro elemento da la (cabea da la) o elemento que seria removido c e pela chamada do mtodo remove ou poll. Em uma queue do tipo FIFO, todos e os elementos novos so introduzidos no nal da la. Outros tipos de queue a 197
podem usar regras diferentes de colocao. Cada implementao de queue deve ca ca especicar suas propriedades. E poss que algumas implementaes de queue restrinja o nmero de elvel co u ementos que prende; tais las so conhecidas como limitadas. Algumas ima plementaes de queue em java.uitl.concurrent so limitadas, mas as impleco a mentaes em java.util no so. co a a As implementaes da queue geralmente no permitem a insero de elemenco a ca tos nulos. A implementao de LinkedList, que foi adaptada para implementar ca uma queue, uma exceo. e ca A seguir mostrado um exemplo: e 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 uma la de prioridade baseada na estrutura de e dados heap. Esta la requisita elementos de acordo com uma ordem especicada no tempo da construo. ca A interface queue estendida pela BlockingQueue. Algumas implementaes e co de BlockingQueue so: LinkedBlockingQueue, ArrayBlockingQueue, Prioritya BlockingQueue, DelayQueue e a SynchronousQueue.
198
Cap tulo 18
JDBC - Java Database Connectivity

18.1 Conceitos Bsicos a
Java Database Connectivity ou JDBC um conjunto de classes e interfaces e (API) escritas em Java que faz o envio de instrues SQL para qualquer banco co de dados relacional. API de baixo n e base para APIs de alto n vel vel; Amplia o que voc pode fazer com java; e Possibilita o uso de banco de dados j instalados; a Para cada banco de dados h um driver JDBC que pode cair em quatro a categorias. As 4 categorias de driver so: a TIPO 1: PONTE JDBC-ODBC E o tipo mais simples mas restrito ` a plataforma Windows. Utiliza ODBC para conectar-se com o banco de dados, convertendo mtodos JDBC em chamadas `s funes do ODBC. e a co Esta ponte normalmente usada quando no h um driver puro-java (Tipo e a a 4) para determinado banco de dados, pois seu uso desencorajado devido e a ` dependncia de plataforma. e 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 mquina cliente. a TIPO 3: DRIVER DE PROTOCOLO DE REDE Traduz a chamada JDBC para um protocolo de rede independente do banco de dados utilizado, que traduzido para o protocolo do banco de dados por um servie dor. Por utilizar um protocolo independente, pode conectar as aplicaes co java a vrios banco de dados diferente. E o modelo mais ex a vel.
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 prprios desenvolvedores. E o o tipo mais recomendado para ser usado.
Figura 18.1: Tipos de Drivers JDBC Como mostrado na gura 18.1 a aplicao java chama a biblioteca JDBC. ca 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 necessrios (import java.sql.*), a devemos seguir certos passos para que seja poss vel o acesso ao SGBD. Devemos inicialmente carregar o driver e depois criar a conexo propriamente a dita. A carga do driver muito simples. Basta invocar o mtodo esttico: e e a 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 funo instanciar a classe identicada entre parnteses ca e e registr-la com a JVM, que ir utiliz-la para acessar o SGBD. Em nosso exa a a emplo, utilizamos a ponteODBC-JDBC. A Class uma classe no pacote de e java.lang.
18.3
Conexo a
Feito o carregamento dos drivers, o prximo passo o estabelecimento da o e conexo. Tipicamente uma aplicao JDBC conecta ao banco de dados usando a ca 200
um dos seguintes mecanismos: DriverManager: Esta implementao requer que uma aplicao carregue ca ca um driver espec co, usando uma URL hardcoded. Como parte de sua inicializao, a classe DriverManager tenta carregar as classes do driver ca referenciado. Isto permite que voc customize os drivers de JDBC usados e por suas aplicaes. co DataSource: Esta interface preferida sobre a DriverManager porque pere mite que os detalhes sobre a origem dos dados sejam transparentes a sua aplicao. As propriedades de um objeto de DataSource so ajustadas de ca a modo que represente uma origem particular de dados. Para abrirmos uma conexo, normalmente teremos que entrar em contato a com o SGBD. A linha mostrada abaixo d a idia geral de como feita ` conexo a e e a a atravs do mecanismo DriverManager: e try{ Connection con = DriverManager.getConnection(url,"user", "password"); }catch( SQLException x ){ System.out.println( "Couldnt get connection!" ); } A parte mais complexa montar a url. Esta parte da informao sempre e ca se inicia com jdbc: mas o resto depende do fabricante do banco. Na seqncia ue normalmente temos o nome do fabricante (ento temos jdbc:db2, jdbc:oracle, a jdbc:psql e etc) e por ultimo o nome da fonte de dados (ento temos jdbc:db2:db, a jdbc:oracle:server.unicamp.br:1234/meubanco e etc). O prximo exemplo mostra como seria o estabelecimento de conexo atravs o a e 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 conexo propriamente dita acontece de maneira a transparente. O programador no tem necessidade nenhuma de saber o que a se passa e, a no ser que ele um dia resolva escrever seu prprio driver para a o conexo a algum SGBD, tem que se dar por satisfeito da coisa acontecer assim. a A partir de agora, o objeto con representa uma conexo ativa e aberta ao a banco de dados e o programador pode utiliz-lo para enviar statements SQL a para o banco.
18.4
Statements
E necessrio criar um objeto da classe Statement para armazenar o pedido a que ser enviado ao SGBD. O programador deve simplesmente criar um objeto a deste tipo, informar a cadeia de strings que representa seu comando SQL e depois execut-lo, usando mtodos especiais dependendo do tipo de comando a e 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 no existe nenhum comando a SQL nele. Podemos executar um comando como no exemplo abaixo: stmt.executeUpdate( "DELETE FROM Clientes WHERE CPF = " + cpf + ""); Note que existe uma estrutura de parnteses, sinais de concatenao e aspas. e ca Esses sinais so importantes e muitas vezes causam confuses tremendas em a o programas. Deve-se ter muito cuidado com eles, principalmente quando houver variveis do programa java misturadas ao SQL. a O mtodo mais comum de ser utilizado o executeQuery. Mas ele retorna e e 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 chamada ResultSet. E necessrio instanciar um objeto e a 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 mtodos presentes na classe ResultSet. e Esses mtodos permitem andarpelos resultados e copiar os valores para outros e 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 mtodo next() movimenta o cursor para o e prximo registro, tornando aquele registro o corrente. Podemos ento execuo a tar outros mtodos. Note que o cursor inicialmente ca posicionado acima do e primeiro registro, exigindo uma primeira execuo do next() para que possamos ca processar o primeiro registro. Utilizamos mtodos cujo nome se iniciam com get para obter os dados das e colunas. Eles devem ser obtidos de acordo com o tipo (o cast pode ser efetuado, quando houver possibilidade), e esses mtodos permitem que apontemos as cole unas pelo nome ou pelo ndice (seu nmero, na hora em que foi recebida e no u a na ordem da tabela original). Assim, o cdigo anterior poderia ser: o 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
` As vezes mais conveniente usar um objeto PreparedStatement para enviar e comandos sql para a base de dados. Este tipo especial de statement derivado e da classe mais geral, Statement. A principal diferena que o prepared statement contm no apenas um c e e a comando SQL, mas sim um comando SQL pr-compilado. Isso signica que e quando o prepared statement executado, o SGBD deve apenas rodar o coe mando SQL sem ter que fazer sua compilao primeiro. ca Os objetos PreparedStatements podem ser usados sem parmetros no coa mando SQL, embora seja mais freqente o uso com parmetros. A vantagem da u a utilizao de parmetros que voc pode fornecer valores diferentes ao mesmo ca a e e statement a cada vez que voc execut-lo. e a PreparedStatement pstmt = conn.prepareStatement("insert into TABLE values (?,?)"); pstmt.setString(1,arquivo.getName()); pstmt.setBinaryStream(2,inputStream,(int)arquivo.length()); pstmt.executeUpdate(); Note que voc pode possuir diversos tipos de campos diferentes, e nem por e 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 devero ser dadas na mesma ordem que a foi inserido os sinais de interrogao. A seguir mostrada uma operao de ca e ca 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
Transao ca
Existem situaes onde no se deseja que uma instruo tenha efeito a no ser co a ca a que outras tambm tenham. Algumas situaes necessitam que dados sejam e co inclu dos em mais de uma tabela para que sejam considerados consistentes. Ou os dados esto presentes em todas as tabelas ou no devem estar presentes em a a nenhuma.
203
A tcnica utilizada para garantir esse tipo de consistncia e o uso de transaes. e e co Uma transao nada mais do que statements que so executados juntos, como ca e a uma coisa unica: ou todos falham, ou todos so executados. a A primeira providncia desabilitar o auto-commit. Quando uma conexo e e a criada, o padro que ela trate cada executeUpdate como uma transao e a e ca separada, que validada (commit) assim que completada. Assim, devemos e e utilizar o cdigo: o con.setAutoCommit(false); A partir daqui, nenhum statement ser validado at que o programador a e permita. Todos eles sero agrupados e validados como um s. Ao nal do a o processo (caso tudo tenha transcorrido de acordo com o esperado), executa-se: con.commit(); Caso algo no tenha dado certo, podemos executar o mtodo rollback para a e que todo o statement seja descartado. con.rollback(); E importante lembrar algumas coisas quando lidamos com a transao de ca maneira manual. Os recursos de banco normalmente cam presos, esperando um commi() ou rollback(). Assim, se um programa tratar ou entrar em loop (ou mesmo demorar muito) o acesso ao banco ca prejudicado. Existe ainda a possibilidade de um dirty read, onde outro programa recupera dados do disco que voc est alterando, mas ainda no validou. Esse tipo de comportamento e a a pode ser evitado aumentando o n de isolamento entre transaes. Verique vel co o mtodo setTransactionIsolation() da classe Connection. e
18.7
Informaes Complementares co
Ocasionalmente, voc ir sentir necessidade de obter mais informaes sobre o e a co resultado de um SELECT ou mesmo sobre a tabela em questo. Pode-se obter a 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 informaes acerca do nmero de co u colunas recebidas, o nome e o tipo das colunas, se alguma coluna aceita dados nulos, campos de data etc. Alm disso fornece tambm informaes sobre a e e co 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 cap tulo. 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~o a 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~es de UPDATE co ... //"commitando" todos os updates realizados de uma nica vez u con.commit(); } }
206
Cap tulo 19
A plataforma J2EE
A plataforma J2EE uma soluo baseada em componentes para projeto, dee ca senvolvimento, montagem e disponibilizao de aplicaes distribu ca co das em ambientes corporativos. O J2EE oferece, entre outras tecnologias: Modelo multi-camada de aplicaes distribu co das (multi-tier ); Componentes Reutilizveis; a Modelo de segurana unicado; c Controle de transaes ex co veis; Suporte a servios Web (web services). c No modelo multi-camada distribu da arquitetura J2EE as seguintes cardo acter sticas so importantes: a Os componentes que compem a aplicao podem estar em diferentes o ca mquinas; a Suas localizaes dependem da camada a que pertence. co Tipicamente, as aplicaes J2EE so divididas em 4 camadas que so: co a a Cliente (client-tier ); Web (web-tier ); Negcios (bussiness-tier ); o
Sistemas de Informao (EIS-tier ). ca As caracter sticas mais comuns dos componentes J2EE so o fato deles serem a unidades de software auto-contidas e a capacidade de comunicao com outros ca componentes. O que distingue um componente J2EE de uma classe comum o e fato deles poderem ser combinados para formar uma aplicao J2EE, alm de ca e serem disponibilizados, executados e gerenciados por um servidor J2EE, comumente chamado de servidor de aplicao. ca A tabela a seguir mostra exemplos de componentes J2EE e o seus respectivos tipo e local de execuo. ca
207
Figura 19.1: Arquitetura J2EE Componente Clientes da aplicao e Applets ca Servlets e Pginas JSP a Enterprise Java Beans Tipo Cliente J2EE Web Negcios o Local de Execuo ca Cliente Servidor Servidor
Tabela 19.1: Componentes J2EE
19.1
Containers J2EE
Na arquitetura J2EE um container um ambiente que fornece um conjunto e de servios para os componentes. Um componente deve ser colocado em um c container apropriado para que possa ser executado. Um exemplo simples de container o Apache Tomcat, que na arquitetura J2EE funciona como um cone tainer Web, fornecendo servios para rodar pginas JSP e Servlets. c a Algumas dos servios prestados pelos containers podem ser congurados. c Exemplo deles so: a Segurana; c Gerenciamento de Transaes; co Busca de Nomes e Diretrios utilizando JNDI (Java Naming and Directory o Interface);
Conectividade Remota entre clientes e EJBs; No entanto, alguns dos servios oferecidos pelos containers no podem ser c a congurados, uma vez que contituem o ncleo da arquitetura e conferem a u escalabilidade da soluo. Exemplo de servios no congurveis so: ca c a a a Criao de Destruio de EJBs e Servlets (Ciclo de Vida dos Compoca ca nentes). So utilizados pools de componentes para atender as requisies a co dos usurios. No o programador instancia um componete no cdigo a a e o do cliente, porm a criao efetiva do objeto acontece no servidor de e ca aplicao, onde o componente existe e executado de fato; ca e Acesso `s APIs da plataforma; a 208
Gerenciamento de conexes com bancos de dados. Os servidores de aplicao o ca implementam o conceito de pools de conexes. O programador no preo a cisa escrever o cdigo para abertura e encerramento da conexo, pois isso o a papel do servidor de aplicao; e ca Persitncia do estado dos componentes. e
19.2
Clientes J2EE
Na arquitetura J2EE existem basicamente dois tipos de clientes que so: a Clientes Web: Pginas Web dinmicas geradas por componentes Web a a (JSP ou Servlets) e que so exibidas no browser. Existe ainda os applets, a que so pequenos clientes de aplicao escritos em Java e que rodam na a ca JVM embutida no browser. Clientes de Aplicao: Permitem que o usurio interaja com o servidor ca a de aplicao atravs de interfaces mais complexas, geralmente feitas utica e lizando as APIs Swing ao AWT (Abstract Window Toolkit). E importante ressaltar que toda a lgica de negcio implementada pelos o o e EJBs, que rodam no servidor de aplicao. Assim como os EJBs , os Servlets e ca pginas JSP tambm esto em um servidor de aplicao, porm no no mesmo a e a ca e a container. Os Servlets so classes Java que processam dinamicamente as requisies e a co controem respostas na forma de pginas HTML. As pginas JSP permitem ina a serir cdigo java diretamente em um documento HMTL, sendo apropriadas para o criar contedo dinmico e, em geral, para descrever a lgica de apresentao. u a o ca
19.3
Um pouco mais sobre Servlets
Um servlet uma classe java que extende as capacidades do servidor que acese sam aplicaes num modelo de programa requisio e resposta. Os servlets, co ca como denidos na interface Servlet dispon vel no pacote javax.servlet, so ina dependentes de protocolo, e denem os mtodos que todos os servlets devem e implementar. Os servlets so especialmente populares no desenvolvimento de a aplicaes Web, cuja comunicao baseada no protocolo HTTP. co ca e A classe HttpServlet, dispon no pacote javax.servlet.http, implementa a vel interface Servlet e prov a base para implementao de aplicaes Web empree ca co gando o protocolo HTTP. Do ponto de vista do cliente, um servlet funciona atendendo uma requisio ca e gerando contedo dinmico em forma de pginas web, em HTML por exemplo, u a a como resposta. O cdigo a seguir exemplica a criao de um servlet. o ca
209
import import import import
javax.servlet.*; javax.servlet.http.*; java.io.*; 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 informao dos formulrio HTML para gerar uma ca a pgina, tambm HTML, como resposta ` requisio do cliente. O trecho a a e a ca seguir mostra o cdigo HTML da pgina que contem o formulrio. o a a <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 cdigo a seguir mostra a pgina HTML retornada o a como resposta pelo servlet, supondo que o usrio tenha digitado zazaza. a <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 sistema inicia uma aplicao baseada em um servlet. Nesse momento, o container ca responsvel pelos servlets no servidor de aplicao cria uma instncia de um a ca a servlet. O container tambm passa os parmetros de inicializao do servlet e a ca atravs do mtodo init. Os parmetros de inicializao persistem at o servlet e e a ca e ser destru do.
Se o processo de incializao ocorrer com sucesso, o servlet se torna dispon ca vel para servio (atendimento de requisies). Se o processo falhar o container c co descarrega o servlet. Aps a que um servlet se torna dispon o vel, o administrador pode optar para coloc-lo em um estado de indispon a vel, e assim ele permanecer at que o ada e ministrador execute a operao contrria. ca a Quando um requisio de um cliente chega ao servidor de aplicao, o conca ca tainer cria os objetos request e response, que so passados de parmetro para a a o mtodo service. e
211
O mtodo service recupera informaes sobre a requisio a partir do obe co ca jeto request, processa a requisio, e em seguida utiliza o objeto response para ca criar uma resposta para o cliente.O mtodo service pode ainda chamar outros e mtodos para processar a requisio, como doGet(), doPost(), ou mtodos ese ca e critos pelo prprio programador. o Quando o administrador encerra a aplicao, o container invoca o mtodo ca e destroy() e descarrega o servlet. A gura 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 aplicaes requerem que uma srie de requisies de um mesmo cliente co e co sejam associadas uma com a outra, para que uma determinada operao faa ca c sentido. Um exemplo prtico uma aplicao de carrinho de compras, em que a e ca o cliente vai navegando durante as pginas escolhendo os produtos e ao nal a realiza a compra de fato. O per odo que compreende a entrada no site, passando pela escolha dos produtos e chegando ao pagamento ou ao cancelamento comumente chamada de sesso. A aplicao responsvel por manter o estado e a ca e a da sesso, tendo em vista que o protocolo HTTP um protocolo stateless. a e Para suportar aplicaes que precisam manter um estado, os servlets ofereco cem APIs para implementar o conceito de sesso. a As sesses so representadas pelo objeto HttpSession. Uma sesso pode ser o a a acessada chamando o mtodo getSession do objeto request. Esse mtodo ree e torna a sesso corrente associada com o request, e se ela ainda no existir, uma a a 212
sesso criada. Como o mtodo getSession pode modicar o header da resposta a e e (response header), esse mtodo deve ser chamado antes de recuperados o Printe Writer ou o ServletOutputStream (objetos que servem para mandar dados para o cliente). Atributos podem ser associados a uma sesso pelo nome. Tais atributos a podem ser acessados por qualquer componente Web que pertena ao mesmo c contexto esteja atendendo uma requisio que seja parte da mesma sesso. A ca a seguir um exemplo de Servlet que mantm sesses: e o 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 no h nenhuma forma de um cliente HTTP sinalizar que uma sesso a a a no mais necessria (a no ser via aplicao), cada sesso possui um valor de a e a a ca a timeout. O valor de timeout pode ser acessado atrves dos mtodos getMaxa e InactiveInterval e MaxInactiveInterval. Geralmente o tempo mximo de a inatividade permitido para uma sesso tambm feita no servidor de aplicao. a e e ca
19.4
Um pouco mais sobre pginas JSP a
Java Server Pages (JSP) uma tecnologia que permite embutir cdigo java em e o uma pgina HTML para gerar contedo dinmico. Um exemplo simples de uma a u a pgina JSP a seguinte: a e <HTML> <BODY> <% int a = 1 + 3; %> Hello! O valor de a <%= a %> e </BODY> </HTML> Todo cdigo java aparece na pgina .jsp deve estar entre as tags % e %. o a Para imprimir algum valor na pgina utilizada as tag %= e %, ou alternaa e tivamente os mtodos out.print() ou out.println(), como mostrado no exemplo e 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 pgina um exemplo de diretiva JSP. Elas sempre so a e a denidas entre as tags %@ e %. No exemplo utilizada uma diretiva de ime 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 contedo do arquivo especicado durante a fase u de compilao da pgina JSP, ou seja, quando esta convertida em um Servlet. ca a e Neste caso, os dois arquivos so combinados para gerar um s. E muito util a o quando uma pgina estruturada em partes bem denidas (topo, menu, roa e dap, etc.). A seguir um exemplo do uso de uma diretiva include. e <%@ include file="right_menu.jsp" %> <HTML> <BODY> <h1> Noticias do dia </h1> COECA aprova mais de 30 em 2007. A soma dos salrios j chega a R$ 150.000! a a </BODY> </HTML> Um outro recurso das pginas JSP so as chamadas taglibs, que so um a a a mecanismo portvel para encapsular funcionalidades reusveis em pginas da a a a Web. As tags podem ser de dois tipos: carregadas de uma biblioteca externa de tags ou pr-denidas. As tags pr-denidas sempre se iniciam com jsp. Exemplo e e de chamadas a tag pr-denidas so mostrados abaixo: e a
// Exemplo 1: // Inclui uma pgina dentro de outra no momento da compila~o. a ca <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 preciso utilizar a diretiva taglib para especicar onde a biblioteca de tag e (tag library) est localizada. a <%@ 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 pgina JSP requisitada pela primeira vez, o container compila a e a pgina JSP gerando um servlet. Nas chamadas sucessivas essa etapa no a a e mais necessria, a no ser que a pgina JSP tenha sido modicada. Portanto, a a a as pginas JSP so, em ultima instncia, processadas como servlets. a a a Pelo fato de ser transformada em um servlet, durante o processamento de pginas JSP, o container tambm cria os objetos request e response. O objeto a e request armazena informaes enviadas na requisio do cliente, por exemplo, co ca os campos de um formulrio de cadastro. O seguinte trecho de cdigo mostra a o como o objeto request utilizado em uma pgina JSP. e a
<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~o ca String ip = request.getRemoteHost(); %> Ol <b> <%=nome%> </b>, o endereo IP da sua mqina <%=ip%> a c a e
215
</BODY> </HTML>
19.5
Um pouco mais sobre EJBs
Os EJBs (Enterprise Java Beans) so componentes de software simples, rea utilizveis e portveis, que podem ser combinados para criar aplicaes corpoa a co rativas. Eles encapsulam a lgica de negcio, ou seja, o cdigo que realiza o o o o propsito da aplicao. Tecnicamente falando, os EJBs tambm so classes o ca e a Java, com seus prprios atributos e mtodos. o e As instncias dos EJBs so executadas em containers de EJB nos servidores a a de aplicao. So os containers que gerenciam o ciclo de vida dos EJBs, deca a cidindo quando eles devem ser criados ou destru dos. Os principais benef cios da utilizao dos beans so: ca a O desenvolvedor dos clientes pode se concentra na lgica de apresentao; o ca Os clientes so menos pesados, j que os EJBs so executados nos cona a a tainers do servidor de aplicao; ca Maior reutilizao de componentes. ca Os dois tipos mais importantes de EJBs so: a Session Beans: Modelam os processo da lgica de negcios, executam tarefas para os o o clientes e podem implementar web services. No momento da requisio do ca cliente, um session bean alocado para atendimento, tornando exclusivo e at o m do atendimento da requisio. Os sessions beans podem ser de e ca dois tipos: stateless ou statefull. Os beans stateless no mantm o estado a e da conversao, ou seja, aps o trmino da execuo de um mtodo todo ca o e ca e o estado (valor dos atributos do EJB) se perdem, e o mesmo liberado, se e tornando livre para atender outra requisio. J com os beans statefull, o ca a estado pode ser modicados e recuperado entre sucessivas invocaes de co mtodos. Todos os mtodos invocados pelo cliente so enviados a mesma e e a instncia, que mantm o estado at que a sesso termine ou o bean seja a e e a destru do.
Entity Beans: So responsveis pela persistncia dos dados da aplicao, geralmente utia a e ca lizando bancos de dados. Nesse contexto, bean desse tipo est associado a a uma tabela em um BD, enquanto cada intncia de um entity bean repa resenta um registro de tal tabela. Esse tipo de bean pode ser compartilhado por mltiplos usurios, sendo necessrio para isso o gerenciamento u a a de transaes, que um dos servios prestados pelo container EJB. Cada co e c bean tem um identicador unico que permite encontr-lo. Como na tabela a de um BD relacional, um entity bean pode estar relacionado a outros, podendo este relacionamento ser implementado pelo prprio bean ou pelo o container. Com os entity beans, o container responsvel por todas as e a 216
chamadas ao banco de dados (Ex: Uma atualizao de um entity bean faz ca com que o container dispare um SQL Update, enquanto a criao de um ca novo entity bean ir fazer o container disparar um SQL Insert.) A idia a e eliminar ao mximo a necessidade de escrever comandos SQL. Todos os e a comandos SQL envidos ao banco fazem uso das conexes dispon o veis em um pool de conexes, que tambm um servio gerenciado pelo servidor o e e c de aplicao. ca
19.5.1
Ciclo de Vida dos EJBs
Um EJB passa por vrios estados ao longo de seu ciclo de vida, sendo a que cada tipo de EJB tem um ciclo de vida espec co. No caso dos EJBs stateless, o ciclo de vida descrito pelos seguintes estados e eventos: e O bean inicia em estado Does Not Exist; O cliente invoca um mtodo create() na interface local; e O container instancia o bean e os mtodos setSessionContext() e e ejbCreate(), implementados no bean, so invocados. A partir da o a , EJB passa para o estado Ready; Ao nal, o cliente invoca o mtodo remove() na interface local e em e seguida o container invoca o mtodo ejbRemove(), implementado no e 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, descrito pelo seguintes e estados e eventos: O bean inicia em estado Does Not Exist; O cliente invoca um mtodo create() na interface local; e O container instancia o bean e os mtodos setSessionContext() e e ejbCreate(), implementados no bean, so invocados. A partir da o a , EJB passa para o estado Ready; 217
Quando no estado Ready, o container pode optar por desativar o bean, ou seja, transfer para memria secundria invocando o -lo o a mtodo ejbPassivate(). Nesse caso, o EJB vai para o estado Pase sive; Para reativar o bean, o container deve chamar o mtodo ejbActie vate(), levando-o para o estado Ready novamente; Ao nal, assim como nos EJBs stateless, o cliente invoca o mtodo e remove() na interface local e em seguida o container invoca o mtodo e ejbRemove(), implementado no bean, e o EJB volta para o estado Does Not Exist; Os processos de desativao e ativao de um EJB consistem em salvar ca ca seu estado em memria secundria e restaur-lo, respectivamente. Nesses o a a processos os containers utilizam tcnicas de serializao. Atualmente, os e ca containers tm implementado a serializao utilizando arquivos XML. e ca Como foi discutido, os containers fazem uso dos chamados pools de EJBs, que so um conjunto de beans designados a atender as requisies dos a co usurios. Em determinados momentos, os beans de um pool podem estar a completamente alocados para atendimento de usurios. Um cliente que a desejasse ter sua requisio atendida teria que aguardar a desalocao de ca ca um bean por parte de um cliente. No entanto, alguns dos beans no pool podem estar inativos, aguardando invocao de mtodos por parte dos clientes. E papel do container decidir ca e quando um bean deve ir para o estado passivo (ser serializado) para liberar recursos, que em ultima instncia se traduz em memria no servidor de a o aplicao, permitindo que novas requisies sejam atendidas. Quando um ca co cliente que teve seu bean serializado decidir realizar uma nova requisio, ca um bean deve ser alocado e o seu estado deve ser restaurado da memria o secundria para a memria principal. a o
218
Figura 19.4: Ciclo de vida de um EJB statefull
219
Parte V
Desenvolvimento Web
220
Cap tulo 20
Usabilidade
20.1 Denio ca
A norma ISO 9241-11 dene a usabilidade como: a extenso em que um produto a pode ser usado por usurios espec a cos para alcanar objetivos espec c cos com eccia, ecincia e satisfaao num contexto espec a e c co de uso. E, dene uma estrutura para a usabilidade, gura 20.1.
Figura 20.1: Estrutura de usabilidade segundo a ISO 9241-11 Conforme a estrutura preciso identicar os objetivos, e decompor a usabile idade (eccia, ecincia e satisfao) em atributos pass a e ca veis de serem vericados e mensurados, assim como o contexto de uso (usurio, tarefa, equipamento a e ambiente). Contextualizando o ambiente para as pginas de Web, a usabilidade o a e termo tcnico usado para referenciar a qualidade de uso de uma determinada e interface. Ela refere-se ao grau com que o usurio consegue realizar uma tarefa. a
221
Em geral, so considerados os seguintes atributos para vericao da usabilia ca dade numa interface: funcionalidade correta; a ecincia de uso; a facilidade e de aprendizagem; a facilidade de relembrar; tolerncia ao erro do usurio; e a a satisfao do usurio. ca a
20.2
Princ pios da usabilidade
Os principais pontos que um Web site deve cumprir so: a Usar etiquetas ALT para todas as imagens, especialmente as de navegao; ca Usar texto negro em fundo branco sempre que poss para uma legibilivel 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 (no a branco); Colocar o menu de navegao numa localizao consistente em cada pgina ca ca a do site; Usar localizaes familiares para as barras de navegao; Usar um design co ca adequado para que nunca seja necessrio recorre ao scroll horizontal; a Usar um eixo de simetria para centrar o texto numa pgina; Encorajar o a uso do scroll atravs da colocao de uma imagem que que semi-escondida e ca no fundo da pgina. a Deve-se tentar evitar: As etiquetas ALT sejam reduzidas (especialmente para uma pequena imagem de tamanho xo); Mostrar texto esttico em azul ou a sublinhado; a Usar o negrito ou maisculo para texto longo; u Deixar espaos em branco muito longo a leitura torna-se mais dif c cil;
Obrigar o utilizador a fazer scroll para encontrar informao importante, ca especialmente botes ou links de navegao; o ca Usar travesses para separar horizontalmente diferentes tipos de contedos; o u Alternar frequentemente entre texto centrado e alinhado ` esquerda. A a maior parte do texto deve estar alinhada ` esquerda; a Fixar a resoluo das pginas a mais de 800 X 600. Pginas de grandes ca a a resolues podem obrigar o utilizador a fazer scroll horizontal. co As principais vantagens do estudo da usabilidade de um produto de software so: a
222
Aumentar a produtividade dos utilizadores; Aumentar os n veis de utilizao do produto; ca Reduzir a necessidade de formao e de custos de produo de docuca ca mentao; ca Reduzir os custos de suporte tcnico; e Reduzir custos e tempo de desenvolvimento; Minimizar o re-desenvolvimento e as alteraes aps a nalizao. co o ca
20.3
Tcnicas de avaliao de usabilidade e ca
A usabilidade pode ser avaliada por diversas tcnicas. As mais usuais so da e a heur stica e dos testes com utilizadores. A heur stica uma das formas de avaliar a usabilidade mais econmica e e o prtica, permitindo detectar problemas na fase de desenvolvimento da interface. a Esta tcnica consiste em levantar questes heur e o sticas relacionadas ` interface a como: navegao, controle, funcionalidade, linguagem, ajuda e suporte, conca sistncia e erros. Nunca deve ser feita individualmente, pois uma pessoa no e a tem capacidade de levantar todas as questes heur o sticas. A tcnica dos testes com utilizadores obriga que o produto esteja pelo menos e em forma de prottipo para poder ser testado. O utilizador testa a interface o tendo por base um conjunto de tarefas que foram denidas como princ pios heur sticos. Portanto, o objetivo de um bom design de pginas Web obter alta qualia e dade, no que diz respeito no somente a uma boa aparncia visual, como tambm a e e a ` estruturao da informao de forma a permitir aos usurios encontr-la rpida ca ca a a a e ecaz.
223
Cap tulo 21
Acessibilidade
21.1 Denio ca
A acessibilidade descreve os problemas de usabilidade encontrados por usurios a com necessidades especiais ou com limitaes tecnolgicas. Na prtica, a acessico o a bilidade de uma interface indicada pela facilidade de acesso de um indiv e duo, independente de suas capacidades f sicas, sensoriais e cognitivas, do seu ambiente e das condies de trabalho e das barreiras tecnolgicas. Ou seja, a co o acessibilidade signica que pessoas com necessidades especiais podem apreender, compreender, navegar e interagir com a Web. As causas mais freqentes de falta de acessibilidade em muitas pginas da u a Web para todos os usurios esto muitas vezes associadas: ` falta de estrua a a tura que desorienta o usurio dicultando a navegao e ao uso abusivo de a ca informaes grcas (imagens, macros, scripts Java, elementos multim co a dia) sem proporcionar alternativas adequadas de texto ou outro tipo de comentrio. a
21.2
Princ pios da acessibilidade
Os princ pios de acessibilidade segundo W3C esto relacionados a dois prina cipais temas: assegurar uma transformao harmoniosa e tornar o contedo ca u compreens vel e navegvel. Estes princ a pios so abordados num documento a elaborado pelo W3C (Word Wide Web Consortium)-WAI (Web Accessibility Initiative), considerado referncia para os princ e pios de acessibilidade e idias e de design, chamado Web Content Accessibility GuideLines, WCAG 1.0. A transformao harmoniosa de uma pgina Web pode ser garantida pela ca a observncia de alguns pontos-chaves: a Separar a estrutura da apresentao, diferenciando o contedo (a inca u formao a ser transmitida), a estrutura (a forma como a informao orca ca e ganizada em termos lgicos) e a apresentao (a forma como a informao o ca ca reproduzida, por exemplo, como matria impressa, como apresentao e e ca grca bidimensional, sob forma exclusivamente grca, como discurso a a sintetizado, em braille, etc.); Criar pginas que cumpram a sua nalidade, mesmo que o usurio no a a a possa ver e/ou ouvir, fornecendo informaes que preencham a mesma co 224
nalidade ou funo que o udio ou o v ca a deo, de maneira a se adaptar o melhor poss a canais sensoriais alternativos e as tecnologias de apoio (softvel ware ou hardware para ajudar pessoas com incapacidade ou decincia) e atualmente dispon veis no mercado; Criar pginas que no dependam exclusivamente de um tipo de equipaa a mento. As pginas devem ser acess a veis a usurios que no possuam a a mouse, que recebam voz ou texto, etc. Os criadores de contedo para a Web necessitam tornar suas produes comu co preens veis e navegveis, empregando uma linguagem clara e disponibilizando a meios de navegao e apropriao da informao apresentada. Disponibilizar ca ca ca mecanismos de orientao de pgina e ferramentas de navegao so fatores que ca a ca a potencializam a acessibilidade ` Web ao garantir a perceptibilidade e navegaa bilidade no site, pois sem esses elementos, os usurios podem, por exemplo, no a a compreender tabelas, listas ou menus extensos. O documento WCAG 1.0 descreve os 14 princ pios ou diretrizes que abordam as questes relacionadas ` acessibilidade ` Web. Cada diretriz possui pontos de o a a vericao os quais so classicados por n ca a veis de prioridade. Os 14 princ pios so: a 1. Fornecer alternativas ao contedo sonoro ou visual esta diretriz indica a u necessidade de disponibilizar contedo que, ao ser apresentado ao usurio, u a transmita, em essncia, as mesmas funes e nalidades do contedo e co u sonoro e visual. Assim, deve-se fornecer um equivalente textual a cada elemento no textual; a 2. No recorrer apenas a cor deve-se garantir a percepo do texto e dos a ca elementos grcos do documento, mesmo quando so vistos sem cores. a a Assim, deve-se assegurar que todas as informaes veiculadas por meio co de cores estejam tambm dispon e veis sem cor, por exemplo, a partir de informaes do contexto ou de marcao apropriada; co ca 3. Utilizar corretamente anotaes (proporciona efeitos de formatao, com co ca por exemplo, B ou I em HTML) e folhas de estilo (conjunto de declaraes co que especicam a apresentao do documento) esta diretriz indica a ca necessidade de se utilizar marcao nos documentos com os elementos ca estruturais adequados e controlar a apresentao por meio de folhas de ca estilo, em vez de elementos de apresentao e atributos; ca
4. Indicar claramente qual o idioma utilizado utilizar marcaes que faco cilitem a pronncia e a interpretao de abreviaturas ou de texto em l u ca ngua estrangeira imprescind e vel. Deve-se identicar claramente quaisquer mudanas de idioma no texto de um documento, bem como nos equivalentes c textuais; 5. Criar tabelas pass veis de transformao harmoniosa assegurar que as ca tabelas tm as marcaes necessrias para serem transformadas de forma e co a harmoniosa por navegadores acess veis a outros agentes do usurio. Em a tabelas de dados, preciso identicar os cabealhos de linha e de coluna; e c 6. Assegurar que as pginas dotadas de novas tecnologias sejam transfora madas harmoniosamente permitir que as pginas sejam acess a veis mesmo 225
quando as novas tecnologias mais recentes no forem suportadas ou tena 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 usurio sobre as alteraes temporais do contedo a co u assegurar a possibilidade de interrupo momentnea ou denitiva do ca a movimento, intermitncia, transcurso ou atualizao automtica de pginas e ca a a e objetos; 8. Assegurar acessibilidade direta em interfaces integradas pelo usurio a a interface com o usurio deve obedecer a princ a pios de design para a acessibilidade: acesso independente de dispositivos, operacionalidade pelo teclado, emisso automtica de voz (verbalizao); a a ca 9. Projetar pginas considerando a independncia de dispositivos utilizando a e funes que permitam a ativao de pginas por meio de dispositivos de co ca a entrada e de comandos. Geralmente as pginas que permitem interao a ca pelo teclado so tambm acess a e veis atravs de interfaces de comando de e voz ou de linhas de comando; 10. Utilizar solues provisrias ou de transio utilizar solues de acessico o ca co bilidade transitrias, para que as tecnologias de apoio e os navegadores o mais antigos funcionem corretamente; 11. Utilizar tecnologias e recomendaes do W3C utilizar tecnologias do co W3C (HTML, XML, CSS, SVG, SMIL e etc.) e seguir as recomendaes co de acessibilidade; 12. Fornecer informaes de contexto e orientaes ajudar os usurios a co co a compreenderem pginas ou elementos complexos; a 13. Fornecer mecanismos de navegao claros fornecer mecanismos de navegao ca ca coerentes e sistematizados (informaes de orientao, barras de navegao, co ca ca mapa do site) de modo a aumentar a probabilidade de uma pessoa encontrar o que procura em um dado site. A existncia de mecanismos claros e e coerente importante para usurios com decincia visual ou cognitiva, e a e beneciando a todos os usurios; a 14. Assegurar clareza e simplicidade dos documentos assegurar a produo ca de documentos claros e simples, para que sejam mais fceis de compreena der. Deve-se tambm utilizar a linguagem mais clara e simples poss e vel, adequada ao contedo do site. u
Conforme mencionado anteriormente, cada diretriz possui pontos de vericao que por sua vez possui os n ca veis de prioridade. De acordo com a classicao, existem 3 n ca veis de prioridade: Prioridade 1 pontos que os criadores de contedo Web tm absolutamente de u e satisfazer para evitar que usurios quem impossibilitados de compreender a as informaes contidas na pgina ou site; co a Prioridade 2 pontos que os criadores de contedo para a Web devem satisfazer u para evitar que os usurios tenham diculdade de acessar as informaes a co contidas no documento, evitando barreiras signicativas a documentos publicados na Web; 226
Prioridade 3 pontos que os criadores de contedo na Web podem satisfazer u para melhorar o acesso as informaes disponibilizadas nas pginas ou co a sites. Na vericao da acessibilidade de um documento so estabelecidos os n ca a veis de conformidade para as pginas ou sites na Web: a N vel de conformidade A quando satisfeitos todos os pontos de vericao ca de prioridade 1; N vel de conformidade Duplo A quando satisfeitos todos os pontos de vericao de prioridade 1 e 2; ca N vel de conformidade Triplo A quando satisfeitos todos os pontos de vericao de prioridade 1, 2 e 3. ca
21.3
Tcnicas de avaliao de acessibilidade e ca
As avaliaes e validaes so especicadas num documento do W3C chamado co co a Evaluating Web Sites Accessibility, onde so apresentados dois mtodos de a e avaliao de acessibilidade: Avaliao de Preliminar de Acessibilidade (idenca ca ticao de forma rpida dos problemas gerais de acessibilidade num site) e ca a Avaliao de Conformidade (vericao do grau de conformidade de um site ca ca com os padres de acessibilidade, WCAG. Este mtodo identica problemas de o e acessibilidade mais espec cos num site). A avaliao e validao da acessibilidade so feitas por meio de ferramentas ca ca a automticas ou da reviso direta manual. Os mtodos automticos so gerala a e a a mente rpidos, mas no so capazes de identicar todos os aspectos da acessia a a bilidade. Esses mtodos no so capazes de avaliar contedo gerado dinamicae a a u mente. A avaliao humana pode ajudar a garantir a clareza da linguagem e a ca facilidade de navegao. ca Para a validao automtica da acessibilidade de uma pgina ou de um ca a a site podemos utilizar as ferramentas ou servios de anlise da acessibilidade e c a compatibilidade, como Bobby, o validador par HTML 4 do W3C e o TAW. O ideal a combinao dos mtodos manuais e automticos. e ca e a A avaliao e validao da acessibilidade de uma pgina ou de um site ` ca ca a a Web devem estar presentes desde as fases iniciais do desenvolvimento do documento. O W3C-WAI aponta como mtodo para testar uma pgina ou site, e a aps a implementao dos princ o ca pios de acessibilidade, os seguintes pontos de vericao: ca 1. Utilizar uma ferramenta de acessibilidade automtica e ferramentas de a validao de navegadores; ca 2. Validar a sintaxe (HTML, XML, etc.); 3. Validar as folhas de estilo; 4. Utilizar um navegador s de texto ou um emulador; o 5. Utilizar vrios navegadores grcos com o som e os grcos ativos, sem a a a grcos, sem mouse e sem carregar frames, programas interpretveis, fola a has de estilo ou applets; 227
6. Utilizar vrios navegadores, antigos e recentes; a 7. Utilizar um navegador de emisso automtica de falas, com leitores de a a tela, com software de aplicao, monitores monocromticos, etc; ca a 8. Utilizar corretores ortogrcos e gramaticais; a 9. Rever o documento, vericando a clareza e a simplicidade; 10. Validar pginas com usurios reais. a a Acessibilidade e usabilidade so conceitos que se inter-relacionam, pois ama bos buscam a ecincia e eccia no uso de uma interface. A observao de e a ca alguns critrios ou fatores a serem ressaltados na elaborao de uma pgina e ca a Web pode auxiliar na concepo de bons projetos de interface e conseqenteca u mente, melhorar a qualidade da interao do usurio com a aplicao. ca a ca
228
Cap tulo 22
Padres Web W3C o

Padres Web (Web Standards ou Tableless) um conjunto de normas, diretrizes, o e recomendaes, notas, artigos, tutoriais e ans de carter tcnico, produzidos co a e pelo W3C e destinados a orientar fabricantes, desenvolvedores e projetistas para o uso de prticas que possibilitem a criao de uma Web acess a ca vel a todos, ajudados por diversos recursos que fazem uma Web mais agradvel de usar. a Toda essa padronizao para atender a idia da Web Semntica que ca e e a consiste organizar os documentos Web de tal forma, que estes possam ser interpretados automaticamente, facilitando a pesquisa e cruzamento das informaes co dos documentos. Ou seja, alm da informao, a mquina saberia distinguir a e ca a que se refere esta informao. Um exemplo prtico disso que, se utilizssemos ca a e a o elemento address para denir os endereos em nosso site, uma ferramenta c de busca poderia criar uma indexao destes endereos, e disponibilizar para o ca c usurio. Quantas vezes voc visitou o site de uma empresa e cansou de procurar a e pelo endereo, ou um telefone de atendimento ao cliente? A Web Semntica no c a a uma substituio a Web atual, mas sim uma extenso da atual. E a base da e ca a Web Semntica o XML, o RDF e a Ontologia. a e Existem diversas vantagens na aplicao dos padres Web. Entre elas, vale ca o destacar: Acessibilidade tanto para decientes quanto para usurios de dispositivos a mveis como PDAs, celulares, smartphones, etc.; O browser interpreta as o informaes de layout (em um arquivo CSS) de 30% a 70% mais rapidaco mente, o que gera uma queda considervel no download dos arquivos do a site; Economia de banda na transmisso dos arquivos, pois com a utilizao dos a ca padres os arquivos possuem menor tamanho; O cdigo HTML se torna o o muito mais compacto ao se separar contedo, design e programao; u ca Melhor visibilidade no Google e nos demais mecanismos de busca, pois os padres utilizam a estrutura semntica simples do HTML; o a Maior facilidade de atualizao e mudanas no layout. ca c Algumas tecnologias padronizadas pelo W3C:
229
HTML (Hyper Text Markup Language) E uma linguagem de marcao ca de tags utilizada para produzir pginas na Web. A ultima recomendao a ca lanada pelo W3C foi a HTML 4.01; c XHTML (Extensible Hyper Text Markup Language E uma reformulao ca da linguagem de marcao HTML baseada em XML. Combina as tags de ca marcao do HTML com as regras do XML. Esta reformulao tem em ca ca vista a exibio de pginas Web em diversos dispositivos (televiso, palm, ca a a celular). A inteno desta linguagem melhorar a acessibilidade. A ultima ca e recomendao lanada pelo W3C foi XHTML 1.0; ca c XML (Extensible Markup Language) E uma linguagem de marcao aproca priada para representaao de dados, documentos e demais entidades cuja c essncia fundamenta-se na capacidade de agregar informaes. A ultima e co recomendao lanada pelo W3C foi XML 1.0; ca c CSS (Cascading Style Sheets) E uma linguagem de estilo utilizada para denir a apresentao de documentos escritos em uma linguagem de marcao, ca ca como HTML ou XML. Seu principal benef prover a separao entre o cio e ca formato e o contedo de um documento. A ultima recomendao lanada u ca c pelo W3C foi CSS 3; XSL (Extensible Markup Language E uma linguagem que dene as folhas de estilo padro para o XML. E constitu de trs partes: XSLT (lina da e guagem de transformaao de documentos XML), XPath (linguagem para c navegao em documentos XML) e XSL-FO (linguagem para formatao ca ca de documentos XML). A ultima recomendao lanada pelo W3C foi XSL ca c 1.0, XSLT 2.0 e XSL-FO; XSLT (XSL Transformations) E uma linguagem de marcao XML usada ca para transformar documentos XML. Esta linguagem possibilita mais transformaes mais potentes do que as folhas de estilo CSS; co XPath (XML Path) E uma linguagem para encontrar informaes em um co documento XML. O XPath utilizado para navegar atravs de atributos e e e elementos em um documento XML. E o principal elemento no padro a XSLT; XQuery (XML Query) E uma linguagem utilizada para executar consultas em dados XML. A ultima recomendao lanada pelo W3C foi XQuery ca c 1.0; DOM (Document Object Model) E uma especicao do W3C, indepenca dente de linguagem e plataforma, onde se pode alterar e editar a estrutura de um documento. Com o DOM poss acessar elementos de um doce vel umento, e poder trabalhar com cada um desses elementos separadamente, possibilitando a criao de pginas altamente dinmicas. A ultima reca a a comendao lanada pelo W3C foi DOM Level 3; ca c SOAP (Simple Object Acess Protocol) E um protocolo de comunicao ca simples baseado em XML para troca de informaes entre aplicaes. A co co especicao do SOAP prov maneiras para construir mensagens que posca e sam trafegar por meio de diversos protocolos de forma independente da 230
linguagem de programao e do sistema operacional. Normalmente, o proca tocolo utilizado para troca de informaes o HTTP, pois este no possui co e a problema de segurana com rewalls e proxy. Ou seja, o http por ser um c protocolo da Internet no bloqueado pelos rewalls e proxy. A ultima a e recomendao lanada pelo W3C foi SOAP 1.2; ca c WSDL (Web Services Description Language) E uma linguagem baseada em XML para descrio de Web Services e como acess-los. A ultima ca a recomendao lanada pelo W3C foi WSDL 1.1; ca c RDF (Resource Description Framework) E uma linguagem para representar informaes na Web. O RDF usa notao XML como sintaxe de co ca codicao para descriao de metadados. A idia do RDF a descrio ca c e e ca dos dados e dos metadados em trs componentes: recurso (qualquer objeto e que identicvel unicamente por um URI), propriedade ( uma carace a e ter stica, um atributo ou relacionamento espec co de um recurso) e valor, e uma forma coerente de acesso aos padres de metadados (namespace) o publicados na Web. Um dos benef cios do RDF permitir que aplicaes e co possam agir de forma inteligente e automatizada sobre as informaes co publicadas na Web. A ultima recomendao lanada pelo W3C foi RDF ca c 1.0; OWL (Web Ontology Language) E uma linguagem para denir e instanciar ontologias na Web. Uma ontologia OWL pode incluir descries de co classes e suas respectivas propriedades e relacionamentos. A OWL foi projetada para aplicaes que precisam processar o contedo da informao co u ca ao invs de apresent-la aos humanos. Ela fornece um vocabulrio adie a a cional com uma semntica formal que facilita muito mais a interpretao a ca do contedo da Web do o XML. A OWL foi baseada nas linguagens OIL u e DAML+OIL, e possui trs sublinguagens: OWL LITE, OWL DL, OWL e FULL. A ultima recomendao lanada pelo W3C foi OWL 1.0; ca c 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 multim no so inseridos, apenas referenciados. O SMIL permite a criao dia a a ca de apresentaes audiovisuais interativas, e utilizado em apresentaes co e co multim dias do tipo rich media, que integram udio e v a deo streaming, texto ou qualquer outro tipo de arquivo. O SMIL permite gerenciar a transmisso de arquivos multim a dia por streaming, sincronizar estes arquivos com animaes ash, pginas HTML, etc., e criar uma espcie de co a e indexao destes arquivos de udio e v ca a deo. Uma grande vantagem do SMIL que ele utilizado pelos players mutim e dia Real Player QuickTime. A ultima recomendao lanada pelo W3C foi SMIL 2.1. ca c O W3C estabelece uma srie de recomendaes para utilizar essas tecnoloe co gias. Esses padres so conhecidos como Padres W3C ou Recomendaes W3C. o a o co Observaes: co 1. Um namespace (NS) dene um vocabulrio controlado que identica um a conjunto de conceitos de forma unica para que no haja ambigidade na a u
231
sua interpretao. Os namespaces XML so conjuntos de tipos de elemenca a tos e atributos poss veis 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 repositrio compartilhado, e noo a amb guo, onde usurios e programas de validao de cdigo XML podem a ca o consultar a sintaxe e propriedades semnticas dos conceitos cobertos; a 2. URI (Uniform Resource Identier) uma cadeia de caracteres que identie ca um recurso da internet. O URI mais comum o URL que identica e um endereo de dom c nio, mas os URIs podem tambm identicar livros, e elementos de uma pgina e pessoas individuais, por exemplo; a 3. Uma Ontologia fornece uma conceituao (meta-informao) que descreve ca ca a semntica dos objetos, as propriedades dos objetos e as relaes exisa co tentes entre eles num dado dom nio do conhecimento. As Ontologias so a desenvolvidas para fornecer um n semntico ` informao de um dado vel a a ca dom nio de forma torn-la processvel por mquinas e comunicvel ena a a a tre diferentes agentes (software e pessoas). As ontologias so utilizadas a na Inteligncia Articial, Web Semntica, Engenharia de Software e Are a quitetura da Informao como uma forma de representao de conhecica ca mento do mundo ou alguma parte dele. So elementos da Ontologia: Ina div duos (instncias) que incluem objetos concretos ou abstratos, Classes a (conceitos) que so grupos abstratos (por exemplo, Pessoa, a classe para a todas as pessoas), Atributos que armazenam informaes do objeto (pelo co menos um nome e um valor), e Relacionamento que so as formas como a os objetos se relacionam com os outros objetos;
232
Cap tulo 23
XML
23.1 O que XML? e
Extensible Markup Language (XML) uma linguagem de marcao (utilizao e ca ca de tags) para descrever os dados de pginas Web de forma estruturada. O a XML um dos padres adotado pelo W3C e foi projetado para descrever o e o contedo de uma pgina Web em vez da sua formatao. O XML derivado da u a ca e linguagem SGML (Standard Generalized Markup Language), que um padro e a internacional para denio de formatos de representao de documentos. O ca ca SGML muito mais complexo de se implementar do que o XML. A gura 23.1 e mostra um exemplo de uma pgina Web em XML. a Como o XML trata apenas do contedo do documento, existem diversos u padres para descrever o formato da apresentao dos dados. Uma das formas o ca de apresentar tais documentos por meio das folhas de estilo. As principais e linguagens de estilo so o CSS (Cascading Style Sheets) e o XSL (Extensible a Style Sheets). Ento, a apresentao dos dados car a cargo dessas linguagens. a ca a
Figura 23.1: Uma pgina Web simples em XML a
233
23.2
Caracter sticas do XML
Algumas caracter sticas do XML: E uma linguagem de representao de documentos e no uma linguagem ca a de programao; ca Facilita a gerao de dados, a leitura de dados e assegura que a estrutura ca de dados no amb a e gua; E extens e independente de plataforma; vel E modular, pois a permite a denio de um novo formato de documento ca pela combinao e reuso de outros formatos; ca No possui tags pr-denidas, e permite um nmero innito de tags; a e u Estruturas de dados podem ser agrupadas em profundidade innita; Pode ser descrita por grafos com ns e rtulos, possibilitando que algorito o mos conhecidos possam ser utilizados para a recuperao ou localizao ca ca de dados.
23.3
Comparao entre XML e HTML ca
O XML e o HTML so primos. O XML no veio para substituir o HTML. Eles a a derivam da mesma linguagem, o SGML. A grande diferena entre o HTML e c o XML que o HTML descreve como os dados devem ser apresentados (fore matao dos dados) numa pgina Web enquanto o XML descreve os dados ca a (contedo) de uma pgina Web. u a Ambos fazem o uso de tags (palavras delimitadas por < e >) e atributos. Enquanto o HTML especica o que cada tag e atributo signicam e frequentemente como o texto entre elas aparece num browser, o XML usa as tags somente para delimitar as pores de dados, e deixa a interpretao dos dados para a co ca aplicao que ir ler este dado. Por exemplo, enquanto em um documento ca a HTML uma tag p indica um pargrafo, no XML essa tag pode denotar um a preo, um parmetro, uma pessoa, etc. c a Enquanto ao uso das tags nas duas linguagens, O XML as tags no so a a pr-denidas e pode-se usar um nmero innito de tags. O HTML isso no e u a e poss vel. Os arquivos XML so arquivos textos, e no so destinados ` leitura por a a a a um ser humano como o HTML . Isso ca a cargo de outras linguagens. As e especicaes de XML so muito mais r co a gidas que a especicao do HTML. ca Elas estabelecem que obrigatrio rejeitar sintaticamente arquivos incorretos, e o mesmo que o navegador possa descobrir o que o Web designer pretendia. Os navegadores s tm permisso para indicar o erro. o e a
23.4
Sintaxe bsica do XML a
O componente bsico no XML o elemento, que composto pela uma tag a e e inicial, pelo contedo e pela uma tag nal. A expresso book chamada de u a e 234
tag inicial (comea com e termina com ) e /book chamada de tag nal c e (comea com / e termina com ). Estas marcaes so denidas pelo usurio. c co a a A estrutura ou o texto entre as tags iniciais e nais chamado de contedo. As e u tags no XML so case sensitive. a Os elementos podem incluir outros elementos (ditos elementos lhos) e textos. No exemplo da gura 23.1, bookl ist o elemento raiz e o book o elemento e e lho. Usam-se elementos repetidos com a mesma tag (book) para representar colees de dados, gura 23.1. co Um elemento pode no ter qualquer contedo. Este tipo de elemento a u e designado por elemento vazio, por exemplo, o elemento \ <gura path=... > que marca onde deve ser inserido uma gura. Os elementos vazios possuem uma sintaxe diferente, inicia-se por < e termina em >, que a forma abreviada de e escrever <elem-ident> <elem-ident>. No permitida a utilizao de espao a e ca c em branco no nome dos elementos. O nome dos elementos pode comear somente c com letras, underscore ou dois pontos. A linguagem XML permite associar atributos aos elementos. Os atributos so utilizados para especicar as propriedades ou caracter a sticas do elemento. O atributo denido como um par (nome, valor) separado por um sinal de e igual (=) e sempre aparecem na tag inicial. Assim como nas tags, o usurio a pode denir tambm os atributos. O valor do atributo sempre um conjunto e e de caracteres que deve estar entre aspas. Por exemplo: <disciplina cod="cop025"> Tcnicas de programa~o</disciplina> e ca Neste exemplo, cod=3cop025 um atributo do elemento <disciplina>. e Cada atributo de um elemento pode ser especicado somente uma vez.O XML dene apenas dois atributos como reservado: xml:lang e xml:space. Uma observao importante a ser feita a respeito de elemento e atributo ca e que no existe uma fronteira entre os dois, gura 23.2. A representao (b) est a ca a correta, mas muito mais dif de processar. e cil
Figura 23.2: Representaes diferentes de uma estrutura em XML co Algumas regras bsicas devem ser lembradas na construo de um docua ca mento XML: 235
O documento deve ter sempre uma declarao XML no in ca cio (<?xml version=1.0?>); O documento deve incluir um ou mais elementos o primeiro elemento, que delimitar todo o corpo do documento, o elemento raiz e todos os a e outros devero estar inclu a dos dentro dele; Todos os elementos dever ter uma tag de in e outra de m; cio 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 so: a Instruo de processamento mecanismo que permite a insero de informaes ca ca co expl citas em um documento destinadas a uma aplicao. Os interpreca tadores XML no interpretam essas informaes, mas simplesmente as a co repassam para a aplicao. A instruo de processamento no faz parte ca ca a do contedo do documento; u Sintaxe: <? ?>
Exemplo: <?html action="hr"?> Declarao XML um tipo de instruo de processamento. Qualquer docca e ca umento XML dever comear sempre com uma declarao XML. Norc ca malmente, se contiver algo antes da declarao ou se estiver ausente, a ca aplicao acusar erro. Existem trs tipos de atributos para a declarao: ca a e ca version (Obrigatrio e indica a verso do XML utilizado, 1.0), stano a dalone (Opcional e indica se o documento est autocontido. Aceita os a valores yescaso o documento no tenha referncias a entidade externa e a e nocaso contrrio.), encoding (Opcional e indica qual codicao usada a ca para os caracteres. O valor para caractere portugus isso-8859-1); e e
Sintaxe: <?xml Exemplo: <?xml version="1.0" standalone="yes" encoding="UCS-2" ?> Comentrios utilizado para indicar que o contedo a seguir no para ser a u a e processado; Sintaxe: 236 ?>
<!-Exemplo:
-->
 e a Elementos explicado anteriormente; Atributos explicado anteriormente; CDATA utilizado quando se deseja que os caracteres de texto no sejam cona fundidos com os elementos de marcao, por exemplo o uso do sinal < e ca >; Sintaxe: <![CDATA[ ... ]]> Exemplo: <![CDATA[Imprima a tecla <<ENTER>>]]> PCDATA (Parser Character Data) utilizado para designar que o texto entre as duas marcaes um dado e no um texto. Isso utilizado na co e a e denio das DTDs ou gramtica do documento; ca a Referncias poss associar identicadores unicos aos elementos, por meio e e vel de um atributo de identicao, id. Com isto permite-se que elementos ca distintos referenciem-se entre si; Exemplo: <biblio id="bib" ano="2001"> ... </biblio>
Entidade identica um conjunto de informao por um nome. As entidades ca podem ser associar a textos e cheiros. O XML possui cinco entidades pr-denidas: &lt (<), &gt (>), &amp (&), &apos () e &quot (); e
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 vericao sinttica de um documento XML feita por parsers que analca a e isam um documento e enviam mensagens de erro ao detectar erros de sintaxe. Existem dois tipos de parser: o paser validador, que verica se um documento e bem formado, e o parser no validador, que verica se um documento vlido. a e a Um documento XML bem formado quando obedece a sintaxe XML, e um doce umento XML vlido quando obedece a uma gramtica especicada por uma e a a DTD. Pode-se dizer que um documento vlido um documento bem formatado, a e mas o contrrio no. a a
23.6
NameSpaces
Como os nomes dos elementos em XML no esto pr-denidos, pode ocorrer a a e um conito 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 gura 23.3.
Figura 23.3: Diferentes documentos XML com mesmo nome de elemento O NameSpace um padro denido pelo W3C e basicamente utilizado e a e para resolver conitos de nomes usados nos documentos XML. A resoluo de ca conitos pode ser feita por meio do uso de prexos ou de namespaces. No uso de prexos, basta o usurio denir um nome diferente para seus a elementos < table >, por exemplo, < h : table > e < f : table >. Usando o prexo, criam-se dois tipos diferentes de elementos do tipo < table >. Para denir/criar um namespace o usurio deve denir o atributo xmlns a (XML NameSpace) a tag inicial de um elemento no documento XML com a sintaxe xmlns:namespace-prex =namespace. Quando o namespace denido e a tag inicial do elemento, todos os elementos lhos com o mesmo prexo so a associados com o mesmo namespace. O atributo xmlns pode ser utilizado em qualquer elemento e no apenas no n raiz. A gura 23.4 mostra alguns exemplos a o de namespace e a Ilustrao 6 mostra a utilizao de namespace em vez de ca ca prexo para o exemplo da gura 23.3. Pode-se perceber pela gura 23.4.(a) que a string identicadora de um namespace grande para ser manipulada diretamente. Para que sua utilizao e ca
238
Figura 23.4: Declarao de namespace ca
Figura 23.5: Exemplo de utilizao de namespace ca seja vivel, utiliza-se um prexo, uma espcie de abreviatura para os namesa e paces. De acordo com a gura 23.4.(b) os prexos seriam catalogo, encomenda e jcr. A especicao de namespaces da W3C estabelece que o namespace deve ter ca um URI para garantir a unicidade dos nomes dos elementos. Note que o endereo usado para identicar o namespace no usado pelo c a e parser para buscar informaao. O unico propsito dar ao namespace um c o e nome unico. Entretanto, comum usar o namespace como um ponteiro para e uma pgina Web real contendo informaes sobre o namespace. Por exemplo, a co a gura 23.5 mostra a declarao de namespaces distintos para especicar onde ca so buscados os dados da denio de elementos com o mesmo nome, no caso < a ca table >. Os namespaces so tambm utilizados em denies de XML Schema, a e co XSL e RDF.
23.7
Gramtica de um documento XML a
Algumas vezes existe a necessidade de denir os elementos que podem aparecer em um documento XML, o contedos destes, e os atributos que podem estar u associados aos elementos. Tambm, existe a necessidade de denir a estrutura e do documento especicando, por exemplo, quais so os subelementos de um a elemento e a seqncia que eles devem aparecer. A primeira linguagem proposta ue
239
para a denio dessas regras nos documentos XML foi a DTD (Document Type ca Denition). Existem quatro tipos de declaraes que podem ser utilizadas em um DTD: co elementos, atributos, entidades e instrues de processamento. As entidades co esto relacionas com a organizao f a ca sica do documento XML, as instrues de co processamento foram explicadas anteriormente, os elementos so denidos pela a palavra-chave ELEMENT e a lista de atributos de cada elemento denida pela e palavra-chave ATTLIST. As principais declaraes que ocorrem em um DTD co so de elementos e de atributos. a As declaraes de elementos especicam como deve ser o contedo do eleco u mento. As seguintes declaraoes podem ser feitas: c Denir a seqncia em os subelementos de um elemento devem aparecer: ue (a, b) Sintaxe: <!ELEMENT nome_elemento (seq^ncia de subelemento separados por vrgula na ue ordem que devem aparecer)> Exemplo: <!ELEMENT biblio (ttulo, autor, tipo_pub)> Denir elementos vazios: constante EMPTY Exemplo: <!ELEMENT image EMPTY> Denir a ocorrncia repetida de um elemento em particular: e Pelo menos uma vez: (elemento)+ Exemplo: <!ELEMENT biblio (titulo, autor+, tipo_pub)> Zero ou mais vezes: (elemento)* Exemplo: <!ELEMENT tabela_biblio (biblio*)> Denir que o elemento deve ser um entre uma lista de elementos: (a|b) Exemplo:
<!ELEMENT tipo_pub (periodico | evento)> Obs.: O elemento tipop ub composto por um elemento periodico ou e evento. Denir que o elemento tem presena opcional: (elemento)? Exemplo: c <!ELEMENT biblio (titulo, autor, tipo_pub, resumo?)> Denir que o elemento uma string de caracteres: #P CDAT A Exemplo: e <!ELEMENT autor (#PCDATA)> 240
Denir elementos livres: constante ANY. Exemplo: <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT doc (para)+> nome (#PCDATA)> lugar (#PCDATA)> data (#PCDATA)> para ANY>
Obs: O elemento para est denido como sendo de contedo ANY, ou seja, a u pode ser texto com elementos nome, lugar e data pelo meio (< para >Tudo aconteceu em < lugar > Braga < /lugar > ... < /para >). A gura 23.6 mostra o documento XML que descreve uma agenda e a gura 23.7 mostra as especicaes do documento DTD. co
Figura 23.6: Documento XML contendo a descrio de uma agenda ca
Figura 23.7: Conjunto de declaraes para o XML que descreve a agenda co
241
As declaraes de atributo servem para especicar o nome, o tipo de dado co associado ao atributo e opcionalmente especicar se h algum valor padro de a a 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 declaraes de tipo de atributo podem ser feitas: co 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 poss veis: Exemplo: <!ATTLIST tipo_pub abrange (regional | nacional | internacional)> Valor do atributo signica um identicador do elemento ao qual est asa sociado: ID Exemplo: <!ATTLIST biblio ident ID> Obs.: Cada elemento que possui o atributo ID deve ter um unico atributo ID e para cada elemento o valor ID deve ser diferente. Valor do atributo signica um nome de identicador referencivel: IDREF a Exemplo: <!ATTLIST biblio refer IDREFS> Obs.: Quando da ocorrncia de atributo com mltiplos valores do tipo e u IDREF, utiliza-se a declarao IDREFS. Usa-se o IDREF para implemenca tar relaes entre elementos. co Opcionalmente poss e vel estabelecer se a presena de um atributo obric e gatria, opcional ou se assume um valor padro. As seguintes declaraes so o a co a poss veis: Declarar que a presena do atributo obrigatria: #REQU IRED aps c e o o a declarao do tipo de atributo ca Exemplo: <!ATTLIST biblio ano CDATA #REQUIRED local CDATA> Declarar que a presena do atributo opcional: #IM P LIED aps a c e o declarao do tipo de atributo ca Exemplo: 242
<!ATTLIST biblio ano CDATA #REQUIRED local CDATA #IMPLIED> Especicar um valor padro quando o valor do atributo deve ser escolhido a entre uma lista de valores: Exemplo: <!ATTLIST aula tipo (teoria | exemplo | exerccio) "teoria"> Declarar que a presena do atributo xa: #F IXED aps a declarao c e o ca do tipo de atributo e seu valor ser o que estiver a frente da palavra a #F IXED. Exemplo: <!ATTLIST data tipo CDATA #FIXED "data"> Obs.: 1. O atributo a ser denido como #F IXED constante e imutvel. e a 2. Denio de uma entidade paramtrica (somente no DTD): ca e <!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 especicaes de um esquema, este co documento chamado de documento vlido. Para que o interpretador XML e a possa validar um documento XML quanto a sua gramtica necessrio associar a e a o DTD ao documento XML. Esta associao, que especicada no in ca e cio do documento DTD, pode ser feita tanto de forma interna quanto de forma externa. Na forma interna, as declaraes DTD so colocadas explicitamente no arco a quivo XML, atravs da sintaxe: e <!DOCTYPE nome_DTD [declara~es da DTD]> co Exemplo:
Figura 23.8: Associaao entre o XML e o DTD na forma interna c Na forma externa, a associao feita no documento XML por meio da ca e 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 declarao indica que o elemento raiz do documento agenda e que ca e o DTD pode ser encontrado no sistema no arquivo agenda.dtd. A declarao DOCTYPE no pode aparecer livremente num documento ca a XML. Ela deve aparecer sempre aps a declarao XML e antes do elemento o ca raiz, gura 23.9.
Figura 23.9: Posio da declarao DOCTYPE ca ca Pelas declaraes bsicas que uma DTD pode utilizar, observa-se que os tipos co a de dados que podem ser declarados so de certa forma limitados. Para ampliar a as possibilidades de se denir tipos de dados, outro tipo de esquema foi denido pelo W3C denominado XML Schema ou XSD (XML Schema Denition).
23.8
Tecnologias XML
A seguir so apresentadas as tecnologias relacionadas ao XML: a XHTML (Extensible HTML) uma verso expl e a cita do HTML; XML DOM (XML Document Object Model) dene um padro de acesso a e manipulao de documentos XML; ca XSL (Extensible Style Sheet Language) consiste de trs partes: XSLT, e XPath e XML-FO; XSLT (XSL Transformation) usado para transformar documentos XML e em outros formatos, como XHTML; XPath uma linguagem para navegao em documentos XML; e ca
XSL-FO (XSL Formatting Object) uma linguagem para formatao de e ca documentos XML; XLink (XML Linking Language) uma linguagem para criar hyperlinks e em documentos XML; XPointer(XML Pointer Language) permite os hyperlinks XLink apontar para partes espec cas de um documento XML; DTD (Document Type Description) usado para denir a gramtica de e a um documento XML; XSD (XML Schema Denition) baseado em XML alternativo ao DTD; e 244
XForms (XML Forms) usa XML para denir a forma dos dados; XQuery (XML Query Language) usado para consultar dados em XML; e SOAP (Simple Object Access Protocol) um protocolo em XML que pere mite as aplicaes trocarem informaes sobre o protocolo http; co co WSDL (Web Services Description Language) uma linguagem baseada e em XML para descrever web services; RDF (Resource Description FrameWork) uma linguagem baseada em e XML para descrever recursos da Web; RSS (Really Simple Syndication) um formato para indicar not e cias e contedos u novos de um site; WAP (Wireless Application Protocol) foi desenvolvido para mostrar contedo u para cliente wireless, como celulares; SMIL (Syncronized Multimedia Integration Language) uma linguagem e para descrever apresentaes audiovisuais; co SVG (Scalable Vector Graphics) dene formatos grcos em XM. a A gura 23.10 mostra como algumas dessas tecnologias interagem com a linguagem XML.
Figura 23.10: Interao entre as tecnologias XML ca
23.9
Benef cios da linguagem XML
Os principais objetivos da linguagem XML: Buscas mais eciente; Desenvolvimento de aplicaes ex co veis para a Web; 245
Integrao de dados de fontes diferentes; ca Computao e manipulao local; ca ca Mltiplas formas de visualizar os dados; u Atualizao granulares dos documentos; ca Fcil distribuio na Web; a ca Escalabilidade; Compreenso. a
23.10
Parsers:
Ferramentas de desenvolvimento
Expat; XML4J; MSXML; Editores: Editores de texto comum; Xeena;
246
Cap tulo 24
XSLT
Uma das principais idias de XML deixar expl e e cita a separao entre contedo, ca u estrutura e apresentao de um documento para Web. Como XML trata apenas ca do contedo dos documentos, devem existir outros padres para descrever o u o formato de apresentao dos dados. Uma das formas de permitir apresentao ca ca de tais documentos por meio das folhas de estilo. e Linguagens de folhas de estilo (style sheets) foram projetadas para permitir que a descrio de estilo de apresentao de documentos seja separada da ca ca representao do contedo dos documentos. Isto facilita a reutilizao de um ca u ca mesmo documento para diferentes aplicaes ou diferentes tipos de usurios co a que requerem diferentes vises do mesmo. O princ o pio bsico destas linguaa gens prover uma sintaxe que permita associar partes espec e cas do contedo u de documentos a estilos ou aes que devem ser realizadas sobre tais partes. co As principais linguagens de estilo so a CSS (Cascading Style Sheets) e XSL a (Extensible Style Sheet).
24.1
O que uma folha de estilo? e
Quando um site Web complexo e consiste de muitas pginas produzidas por e a vrios autores que trabalham na mesma empresa, frequentemente interessante a e ter um meio de impedir que diferentes pginas tenham uma aparncia distinta. a e Esse problema pode ser resolvido usando-se folhas de estilo. Quando as folhas de estilo so utilizadas, as pginas individuais deixam de a a usar estilos f sicos, como negrito e itlico. Em vez disso, os desenvolvedores a utilizam estilos prprios como < dn > (denio), < em > (nfase fraca), o ca e < strong > (nfase forte) e < var > (variveis). Os estilos lgicos so denidos e a o a na folha de estilo, referida no in de cada pgina. Uma folha de estilo pode cio a ser comparada a um arquivo #include em um programa C: a mudana em uma c unica denio de macro provoca a alterao em todos os arquivos de programa ca ca que incluem o cabealho. c
24.2
Comparao entre o CSS e XSL ca
A semelhana entre as essas duas folhas de estilo, CSS e XSL, est em ambas c a podem ser usadas em documentos XML, mas o CSS no transforma documentos. a 247
Essa possibilidade est reservada somente ao XSL. XSL mais poderoso que a e o CSS, pois suporta transformaes do documento antes de sua exibio. Por co ca outro lado, o XSL no pode ser usado em linguagens HTML. a Desta forma essas duas linguagens completam-se uma ` outra e podem ser a utilizadas simultaneamente. A utilidade do XSL mais percept e vel, quando, por exemplo, necessria a ordenao dos dados antes de serem exibidos. e a ca
24.3
O que o XSL? e
O XSL uma linguagem para descrever folhas de estilo para documentos XML. e E composta por trs linguagens descendentes de XML: e XSLT (XSL Transformation) linguagem para transformar documentos XML; XPath linguagem para denir parte de um documento XML; XSL-FO (XSL Formatting Object) linguagem para formatar documentos XML. A componente mais importante do XSL o XSLT. e
24.4
O que o XSLT? e
O XSLT a parte do XSL usada para transformar um documento XML em e outro documento XML, ou em outro tipo de documento (tx, pdf, rtf, HTML, XHTML, etc.). O XSLT utiliza o XPath para encontrar informaes nos docco umentos XML. XPath usado para navegar atravs dos elementos e atributos e e nos documentos XML. O XSLT dene um conjunto de regras de transformao que sero aplicadas ca a a um documento XML (rvore fonte) para produzir outro documento XML a (rvore resultado). Nesse processo de transformao, o XSLT utiliza o XPath a ca para denir partes do documento de origem (fonte) que combinem com um ou mais templates pr-denidos. Quando uma combinao encontrada, o XSLT e ca e transforma essas partes do documento de origem no documento de resultado. As partes do documento de origem que no so combinadas com o template a a permanecero sem modicaes no documento de resultado. a co O XSLT permite:
Adicionar texto ao contedo de elementos; u Remover, criar, alterar e ordenar os contedos dos elementos; u Converter contedo de elementos para valores de atributos, ou vice-versa; u Alterar a ordem dos elementos; Substituir elementos por novos elementos.
248
24.5
Caracter sticas do XSLT
Algumas caracter sticas do XSLT: E uma linguagem declarativa descreve a transformao desejada, ao ca invs de prover uma seqncia de instrues procedurais; e ue co E essencialmente uma ferramentapara transformar documentos XML; Manipula rvores; a Uso de XSL NameSpaces o W3C prov um namespace para as tags XSL. e
24.6
Declarando um documento XSL
Como o XSL obedece a mesma sintaxe do XML, quando se cria uma especicao de folha de estilo XSL, deve-se incluir a instruo de processamento (por ca ca exemplo, <?xml version=1.0standalone=yesencoding=UCS-2?>) para arquivos XML no in cio do arquivo que descreve a folha de estilo. Os arquivos XSL tem extenso .xsl. A gura 24.1 mostra um exemplo de um arquivo XSL. a
Figura 24.1: Declarao de uma folha de estilo XSL ca O elemento raiz que declara um documento ser uma folha de estilo XSL o elemento <xsl:stylesheet> ou <xsl:transform>. Esses dois elementos so e a sinnimos e so as tags mais externas de um documento XSL. o a 249
O modo correto de declarar uma folha de estilo XSL de acordo com a recomendao W3C XSLT: ca <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 caracter stica do XSLT, devese declarar o namespace XSLT no in do documento; cio 2. O xmlns:xsl=http://www.w3.org/1999/XSL/Transformidentica a Recomendao NameSpace ocial do W3C. Caso utilize este namespace, deve ca incluir o atributo version=1.0. O restante da declarao na folha de estilo XSL referente a como transforca e mar o documento XML. Essa transformao realizada utilizando os principais ca e elementos XSLT: < xsl : template >; < xsl : value of >; < xsl : f or each >; < xsl : sort >; < xsl : if >; < xsl : choose >; < xsl : apply templates >. Aps a denio do arquivo XSL preciso associar este arquivo no docuo ca e mento XML. A instruo que deve ser inclu no documento XML para que o ca da interpretador XML faa uso da folha de estilo XSL denida : c e <?xml-stylesheet type="text/xsl" href="localiza~o do arquivo.xsl"?> ca
A gura 24.2 mostra o arquivo XML com esta associao. A gura 24.1 a ca e declarao da folha de estilo para esse documento XML. A gura 24.3 mostra a ca visualizao do documento XML no browser utilizando a folha de estilo denida ca anteriormente. Ao abrir o documento XML o browser transforma o documento XML em HTML.
24.7
Elemento <xsl:template>
O elemento <xsl:template> utilizado para construir templates. Cada template e contm regras para aplicar quando um n (elemento) espec e o co combinado. e O atributo match desse elemento usado para associar um template com um e elemento XML ou denir um template para toda uma seo de um documento ca 250
Figura 24.2: Documento XML com linkpara a folha de estilo XSL
Figura 24.3: Visualizao do arquivo XML no browser ca 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 uma expresso XPath. e a A gura 24.1 mostra um exemplo do uso do elemento <xsl:template>.
24.8
Elemento <xsl:value-of>
O elemento <xsl:value-of> usado para extrair o valor de um elemento no e documento XML e adicion-lo ao documento resultado. O atributo select desse a elemento informa qual o elemento que ser extra o valor. O valor do atributo a do select uma expresso XPath. A gura 24.1 mostra um exemplo do uso do e a elemento <xsl:value-of>.
251
24.9
Elemento <xsl:for-each>
O elemento <xsl:for-each> permite a realizao de loops no XSLT. Esse eleca mento usado para selecionar todos os elementos XML de um determinado e tipo. O atributo select desse elemento seleciona o elemento no documento XML que ser processado. O valor desse atributo uma expresso XPath. A gura a e a 24.1 mostra um exemplo do uso do elemento <xsl:for-each>. O elemento <xsl:for-each> tambm pode ser usado para ltrar a sa de e da um documento XML. Basta acrescentar um critrio de seleo ao atributo see ca lect desse elemento. Por exemplo, <xsl:for-each select=catalog/cd[artist=Bob Dylan]>, mostra apenas que o catlogo com o nome de artista Bob Dylan a ser colocado no documento de sa a da. Os operadores de ltro so: = (igual); a != (diferente); &lt (menor que); &gt (maior que).
24.10
Elemento <xsl:sort>
O elelemento <xsl:sort> usado para ordenar a sa de um documento. Para e da ordenar a sa da, insere-se esse elemento dentro do elemento <xsl:for-each>. O atributo select desse elemento informa por qual elemento XML ocorre a ordenao. A gura 24.4 mostra o documento XML da gura 24.2 com a sa ca da ordenada pelo elemento artist.
Figura 24.4: Arquivo XSL ordenando a sa de um documento da
24.11
Elemento <xsl:if>
O elemento <xsl:if> usado para realizar testes condicionais. Para realizar e um teste condicional, basta inserir esse elemento dentro do elemento <xsl:foreach>. O atributo test contm a expresso booleana. A gura 24.5 mostra o e a documento XSL com o teste condicional, o qual seleciona apenas os cds com preos maiores que 10. c
252
Figura 24.5: Arquivo XSL com teste condicional
24.12
Elemento <xsl:choose>
O elemento <xsl:choose> usado em conjunto com os elementos <xsl:when> e e <xsl:otherwise> para expressar mltiplos testes condicionais. A mostra o uso do u elemento <xsl:choose>. Neste exemplo, os elementos cd que possui preo maior c que 10 aparecem pintados de rosa e os outros aparecem normais no documento de sa da.
Figura 24.6: Arquivo XSL com mltiplos testes condicionais u
24.13
Elemento <xsl:apply-templates>
O elemento <xsl:apply-templates> aplica um template ao elemento corrente ou aos lhos do elemento n corrente. Se adicionar o atributo select ao elemento o <xsl:apply-templates>, o template s ser aplicado aos elementos lhos que o a combinem com o valor do atributo. O valor do atributo select pode ser usado para especicar a ordem na qual os ns lhos so processados. A gura 24.7 o a mostra um exemplo com a utilizao desse elemento. A gura 24.8 mostra como ca a visualizao do documento resultado. e ca Apesar do XSL ter elementos de loop, condies de teste, e etc., as pginas co a Web em XML e XSL ainda so estticas como o HTML. a a
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 descrio XSL no ca arquivo XML e deixar a transformao para o browser. Embora isso funcione ca bem, no sempre desejado incluir a referncia ao XSL no arquivo XML essa a e e soluo no funcionaria com um navegador sem nenhuma facilidade XSL. ca a Uma soluo mais verstil usar o JavaScript para fazer a transformao de ca a e ca XML para HTML. Usando-se JavaScript pode-se:
Permitir que o JavaScript faa um teste de navegao espec c ca co; Usar diferentes modelos de estilo de acordo com o navegador e/ou as necessidades de usurio. a Usando JavaScript poss transformar dados de um formato para outro, e vel suportando diferentes navegadores e diferentes necessidades dos usurios. a
24.15
XSL no lado Servidor
A soluo apresentada anteriormente utilizando JavaScript esbarra no probca lema de o browser no suportar um parser XML, pois a transformao no a ca a 254
Figura 24.8: Visualizao do arquivo XSL com uso do <xsl:apply-template> ca funcionaria. Para disponibilizar os dados XML para todos os tipos de navegadores, o documento XML transformado no servidor e enviado como HTML puro para e 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
Cap tulo 25
Gerenciador de Conte do u Web Zone/Plone

25.1 Gesto de Conte do a u
Os produtos e servios de informao dados, textos, imagens, sons, softwares, c ca etc. so identicados na rede com o nome genrico de contedos. A idia a e u e bsica da Gesto de Contedos (GC) agilizar o processo de criao, gesto a a u e ca a e publicao de informao. Em geral, os sistemas de gesto de contedos ca ca a u automatizam o processo de gesto e publicao e permitem que usurios no a ca a a tcnicos possam criar contedos com maior facilidade. e u O processo de gesto de contedo, gura 25.1, envolve as seguintes etapas: a u 1. Criao de documentos; ca 2. Reviso de documentos; a 3. Incluso de metadados (Indexao) e controle de qualidade; a ca 4. Publicao; ca 5. Reviso peridica a o 6. Arquivamento ou eliminao dos documentos. ca
Figura 25.1: O processo de gesto de contedo a u O processo de gesto pode ser representado em trs partes bsicas: criao, a e a ca gesto e publicao. A fase de gesto envolve as etapas de indexao e controle a ca a ca de qualidade, reviso, arquivamento e eliminao de documentos. a ca 256
Os componentes do gerenciamento de contedo so a administrao de contedo, u a ca u gerenciamento de workow, acesso e segurana, bem como a customizao e inc ca tegrao com sistemas legados. ca Os sistemas de gesto de contedo so uteis em diversas aplicaes, como a u a co por exemplo, comunidades prticas, portais corporativos e sites editoriais. a
25.2
Sistema de Gesto de Conte do a u
Em geral, um sistema de gesto de contedo composto por mdulos que a u e o fornecem servios que garantem um processo mais gil na criao, gesto e pubc a ca a licao de contedos. As funcionalidades essenciais existentes nesses sistemas ca u so: a Gesto de usurios e de seus direitos permite o controle de acesso por usurios, a a a incluindo ferramentas de criao de pers de usurios, autenticao, auca a ca torizao e auditorias; ca Criao, edio e armazenamentos de conte dos suporte ` criao, edio ca ca u a ca ca e manipulao de contedos, considerando mltiplos tipos (udio, v ca u u a deo, imagem, xml, html, texto, etc.); Metadados (propriedades que descrevem o conte do) descrevem caracu ter sticas importantes do contedo como descrio, autor, linguagem, data u ca da criao, data da reviso, etc. Os metadados possibilitam o controle de ca a acesso, controle de qualidade, classicao e eliminao automtica de ca ca a documentos; Gesto de qualidade inclui regras associadas aos tipos de contedo que pera u mitem controle e acompanhamento do ciclo de vida. Um sistema worow consiste na automatizao de procedimentos na qual documentos, inca formaes ou tarefas so passadas de um participante a outro, governado co a por regras; Classicao, indexao e busca de conte do inclui mecanismos automca ca u atizados de classicao e indexao e de recursos de busca ecientes ca ca baseados em metadados; Gesto de interface com usurios o contedo independente da lgica da a a u e o aplicao e da apresentao visual. A publicao dinmica em funo ca ca ca e a ca do usurio e do dispositivo de sa a da. O acesso ao contedo controlado u e e pode ser agrupado em trs reas de controle: Acesso pblico, Acesso e a u restrito por licena e acesso privilegiado (controlado a partir de regras c relacionadas ao contedo e usurio); u a Sindicalizao (syndication) tcnica que permite compartilhar informao ca e ca entre diferentes sites por meio do formato RSS; Gesto de verses permite manipular diferentes verses do site, ou de um a o o conjunto de contedos; u Gravao das aes e possibilidade de desfaz-las permite que se recuca co e pere de erros. Todas as mudanas no site (incluindo mudanas na lgica, c c o apresentao e contedo) podem ser desfeitas. ca u 257
No mercado de gesto de contedos, o ambiente Zope, uma framework para a u gesto de contedos, e o Plone, sistema de gesto de contedos, ambos de cdigo a u a u o aberto, tem atra um nmero crescente de empresas e usurios. do u a Obs.: Um framework (literalmente: moldura, esqueleto, armao) um ca e amlgama de servios de softwaresatmicos coerentes. Considerando como a c o tijolosde base, estes servios so montados para formar uma aplicao. A c a ca equipe pode concentrar-se nas regras de negcios e no nos aspectos tcnicos o a e dos projetos.
25.3
Zope
O Zope (Z Object Publishing Environment) uma plataforma de desenvolvie mento de aplicaes Web baseada em Python e oferece um sistema de gesto co a de contedos, onde o usurio poder publicar e gerenciar o contedo Web. E u a u um ambiente totalmente Orientado a Objetos e o permite o desenvolvimento via Web. O Zope integra um grande nmero de ferramentas e funcionalidades u como uma base de dados de objetos, um mdulo de publicao de objetos Web o ca e uma linguagem de gerao dinmica de pginas. ca a a O Zope um ambiente multiplataforma (funciona em Unix, Linux, Mac Os e e Windows). E registrado com a licena ZPL (Zope Public License), compat c vel com GPL (General Public License). Diferente das outras soluoes do mercado, a nalidade do Zope no publicar c a e pginas HTML, mas objetos que podem ser montados automaticamente a partir a de componentes cujo comportamento, dados e a aparncia so congurveis pelo e a a projetista do site. Esta abordagem torna o Zope mais apto ` publicao de a ca contedo Web que os outros produtos. u A arquitetura do Zope, mostrada na gura 25.2, constitu pelos seguintes e da mdulos: o Servidor Web (ZServer) O Zope possui seu prprio servidor web, o Zope o Server, e dispensa a presena de qualquer outro servidor web. Entretanto c no impede a utilizao de outro servidor web como Apache e Microsoft a ca IIS. ; Banco de dados orientado a objetos (ZODB) o Zope possui seu prprio o servidor de Banco de Dados Orientado a Objetos (ZODB), onde armazena os objetos em uma representao simples e eciente, que formada pela ca e classe do objeto e uma estrutura de dicionrio contendo nas chaves as a propriedades do objeto e nos valores associados `s chaves que cada proa priedade possui; ZClassses Funcionam como molduras para os novos objetos no Zope. So esa 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 mtodo, etc. ZClasses podem ser criadas e ampliadas utie lizando apenas a interface web; Zope Products So produtos implementados em Python; a Integrao com banco de dados relacionais O Zope apresenta componentes ca de acesso a vrios bancos de dados, por exemplo, MYSQL, Oracle, Posta 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 criao de modelos de pginas para apresentao. A DTML uma linca a ca e guagem de criao de scripts que permite ligar dados dinmicos e modelos, ca a denindo a apresentao visual desses dados; ca Interface Web de gerenciamento e desenvolvimento Zope apresenta uma poderosa interface de gerenciamento e desenvolvimento (ZMI Zope Management Interface) que permite adicionar, editar e remover objetos, congurar propriedades, via browser padro. Inclui acesso via ftp ou WebDAV a e oferece suporte aos protocolos DOM, XML, SOAP e XML-RPC.
A idia principal em torno do Zope a construo de um ambiente de e e ca publicao de objetos. Nesse contexto, elementos constituintes de uma pgina ca a HTML so vistos como objetos que podem ser publicados e gerenciados atravs a e do Zope. Sua arquitetura ex e baseada em componentes atende a diversas vel aplicaes: co Gerenciar Websites o Zope inclui recursos como a possibilidade de delegao ca de acesso a diferentes n veis, separao do contedo, lgica e apresentao, ca u o ca controle de acesso, controle de verses, segurana, etc; o c Construir sistemas de gesto de conte do a arquitetura Zope inclui coma u ponentes e disponibiliza produtos, que fornecem ferramentas que possi259
bilitam criar, gerenciar e publicar contedos, de modo fcil e seguro, por u a usurios no tcnicos; a a e Desenvolver aplicaes Web personalizadas o Zope forenece um frameco work com aplicaes sosticadas, como comrcio-eletrnico, portais, fruns co e o o e aplicaes personalizadas. O Zope fornece componentes funcionais de co acesso a dados, segurana e personalizao, que integrados facilitam a c ca construo de aplicaes Web rapidamente; ca co Desenvolver portais corporativos o Zope possibilita o desenvolvimento de um site organizacional ou de uma comunidade de usurios, tal que o a contedo, como not u cias, documentos, eventos, seja fornecido por membros da organizao. O ambiente Zope, atravs de sua arquitetura ex ca e vel e de produtos desenvolvidos pela comunidade de usurios, especialmente o a Plone (um produto para portais), fornece elementos necessrios para a cona struo rpida de um portal (apresentao e personalizao, organizao ca a ca ca ca e gerenciamento, integrao com diversas fontes de dados, mecanismos de ca indexao e busca, segurana, escalabilidade, etc). ca c
25.4
Plone
O Plone um sistema gesto de contedo livre e de cdigo aberto que roda e a u o em servidores Zope. Surgiu de uma evoluo do CMF (Content Management ca Framework) do Zope. O Plone foi escrito em Python e roda sobre o Zope o CMF. O Plone vem com um sistema de workow, segurana e funes prc co e conguradas, um conjunto de tipos de contedo e suporte a vrias l u a nguas. O Plone no substitui o CMF, ele o complementa em funcionalidade e tambm a e em ambigidade de interface com usurio, apresentando uma interface mais u a amigvel para o usurio nal. A gura 25.3 mostra a arquitetura do Zope, a a CMF e Plone. Algumas caracter sticas do Plone: Internacionalizao a interface de usurios traduzida para diversas l ca a e nguas; Usabilidade permite desenvolver sites com alto n de usabilidade e acessivel bilidade; Personalizao de templates o Plone separa o contedo do template no qual ca u o contedo est sendo exibido. Os templates do Plone so escritos em u a a cdigos HTML com folhas de estilo CSS; o Personalizao de registro de usurios o Plone possui um completo sisca a tema de registro de usurios, onde poss a e vel personalizar o registro de usurios. E poss a vel usar informaes de usurios de outros bancos de co a dados relacional (LDAP, AD, e outros); Workow e segurana o workow controla a lgica de processamento de c o contedo de um site. E poss congurar o workow na web utilizando u vel ferramentas grcas. Para cada item de contedo em um site Plone a u e poss vel construir uma lista de usurios que podem acess-lo e se esto a a a habilitados a interagir com este contedo (editar, ver, excluir, comentar, u etc.); 260
Figura 25.3: Arquitetura Zope, CMF e Plone Extens vel como o Plone de cdigo aberto poss alter-lo sem problemas. e o e vel a Com ferramentas de desenvolvimento como Archetype, poss gerar e e vel alterar cdigo do Plone por meio da Web; o Personalizao de conte do o administrador de sites pode desenvolver seus ca u prprios tipos de contedos e gerenci-los conforme as necessidades. Com o u a a ferramenta Archetype, poss gerar novos tipos de contedo usando e vel u ferramentas de UML; Comunidade Plone uma das melhores caracter sticas do Plone comunidade e de desenvolvedores e empresas que prestam suporte ao desenvolvimento. Os tipos bsicos de contedo do Plone so: a u a Documento apresenta informaes estticas para o usurio. E o mais usado e co a a pode ser considerado como uma pgina de um site; a Evento representam reunies, eventos, encontros, seminrios, e so utilizados o a a nas pesquisas por tpico de calendrio; o a Arquivo objetos podem conter arquivos pass veis serem baixados; Pasta serve para adicionar outros tipos de contedo. Pode ser usada para u denir vises de informaes personalizadas. E como uma pasta no disco o co r gido; Imagem uma imagem do tipo GIF ou JPEG; e Link so endereos Web; a c 261
Not cia contm pequenos artigos e podem possuir t e tulo assim como uma descrio opcional. ca Algumas denies relacionadas ao Plone: co Portlet Um site Plone possui uma trs colunas por padro. As colunas da e a esquerda e da direita possuem uma srie de caixas que mostram algum e tipo de informao. Cada uma dessas caixas chamada de portlet; ca e ZPT (Zope Page Template) um sistema de templates usados pelo Plone e para exibio de algum contedo; ca u Plone workow por meio das permisses padro (pendente, pblico, privado o a u e esboo) do workow Plone poss criar n c e vel veis de acesso a informaes, co vises de contedos diferenciadas e regras de administrao de contedo o u ca u espec cas para cada tipo de contedo; u Archetype um framework para o desenvolvimento automatizado de produtos e (contedos) no Plone; u ArchGenXML uma ferramenta de gerao de cdigo que permite desene ca o volver novos tipos de contedo por meio de um modelo UML. u O Plone hoje a mais recomendada opo para criao, publicao e edio e ca ca ca ca de portais web. Ele pode ser usado como um servidor para intranets ou extranets, um sistema publicador de contedos e uma ferramenta de colaborao u ca interativa. O Plone roda em diversos sistemas operacionais (como Linux, Windows, Solaris, FreeBSD e Mac OS X). O uso do Plone est associado a vrios casos de sucesso no Brasil e no mundo. a a No Brasil, pode-se citar o projeto Interlegis e o Serpro. O propsito do Interlegis o integrar as casas do poder legislativo e Serpro uma empresa especializada e e em fornecer servios de TI para organizaes pblicas federais. c co u
262
Cap tulo 26
Web Services
26.1 O que Web Services? e
Web Service um componente de software identicado por uma URI que ine depende de implementao ou de plataforma e pode ser descrito, publicado e ca invocado sobre uma rede por meio de mensagens padro XML. As mensagens a XML so transportadas usando protocolos padres da Internet. Com web sera o vice poss realizar a integrao entre sistemas desenvolvidos em diferentes e vel ca linguagens e plataforma, e disponibilizar servios interativos na Web. E uma c tecnologia de padro aberto e padronizada pelo W3C. a A arquitetura do Web Service constitu por trs componentes bsicos: e da e a o servidor de registro (broker server ou service registry), o provedor de servios c (service provider) e o solicitante de servios (service requestor). As interaes c co entre esses componentes so de busca, publicao e interao de operaes. a ca ca co Na operao de publicaao o provedor publica a descrio do servio de ca c ca c tal forma que um solicitante possa localiz-la. Na operao de busca o solicia ca tante obtm a descrio do servio diretamente ou consulta o servidor de registro e ca c procurando pelo tipo de servio desejado. Essa operao pode ser executada em c ca duas fases distintas: desenvolvimento ou execuo. Na operao de interao ca ca ca o solicitante chama ou inicia uma interao com o provedor, em tempo de exca ecuo, utilizando os detalhes contidos na descrio do servio para localizar, ca ca c contactar e chamar o servio. A gura 26.1 mostra os componentes e a interao c ca entre eles. O provedor de servios representa a plataforma que hospeda o web service c permitindo que os clientes acessem o servio. O provedor de servios fornece o c c servio e responsvel por publicar a descrio do servio que prov. O solicc e a ca c e itante de servios a aplicaao que est procurando, invocando uma interao c e c a ca com o web service, ou seja, requisita a execuo de um servio. O solicitante de ca c servio pode ser uma pessoa acessando por meio do browser ou uma aplicao c ca realizando uma invocao aos mtodos descritos na interface do web service. O ca e servidor de registro um repositrio central que contm a descrio (informao) e o e ca ca de um web service, e por meio do servidor de registro que essas descries so e co a publicadas e disponibilizadas para localizao. ca Os clientes buscam por servios no servidor de registro e recuperam inc formaes referentes ` interface de comunicao para os web service durante co a ca
263
Figura 26.1: Componentes bsicos da arquitetura do Web Service a a fase de desenvolvimento ou durante a execuo do cliente, denominadas inca terao esttica (static bind) e interao dinmica (dinamic bind), respectica a ca a vamente. Na interao esttica, o cliente recupera a assinatura do servio, ca a c necessria ` codicao. Na interao dinmica, o cliente recupera os valores a a ca ca a de parmetros e a localizao do servio. a ca c O ciclo de vida de um web service compreende quatro estados distintos, gura 26.2: Publicao processo, opcional, por meio do qual o fornecedor do web services ca d a conhecer a existncia do seu servio, efetuando o registro do mesmo a e c no repositrio do web service; o Descoberta processo, opcional, por meio do qual uma aplicao cliente toma ca conhecimento da existncia do web services pretendido pesquisando num e repositrio UDDI; o Descrio processo pelo qual o web service expe a sua API (documento ca o WSDL). Desta maneira a aplicao cliente tem acesso a toda a interface ca do web service, onde encontram descritas todas as funcionalidades por ele disponibilizadas; Invocao (Mensagens) processo pelo qual o cliente e o servidor interagem, ca por meio do envio de mensagens; A conjugao desses quatro estados permite constituir o ciclo de vida de um ca web service: O fornecedor constri o servio utilizando a linguagem de programao que o c ca entender; De seguida, especica a interface/assinatura do servio que deniu em c WSDL;
264
Figura 26.2: Ciclo de vida do web service Aps a concluso dos dois primeiros passos, o fornecedor registra o servio o a c no UDDI; O utilizador (aplicao cliente) pesquisa num repositrio UDDI e encontra ca o o servio; c A aplicao cliente estabelece a ligao com o web service e estabelece um ca ca dilogo com este, via mensagens SOAP. a A interao entre os web services se d sob vrios protocolos abertos, em ca a a diferentes n veis de abstrao. Os protocolos utilizados para realizar a comuca nicao so o: UDDI (Universal Description Discovery and Integration), WSDL ca a (Web Services Description Language), XML, SOAP (Simple Object Access Protocol) e o HTTP, conforme gura 26.3.
Figura 26.3: Protocolos de comunicao de Web services ca As mensagens trocadas so formatadas no protocolo SOAP, o que permite a a interoperabilidade entre diferentes plataformas, em um processo denominado serializao XML. Porm, antes que as mensagens SOAP sejam trocadas, suas ca e caracter sticas so explicitadas por meio de documentos WSDL, que descrevem a quais dados estaro sendo trocados, e como estes dados estaro organizados nas a a mensagens SOAP. Adicionalmente, os servios dos web services podem ser pubc licados atravs de UDDI, que um formato utilizado para seu armazenamento e e 265
em repositrios dispon o veis na Internet. Assim, se um desenvolvedor precisar resolver uma determinada tarefa, pode encontrar o web service que mais se adequar ` sua necessidade. a Como os rewalls convencionais e proxies no bloqueiam a porta utilizada a pelo protocolo HTTP, no existem grandes restries para o uso deste tipo de a co aplicao em redes de longa distncia. ca a Pode-se denir, resumidamente, o web service como sendo um servio de c 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 disseminao no uso de web services nos ultimos anos incentivou o mercado ca a oferecer uma grande variedade de ferramentas e aplicaes para prover suporte co a essa tecnologia. Atualmente, as principais plataformas para web services so: a Sun Microsystems, IBM, BEA, Apache, Systinet e Microsoft.
26.2
SOAP
O SOAP (Simple Object Access Protocol) um protocolo leve para troca de e informaes em um ambiente descentralizado e distribu que permite comuco do nicao entre aplicaes de forma simples e completamente independente de ca co sistema operacional, linguagem de programao ou plataforma. E o protocolo ca de comunicao para os Web Services. ca A comunicao realizada por meio de trocas de mensagens, transmitidas ca e em formato XML, incluindo os parmetros usados nas chamadas, bem como a os dados de resultados. Tambm pode ser utilizado para invocar, publicar e e localizar web services no registro UDDI. Parte da sua especicao composta por um conjunto de regras de como ca e utilizar o XML para representar os dados. Outra parte dene o formato de mensagens, convenes para representar as chamadas de procedimento remoto co (RPC Remote Procedure Calls) utilizando o SOAP, e associaes ao protocolo co HTTP. O protocolo HTTP o unico protocolo padronizado pelo SOAP, mas e existem algumas implementaes que suportam outros protocolos como SMTP, co TCP/IP, FTP e etc. Uma mensagem SOAP nada mais do que um fragmento XML bem formado, e encapsulado por um par de elementos SOAP. A mensagem SOAP consiste dos seguintes elementos, gura 26.4:
Envelope toda mensagem SOAP deve cont-lo. E o elemento raiz do docue mento XML. Dene o in e o m das mensagens; cio Header um cabealho opcional. Ele carrega informaes adicionais, como e c co exemplo, se a mensagem deve ser processada por um n intermedirio. o a Quando utilizado, o Header deve ser o primeiro elemento do envelope; Body obrigatrio e contm o payload, os dados em XML a serem transportae o e dos. O elemento Body possui um campo opcional Fault, usado para carregar mensagens de status e erros retornadas pelos nsao processarem o a mensagem; RPCs ou chamadas remotas de procedimento so chamadas locais a mtodos a e de objetos (ou servios) remotos. Portanto, pode-se acessar os servios de um c c 266
Figura 26.4: Estrutura da mensagem SOAP objeto localizado em outro ponto da rede, atravs de uma chamada local a este e objeto. Cada chamada ou requisio exige uma resposta. ca O processo de uma chamada RPC: Antes de serem enviadas pela rede, as chamadas de RPC (emitidas pela aplicao cliente) so encapsuladas (ou serialca a izadas) segundo o padro SOAP. O servio remoto, ao receber a mensagem faz a c o processo contrrio, desencapsulando-a e extraindo as chamadas de mtodo. a e A aplicao servidora ento processa esta chamada, e envia uma resposta ao ca a cliente. O processo ento se repete: a resposta tambm serializada e enviada a e e pela rede. Na mquina cliente, esta resposta desencapsulada e repassada a e e para a aplicao cliente. ca A especicao SOAP dene as seguintes informaes, como necessrias em ca co a toda chamada de RPC: A URI do objeto alvo; O nome do mtodo; e Os parmetros do mtodo (requisio ou resposta); a e ca Uma assinatura do mtodo opcional; e Um cabealho (header) opcional. c
26.3
WSDL
O WSDL (Web Services Description Language) uma linguagem baseada em e XML, utilizada para descrever um web service. Um web service deve denir todas as suas interfaces, operaes, esquemas de codicao, o contedo das co ca u mensagens, onde o servio est dispon e quais os protocolos de comunicao c a vel ca so usados para conversar com o servio e entre outros neste documento. Um a c documento WSDL dene um XML Schema para descrever um web service. A descrio de um servio consiste de duas partes, gura 26.5: denio de ca c ca implementao do servio e denio da interface do servio. A separao entre ca c ca c ca as duas camadas permite que elas sejam utilizadas separadamente. A parte de denio de interface do servio descreve o web service, incluindo ca c mtodos que so invocados e parmetros que so enviados. A parte de denio e a a a ca
267
Figura 26.5: Camada de descrio de servios da WSDL ca c de implementao de servios descreve como uma interface de servio imca c c e plementada por um provedor: onde o servio est instalado e como pode ser c a acessado. As descries dos elementos das duas partes: co Binding descreve protocolos, formato de data, segurana e outros atributos c para uma interface (portType) em particular; Porttype informa elementos de operaes do web service; co Message dene entrada e sa de dados referentes a operaes; da co Type dene tipos de dados complexos em uma mensagem; Service contm uma coleo de elementos port com elementos binding; e ca Port a combinao de um binding com endereo de rede, fornecendo o ene ca c dereo alvo para a comunicao dos servios. c ca c To logo o cliente tenha acesso ` descrio do servio a ser utilizado, a a a ca c implementao do Web Service pode ser feita em qualquer linguagem de proca gramao. Normalmente so utilizadas linguagem constru ca a das para interao ca 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 determinado web service, ele obtm a descrio do servio (atravs da localizao do e ca c e ca respectivo documento WSDL), e em seguida constri a mensagem, passando os o tipos de dados corretos (parmetros, etc) de acordo com a denio encontrada a ca no documento. As duas partes envolvidas em uma interao web service preca cisam ter acesso ` mesma descrio WSDL para conseguirem entender uma ` a ca a outra. Em seguida, a mensagem enviada para o endereo onde o servio est e c c a localizado, a m de que possa ser processada. O web service, quando recebe esta mensagem valida-a conforme as informaes contidas no documento WSDL. A co partir de ento, o servio remoto sabe como tratar a mensagem, sabe como a c process-la (possivelmente enviando-a para outro programa) e como montar a a resposta ao cliente.
268
26.4
UDDI
Para que um servio seja utilizado necessrio que o cliente consiga localizc e a a lo, e essa localizao pode ser feita por meio do UDDI (Universal Description, ca Discovery and Integration), que uma especicao tcnica para descrever, e ca e descobrir e publicar web services. Uma implementao de UDDI corresponde a um registro web service, que ca prov um mecanismo para busca e publicao de web services. Um registro e ca UDDI contm informaes categorizadas sobre os servios e as funcionalidades e co c que eles oferecem, e permite a associao desses servios com suas informaes ca c co tcnicas, geralmente denidas usando WSDL. e O UDDI possui um componente central chamado UDDI Project, que manipula um registro global e pblico chamado business registry. A informao u ca oferecida pelo bussines registry consiste de trs componentes: white pages, yele low pages e green pages. A informao fornecida por um registro UDDI pode ser comparada ` uma ca a lista telefnica. As pginas brancas (white pages), fornecem informaes tais o a co como nome da organizao, contato e identicadores. As pginas amarelas ca a (yellow pages) so compostas por um a ndice de servios e produtos e as pginas c a verdes (green pages) contm informaes a respeito de transaes, descries de e co co co servio e invocao de aplicaoes. c ca c As informaes contidas em arquivos de descrio de servio (WSDL) comco ca c pletam aquelas que esto no registro. No entanto, UDDI no fornece suporte a a a vrios tipos de descrio de servio, mas no suporta a criao de descries a ca c a ca co WSDL de forma direta. Uma descrio WSDL completa consiste da combinao dos documentos de ca ca interface e de implementao de servio. A primeira publicada no registro ca c e UDDI como businessservice e a segunda como tmodel.
26.5
Segurana c
A segurana no envio de mensagens SOAP um tpico importante. Em um n c e o vel mais baixo, mensagens SOAP podem ser trocadas pela rede utilizando HTTPS ao invs de HTTP. Como HTTPS utiliza SSL no seu transporte, ca garantida e a proteo contra poss ca veis intervenes. Alm disso, o cliente e servidor podem co e vericar cada um suas respectivas identidades. Embora HTTPS resolva o problema de proteo das mensagens contra poss ca veis invasores, este no ajuda muito quando se necessita da segurana necessria a c a para a autenticao de usurios de web services espec ca a cos. Estes servios iro c a fornecer algum tipo de combinao de usurio/senha durante a fase inicial de ca a registro no servio e ento esta ser utilizada para acessos futuros. No h ainda c a a a a um padro de autenticao para Web services, mas pode utilizar os rewalls, a ca VPNs, NTFS, produtos de single-in para oferecer a autenticao e autorizao ca ca de usurios. a
269
Parte VI
Redes de Comunicao ca
270
Cap tulo 27
Tcnicas Bsicas de e a Comunicao ca

27.1 Base Terica da Comunicao de Dados o ca
As informaes podem ser transmitidas por os fazendo-se variar alguma proco priedade f sica, como voltagem ou corrente. Representando o valor dessa voltagem ou corrente como uma funo de tempo com uma valor unico, f(t), pode-se ca criar um modelo para o comportamento do sinal e analis-lo matematicamente. a Tal anlise conhecida como Anlise de Fourier e ela arma que qualquer a e a funo peridica razoavelmente estvel, g(t), com o per ca o a odo T pode ser constru como a soma de um nmero (possivelmente innito) de senos e co-senos. da u A decomposio dos harmnicos que compe que compe a funo a chamada ca o o o ca e srie de Fourier. e Nenhum recurso de transmisso capaz de transmitir sinais sem perder a e parte da energia no processo. Se todos os coecientes da sria de Fourier fossem e igualmente reduzidos, o sinal resultante seria reduzido em amplitude, mas no a seria distorcido. Infelizmente, todos os meios de transmisso reduzem diferentes a componentes de Fourier por diferentes valores e, em conseqncia disso, introue duzem distores. Em geral, as amplitudes so transmitidas sem reduo, de co a ca 0 a alguma freqncia fc, com todas as freqncias acima dessa freqncia de ue ue ue corte sendo atenuadas A faixa de freqncias transmitidas sem serem fortemente ue atenuadas denomina-se largura de banda. Na prtica, o corte no n a a e tido; assim, muitas vezes a largura de banda varia desde 0 at a freqncia em que a e ue metade da potncia transmitida. e e A largura de banda uma propriedade f e sica do meio de transmisso, e a em geral depende da construo, da espessura e do comprimento do meio. Em ca alguns casos um ltro introduzido no circuito para limitar o volume de largura e de banda dispon para cada cliente. Por exemplo, uma linha telefnica pode vel o ter uma largura de banda de 1MHz para curtas distncias, mas as empresas de a telefonia limitam essa faixa a cerca de 3100 Hz.
271
27.2
Taxa Mxima de Dados em um Canal a
Em 1924, Henry Nyquist percebeu que at mesmo um canal perfeito tem uma e capacidade de transmisso nita. Ele derivou uma equao expressando a taxa a ca mxima de dados de um canal sem ru com largura de banda nita. Em 1948, a do Claude Shannon aprofundou o trabalho e o estendeu ao caso de uma canal com ru aleatrio (isto , termodinmico). do o e a Nyquist provou que, se um sinal arbitrrio atravessar um ltro com baixa a freqncia de corte H, o sinal ltrado poder ser completamente reconstru ue a do a partir de apenas 2H amostras (exatas) por segundo. Fazer uma amostragem da linha com uma rapidez maior que 2H/s seria intil, pois os componentes u de freqncia mais alta que essa amostragem poderia recuperar j teriam sido ue a ltrados. Se o sinal consistir em V n veis discretos o teorema de Nyquist arma que: S ) (27.1) N Se houver ru aleatrio, a situao ir se deteriorar mais rapidamente. do o ca a Alm disso, sempre existe ru aleatrio (trmico) presente, devido ao movie do o e mento das molculas no sistema. O volume de ru trmico presente medido e do e e pela relao entre a potncia do sinal e a potncia do ru ca e e do, chamada relao ca sinal/ru do. Dessa forma, o principal resultado de Shannon que a taxa mxima e a de dados de um canal com ru dos cuja largura de banda H Hz, e cuja relao e ca sinal/ru S/N, dada por: do e e Maximum Data Rate = 2Hlog2 (1 + S ) (27.2) N Por exemplo, um canal com largura de banda de 3000 Hz com uma relao ca sinal/ru de 30 db nunca pode transmitir muito mais que 30000 bps, indedo pendente da quantidade de n veis de sinal utilizados e da freqncia com que as ue amostras so obtidas. a Maximum Number of Bits/sec = Hlog2 (1 +
27.3
Sinais Digitais Binrios a
Os sinais digitais binrios podem ser estudados como se fossem um sinal quadrado. a Atravs da Srie de Fourier, poss reconstruir um sinal quadrado a partir e e e vel da correspondente senide fundamental. Ao incluirmos as freqncias harmnicas o ue o de ordem mpar, o sinal reconstru aproxima-se cada vez mais do sinal quadrado do original. A gura 27.1 ilustra a reconstituio de um sinal quadrado a partir da ca senide fundamental e suas harmnicas o o mpares at a quinta ordem. e Assim sendo, na transmisso digital entre dois pontos, dever a amos ter um meio de transmisso com largura de faixa (banda passante) innita, para que a o sinal digital transmitido fosse recebido sem nenhuma distoro. Entretanto, ca sicamente isso no poss a vel. Poderia-se pensar, ento, em aumentar a largura a de faixa do canal ao mximo para atenuar as distores, no entanto isso no a co a e vivel economicamente. a A soluo adaptar o sinal digital aos tipos de degradao inerentes aos ca e ca meios de transmisso. Para isto, foram desenvolvidos dispositivos capazes de a transformar o sinal digital do computador em uma forma poss de ser transmivel tida pelo meio sem que ocorram danos graves. Estes dispositivos so chamados a 272
Figura 27.1: Reconstituio de um sinal binrio ca a de Modems(Modulator/Demodulator). Este equipamento executa uma transformao por modulao (modem analgico) ou por codicao (modem digital) ca ca o ca dos sinais digitais gerados pelo computador. A rigor, os modems digitais no a deveriam receber esse nome, pois eles no executam a modulao/demodulao a ca ca do sinal digital, apenas a codicao. Em complemento, os modems digitais ca tambm recebem os nomes modem banda-base e modem data set. Mesmo use ando o modem digital, devido as caracter ` sticas da onda quadrada, a transmisso a s poder ocorrer a curtas distncias e com linhas de boa qualidade. o a a
27.4
Transmisso em Banda Base a
Banda base freqentemente utilizada para a transmisso digital de dados, um e u a unico canal utiliza a largura de banda total dispon vel. Assim, a transmisso a de um sinal em banda base consiste em enviar o sinal de forma digital atravs e da linha (forma de onda digital), ou seja, enviar os bits conforme a necessidade, de acordo com um padro digital. Desde que a distncia entre o transmissor e a a receptor seja de alguns quilmetros, a banda de transmisso dispon seja em o a vel torno de 15 KHz e o meio de transmisso tenha certas caracter a sticas, poss e vel realizar a Codicao Banda Base do sinal digital. Nesse sentido, a distncia ca a alcanada na transmisso diminui conforme aumenta a velocidade transmisso. c a a O alcance mximo denido como sendo a distncia mxima em que poss a e a a e vel transmitir mantendo a taxa de erro abaixo de um valor predeterminado.
27.5
Classicao dos Sinais ca
Os sinais em Banda Base podem ser classicados quanto a durao e polaridade ca de seus pulsos: Durao: ca o NRZ (non return to zero): cada bit 0 representado por um pulso e OFF e cada bit 1 por um pulso ON ocupando todo o intervalo signicativo do bit;
273
RZ (return to zero): os bits 1 so representados por pulsos ON com a durao de meio intervalo signicativo bit. ca Polaridade: Unipolar: os dois n veis tm a mesma polaridade (exemplo: 0 e +). e Esse tipo de sinal resulta em codicao com componente DC que no ca a leva informao, mas consome energia. Alm disso, a ocorrncia de ca e e uma longa seqncia de bits 0 resulta em um sinal que no apresenta ue a transies, dicultando a sincronizao dos equipamentos. co ca Polar: este sinal possui pulsos com polaridades opostas (exemplo: o bit 0 representado por pulso -e o bit 1 por pulso +), zerando e a componente DC se a mensagem contiver uma proporo igual de ca bits 0 e 1.O nmero de transies depender completamente do sinal u co a transmitido. Bipolar: os sucessivos bits 1 so representados com pulsos de polaria dade alternada.
27.6
Tcnicas de Codicao de Linha e ca
As diversas tcnicas de codicao do sinal digital procuram gerar o sinal codie ca cado com muitas transies, a m de facilitar a recuperao do sincronismo no co ca modem receptor (recuperao do relgio). Alm disso, procura-se concentrar o ca o e espectro de transmisso do sinal codicado dentro de uma faixa de freqncia a ue com pouco componente DC. Diversas tcnicas de codicao so ilustradas na e ca a gura 27.2 e descritas adiante.
Figura 27.2: Exemplos de ondas codicadas
27.6.1
Codicao NRZ ca
Com o cdigo NRZ, o n o vel do sinal mantido constante em uma de duas e tenses poss o veis, pela duraao de um intervalo de bit. Se as duas voltagens c
274
permitidas so 0 e V, a forma de onda NRZ dita UNIPOLAR. Este sinal tem a e uma componente DC diferente de zero. Por outro lado, o sinal NRZ BIPOLAR usa duas polaridades, +V e -V, deste modo prov uma componente DC nula. e A codicao NRZ apresenta carncia de transies de dados, o que resulta ca e co em um pobre desempenho na recuperao de relgio no receptor. A recuperao ca o ca do relgio nesse contexto signica recuperar o relgio usado no transmissor para o o temporizar a codicao do sinal e assim permitir a recuperao da informao ca ca ca no lado receptor. Esta caracter stica limita o seu uso apenas para pequenas distncias de transmisso e conexes entre estaes. a a o co
27.6.2
Codicao RZ ca
O n vel do sinal que representa o bit de valor 1 dura a primeira metade do intervalo do bit, aps o qual o sinal retorna para o n de referncia (zero) para o vel e o restante meio intervalo de bit. Um bit 0 indicado por uma no mudana, e a c com o sinal continuando no n de referncia (zero). vel e Sua principal vantagem reside no aumento das transies e comparao co ca com o NRZ, com uma resultante melhoria na recuperao do relgio no reca o ceptor. Nota-se que uma seqncia muito grande de 0 resulta em um sinal sem ue transies, o que representa um problema para os circuitos de recuperao de co ca relgio. o
27.6.3
Codicao AMI (Alternate Mark Invertion) ca
Na codicao AMI (bipolar), o bit 0 sempre codicado como n zero, e os ca e vel bits 1 so codicados como +V ou -V, onde a polaridade alternada para cada a e ocorrncia de bit 1. A codicao AMI resulta em uma componente DC nula. e ca A representao AMI pode ser NRZ (100 % do tempo de bit) ou RZ (50% do ca tempo de bit). A garantia de transio dos n ca veis para cada bit 1, proporciona um timo o desempenho na recuperao de relgio, melhorando ainda mais quando o sinal ca o for RZ. Esta codicao apresenta ainda a capacidade de deteco de erro, pois ca ca amplitudes positivas consecutivas sem uma amplitude negativa intermediria (e a vice-versa) constituem uma violao da regra AMI e indicam que ocorreu um ca erro na transmisso. Entretanto, quando ocorrer uma seqncia longa de zeros, a ue o sinal codicado ca muito tempo sem transies na linha, o que diculta a co obteno do relgio de sincronismo. ca o
27.6.4
Codicao HDB-3 (High Density Bipolar with 3 ca Zero Maximum Tolerance)
Nesse tipo de codicao, o sinal digital a ser transmitido analisado e, cada ca e vez que detectada uma seqncia de quatro zeros consecutivos, esta seqncia e ue ue substitu por uma outra seqncia padronizada. Para isso, utilizado o e da ue e recurso da violao, que consiste no uso de um pulso que tenha a mesma ca polaridade que o pulso anterior (o que viola o princ pio bsico do AMI). a No HDB-3, os quatro zeros consecutivos so substitu a dos pela seqncia 000V ue ou V00V, onde V a violao, e a substituio depender do ultimo pulso e ca ca a transmitido, observando sempre o princ pio da alternncia de pulsos. Caso o a ultimo pulso transmitido no seja uma violao e tenha polaridade oposta ` a ca a 275
polaridade da violao anterior, transmitir 000V. No caso em que o ultimo ca a pulso transmitido seja uma violao ou tenha polaridade idntica ` polaridade ca e a da violao anterior, transmitir V00V. Essa escolha entre 000V e V00V faz ca a com que violaes sucessivas sejam de polaridades opostas, o que garante a no co a existncia de sinal DC na linha. e Na recepo, o decodicador tem de vericar, inicialmente, a violao AMI ca ca e, posteriormente, o nmero de zeros que precede esta violao, para determinar u ca se o ultimo pulso transmitido tambm uma violao. Isto feito da seguinte e e ca e forma: se na recepo houver dois pulsos, com mesma polaridade, separados por ca trs zeros, o segundo pulso violao, logo, eliminado. Se na recepo houver e e ca e ca dois pulsos, com mesma polaridade, separados por dois zeros, ambos os pulsos so violao, logo, ambos so eliminados. Nota-se que na codicao HDB-3 so a ca a ca a contornados os problemas do aparecimento do n DC e da falta de transies vel co para recuperao do sinal de relgio. ca o
27.6.5
Codicao Manchester ca
Na codicao Manchester, cada per ca odo de bits dividido em dois intervalos e iguais. Um bit 1 binrio enviado quando a voltagem denida como alta dua e e rante o primeiro intervalo, e como baixa no segundo intervalo. Um bit 0 binrio a exatamente o oposto: primeiro baixo depois alto. Esse esquema garante que e cada per odo de bit ter uma transio na parte intermediria, tornando fcil a ca a a para o receptor sincronizar-se com o transmissor. Uma desvantagem da codicao Manchester que ela exige duas vezes mais largura de banda que a ca e codicao binria direta, pois os pulsos so a metade da largura. Por exemplo, ca a a para transmitir dados a 10 Mbps, o sinal precisa mudar 20 milhes de vezes por o segundo. A codicao Manchester diferencial uma variao da codicao Manchca e ca ca ester apresentada. Nela um bit 1 indicado pela ausncia de uma transio e e ca no in cio do intervalo. Um bit 0 indicado pela presena de uma transio e c ca no in cio do intervalo. Em ambos os casos tambm existe uma transio na e ca parte intermediria. O esquema diferencial exige equipamento mais complexo, a mas oferece maior imunidade a ru dos. Todos os sistemas Ethernet usam a codicao Manchester devido a sua simplicidade. ca
Figura 27.3: Codicaes Binria, manchester e diferencial co a
27.7
Modulao ca
Modulao o processo pelo qual alguma caracter ca e stica de uma onda portadora variada de acordo com a mensagem (sinal modulante), produzindo um sinal e
276
modulado cujas propriedades so mais compat a veis com as caracter sticas do canal. Essa descrio resumida na gura 27.4. ca e
Figura 27.4: Processo de Modulao ca A gura 27.5 resumo a classicao dos tipos de modulao. ca ca
Figura 27.5: Tipos de Modulao ca
27.7.1
Modulao de Onda Cont ca nua
As linhas de transmisso enfrentam trs problemas principais: atenuao, disa e ca toro de retardo e ru ca do. Devido a esses problemas e principalmente ao fato de a atenuao e a velocidade de propagao variarem em funo da freqncia, ca ca ca ue no interessante ter uma grande variedade de freqncias no sinal. Infeliza e ue mente, as ondas quadradas usadas em sinais digitais tm um amplo espectro de e freqncias e, portanto, esto sujeitas a uma forte atenuao e a uma distoro ue a ca ca de retardo. Esses efeitos tornam a sinalizao em banda base (DC) inadequada, ca exceto em baixas velocidades e em distncias curtas. a Para contornar os problemas associados ` sinalizao DC usada a sinala ca e izao AC. E introduzido no sinal um tom cont ca nuo na faixa de 1000 a 2000 Hz, denominado onda portadora senoidal. Sua amplitude, freqncia ou fase pode ue ser modulada para transmitir informaes. co Basicamente, existem dois tipos de modulao de onda cont ca nua, a analgica o e a digital. Pode-se citar como exemplo de modulao analgica a modulao ca o ca AM (Amplitude Modulation) onde a variao da amplitude da portadora ocorre ca de acordo com a variao do sinal modulante. Este tipo de modulao tem ca ca algumas derivaes, tais como, AM-DSB (Double-Sideband Amplitude Modulaco tion), AM-DSB-SC (Double-Sideband Suprisse Carrier Amplitude Modulation) 277
e AM-VSB (Vestigial-Sideband Amplitude Modulation). A modulao FM (Freca quency Modulation) tem melhor qualidade que a AM por ser menos suscept vel a ru dos. Neste tipo de modulao ocorre a variao de freqncia da portadora ca ca ue em funo da variao do sinal modulante. A Modulao PM (Phase Moduca ca ca lation) tem como principal caracter stica a variao da fase da portadora em ca funo da variao do sinal modulante. A gura 27.6 mostra alguns exemplos ca ca de modulao analgica. ca o
Figura 27.6: Modulao Analgica ca o A modulao digital consiste em aplicar um sinal digital (binrio) como ca a sinal modulante da portadora ao invs de um sinal analgico como ocorre na e o modulao analgica descrita anteriormente. As modulaes digitais mais usca o co adas so ASK (Amplitude Shift Keying), FSK (Frequency Shift Keying), PSK a (Phase Shift Keying). Essas tcnicas de modulao so representadas na gura e ca a 27.7.
Figura 27.7: Modulaao Digital: Amplitude, Frequncia e Fase c e Para atingir velocidades cada vez mais altas no basta apenas aumentar a a taxa de amostragem. O teorema de Nyquist arma que mesmo com uma linha de 3000Hz perfeita no h razo para uma amostragem mais rpida que a a a a 6000Hz. Na prtica, a maioria dos modens realizam amostragens 2400 vezes/s a e se concentra em obter mais bits por amostra. 278
O nmero de amostras por segundo medido em baud. Durante cada baud, u e e enviado um s mbolo. Desse modo, uma linha de n bauds transmite n s mbolos/s. Se o s mbolo consiste em 0 volts para representar um valor lgico 0 e 1 volt para o indicar um valor lgico 1, a taxa de bits 2400 bps. Porm se as voltagens o e e 0, 1, 2, 3 volts so usadas, cada s a mbolo consiste em dois bits, e assim uma linha de 2400 bauds pode transmitir 2400 s mbolos/ s a uma taxa de dados de 4800 bps. De modo semelhante, com quatro deslocamentos de fase poss veis, tambm existem 2bits/s e mbolo, e portanto mais uma vez a taxa de bits o dobro e da taxa em bauds. Essa ultima tcnica amplamente usada e se denomina e e QPSK (Quadrature Phase Shift Keying). Desse modo, a tcnica de modulao e ca determina o nmero de bits/s u mbolo. Todos os modens avanados utilizam uma combinao de tcnicas de modc ca e ulao para transmitir vrios bits por baud. Com freqncia, vrias amplica a ue a tudes e vrios deslocamentos de fase so combinados para transmitir diversos a a bits/s mbolo. A gura 27.8 (b) abaixo apresenta uma estrutura de modulao ca na qual so usadas quatro amplitudes e quatro fases, dando um total de 16 coma binaes diferentes. Esse esquema de modulao pode ser usado para transmitir co ca 4 bits por s mbolo. Ele chamado QAM-16 (Quadrature Amplitude Modulae tion). A gura 27.8 (c) permite 64 combinaes diferentes. Diagramas como os co apresentados na gura 27.8 so denominados de diagramas de constelao. a ca
Figura 27.8: QPSK, QAM 16 e QAM 64 Com muitos pontos no padro de constelao, at mesmo uma pequena a ca e quantidade de ru na amplitude ou fase detectada pode resultar em um erro do e, potencialmente, em muitos bits incorretos. Para reduzir a chance de um erro, efetuada a correo de erros adicionando bits extras a cada amostra. Os e ca esquemas so conhecidos como TCM (Trellis Coded Modulation). a
27.7.2
Modulao de Pulsos ca
A modulao por pulsos iniciou a partir da teoria da amostragem, a qual estabca elece que a informao contida em qualquer sinal analgico pode ser recuperada ca o a partir de amostras do sinal tomadas a intervalos regulares de tempo. A modulao por pulsos pode ser analgica ou codicada. No caso analgico, ca o o os valores das amostras do sinal so transferidos para as amplitudes, duraes a co ou posies de pulsos de formato xo conhecido. No caso digital, os valores das co amostras so convertidos para nmeros binrios que por sua vez so codicados a u a a em seqncias de pulsos que representam cada um dos valores binrios. Um ue a exemplo desse tipo de modulao o PCM. ca e
279
Modulao de Cdigo de Pulso ca o O processo de transformao das redes telefnicas em redes totalmente digitais ca o tanto no que diz respeito ` comutao como ` transmisso teve in quando a ca a a cio da introduo, em escala comercial, dos sistemas de transmisso PCM. O PCM ca a (Modulao por Cdigo de Pulso) transforma um sinal analgico em uma srie ca o o e de pulsos binrios que podem ser manipulados. Sendo assim, o objetivo da moda ulao PCM fazer com que um sinal analgico possa ser transmitido atravs ca e o e de um meio f sico com transmisso digital. a O processo de modulao PCM consiste basicamente em trs etapas, nessa ca e ordem: amostragem, quantizao e codicao. A gura 27.9 ilustra o processo ca ca de modulao PCM, passo a passo. Uma etapa adicional chamada compresso ca a pode ser inserida aps a etapa de quantizao para manipular a sa desse o ca da processo e transform-lo em uma quantizao no-linear, melhorando assim a a ca a robustez a problemas de ru no canal. do
Figura 27.9: Pulse Code Modulation O sinal PCM resultante enviado atravs do canal por transmisso em e e a banda base. Esse sinal ainda pode usar alguma das tcnicas de codicao de e ca linha apresentadas anteriormente, como, por exemplo, a AMI que, inclusive, foi desenvolvida originalmente para esse m. Cabe ressaltar que o processo de codicao do PCM tem a funo de transformar os valores quanticados ca ca em uma seqncia de bits. Essa seqncia de bits constitui o sinal PCM que ue ue pode ser transmitido pelo canal. Entretanto, o sinal PCM pode ser codicado novamente, mas agora usando uma tcnica de codicao de linha para ento e ca a ser transmitido pelo canal.
27.8
Tcnicas de Multiplexao e ca
Multiplexao a transmisso simultnea de vrios sinais por um unico canal. ca e a a a Desse modo, vrias fontes com esquemas de modulao individuais podem ser a ca multiplexados em um mesmo canal. O objetivo bsico para a utilizao desta a ca
280
tcnica economia, pois utilizando o mesmo meio de transmisso para diversos e e a canais economiza-se em linhas, suporte, manuteno, instalao, etc. ca ca
Figura 27.10: Multiplexao de 3 fontes ca As principais tcnicas de multiplexao so FDM, TDM e WDM. Cada uma e ca a delas sero discutidas a seguir. a
27.8.1
FDM - Frequency Division Multiplexing
Com a tcnica FDM (Frequency Division Multiplexing) a multiplexao ree ca e alizada dividindo todo o espectro de freqncia em diversos canais mais estreue itos que so alocadas entre os terminais em uma relao um para um. Bana ca das de guarda so usadas entre subportadoras adjacentes para no ocorrer soa a breposio, entretanto parte da capacidade de transmisso desperdiada para ca a e c esse m. Alm disso, FDM utilizada apenas em sistemas analgicos. A Figura e e o 27.11 ilustra a tcnica segundo os eixos de tempo e freqncia. e ue
Figura 27.11: FDM - Frequency Division Multiplexing
27.8.2
TDM - Time Division Multiplexing
A tcnica de multiplexao TDM (Time Division Multiplexing) baseada no e ca e dom nio do tempo e s pode ser empregado em sistemas digitais. Nesse eso quema, a linha do tempo dividida em quadros que por sua vez dividida em e e slots. Dessa forma, o acesso ao meio garantido atravs da alocao desses e e ca slots de tempo entre as estaes que compe o sistema. E mais eciente em co o comparao ao sistema anterior, entretanto necessita acrescentar bits adicionais ca ao sinal original para sincronia e gerenciamento da rede. A Figura 27.12 ilustra o esquema.
27.8.3
OFDM
O mtodo de multiplexao OFDM uma tcnica de transmisso multiportae ca e e a dora que surgiu no m da dcada de sessenta como uma evoluo de FDM. e ca
281
Figura 27.12: TDM - Time Division Multiplexing O princ pio bsico em OFDM eleger freqncias ortogonais entre si, dito de a e ue outra forma, deve-se garantir que nenhuma subportadora seja produto de combinao linear das demais presentes no canal. Isso permite prescindir da banda ca de guarda presente na tcnica FDM. O benef imediato obtido com OFDM e cio e a economia de largura de banda. Essa tcnica particularmente util nos casos e e de transmisses sem o, pois alm da ecincia espectral, a tcnica OFDM se o e e e apresenta mais robusta em relao aos problemas inerentes ao canal sem o. ca
Figura 27.13: Comparao entre uso de banda FDM e OFDM ca
27.8.4
WDM -Wavelength Division Multiplexing
A tcnica WDM (Wavelength Division Multiplexing) uma variao da mule e ca tiplexao por diviso de freqncia empregada em canais de bra ptica. As ca a ue o informaes so transportadas sobre faixas de comprimentos de onda por meio co a da tecnologia fotnica. o Nesse contexto, os sinais transmitidos so combinados em um multiplexador a o ptico para ser enviado atravs de um unico cabo de bra ptica. Dessa forma, e o a capacidade de transmisso aumentada e a largura de banda da bra usada a e e efetivamente. A gura 27.14 representa o esquema de multiplexao por diviso ca a de comprimento de onda.
Figura 27.14: WDM -Wavelength Division Multiplexing
282
27.9
Protocolos de Acesso M ltiplo u
Basicamente existem dois tipos de enlaces: ponto-a-ponto e broadcast. O primeiro caso consiste em um unico remetente em uma extremidade do en lace e um unico receptor na outra extremidade do enlace. O segundo tipo pode ter mltiplos ns remetentes e receptores, todos conectados ao mesmo, u o unico compartilhado canal de transmisso. Nesse contexto surge uma questo: a a como coordenar o acesso dos mltiplos ns remetentes e receptores a um canal u o broadcast compartilhado. Essa coordenao realizada pelos protocolos de ca e acesso mltiplo. Formalmente, podem-se classicar esses protocolos em: prou tocolos protocolo de alocao xa (tambm chamado protocolo de diviso do ca e a canal), protocolos de acesso aleatrio e protocolo de alocao dinmica (tambm o ca a e chamado protocolo de revezamento). Os protocolos de alocao xa caracterizam-se por atribuir uma parte do ca canal para cada estao, de maneira xa. O TDMA (Time-Division Multiple Acca cess, baseado na tcnica de multiplexao TDM) e o FDMA (Frequency-Division e ca Multiple Access, baseado na tcnica de multiplexao FDM) so exemplos deste e ca a tipo de protocolo. So extremamente fceis de implementar. Porm, quando a a e uma estao no tem pacotes para enviar durante o per ca a odo de tempo em que o meio est alocado para ela, o canal car ocioso enquanto outros terminais a a poderiam estar utilizando-o. Por outro lado, os protocolos de acesso aleatrio no possuem um controle o a r gido para alocao do canal. O ALOHA e o CSMA (Carrier Sense Multiple ca Access) so exemplos desta categoria. Tambm so relativamente simples de a e a implementar, porm, a possibilidade de ocorrer colises quando duas ou mais e o estaes tentam transmitir ao mesmo tempo provoca desperd co cio no canal de transmisso. a Nos protocolos de alocao dinmica o canal alocado de acordo com as ca a e necessidades das estaes. Este controle pode ser implementado de vrias co a maneiras, como por exemplo: na forma de polling (onde uma estao espera ser ca questionadase necessita acessar o canal), ou na forma de reservas expl citas, como no RPAC (Reservation-Priority Access Control). Com a utilizao destes ca protocolos no existe a possibilidade de colises e o canal alocado sob dea o e manda, evitando per odos de tempo ociosos no canal. Porm, h uma sobree a 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 sim no a no a Colises o no a sim no a Sobrecarga no a no a sim
Alocao Fixa ca Acesso Aleatrio o Alocao Dinmica ca a
Tabela 27.1: Alocao de Canais ca
283
Cap tulo 28
Topologias de Redes
A topologia de uma rede de comunicao refere-se ` forma como os enlaces ca a f sicos e os ns esto organizados, determinando os caminhos f o a sicos existentes e utilizveis entre quaisquer pares de estaes conectadas a essa rede. A topologia a co de uma rede muitas vezes caracteriza o seu tipo, ecincia e velocidade. As e topologias mais comuns so as seguintes: a Malha A interconexo total garantindo alta conabilidade, porm a complexia e e dade da implementao f ca sica e o custo inviabilizam seu uso comercial; Estrela A conexo feita atravs de um n central que exerce controle sobre a a e e o comunicao. Sua conabilidade limitada ` conabilidade do n central, ca e a o cujo mau funcionamento prejudica toda a rede; Barramento As estaes so conectadas atravs de um cabo com difuso da informao co a e a ca para todos os ns. E necessria a adoo de um mtodo de acesso para o a ca e as estaes em rede compartilharem o meio de comunicao, evitando co ca colises. E de fcil expanso, mas de baixa conabilidade, pois qualquer o a a problema no barramento impossibilita a comunicao em toda a rede; ca Anel O barramento toma a forma de um anel, com ligaes unidirecionais ponto co a ponto. A mensagem repetida de estao para estao at retornar ` e ca ca e a estao de origem, sendo ento retirada do anel. Como o sinal recebido ca a e por um circuito e reproduzido por outro h a regenerao do sinal no meio a ca de comunicao; entretanto h tambm a insero de um atraso a cada ca a e ca estao. O trfego passa por todas as estaes do anel, sendo que somente ca a co a estao destino interpreta a mensagem; ca Arvore E a expanso da topologia em barra herdando suas capacidades e limitaes. a co O barramento ganha ramicaes que mantm as caracter co e sticas de difuso a das mensagens e compartilhamento de meio entre as estaes; co
284
Mistas Combinam duas ou mais topologias simples. Alguns exemplos so o de esa trelas conectadas em anel e as rvores conectadas em barramento. Procua ram explorar as melhores caracter sticas das topologias envolvidas, procurando em geral realizar a conexo em um barramento unico de mdulos a o concentradores aos quais so ligadas as estaes em conguraes mais a co co complexas e mais conveis. a
Figura 28.1: Topologias de Rede
285
Cap tulo 29
Arquitetura de Redes
29.1 Organizao em Camadas ca
Para reduzir a complexidade do projeto, a maioria das redes organizada como e uma pilha de camadas colocadas umas sobre as outras. O nmero de camadas u e suas funes podem ser diferentes de uma rede para outra. No entanto, em co todas as redes o objetivo principal da implementao em camadas fazer com ca e que uma camada oferea servios `s camadas superiores, isolando a camada c c a superior dos detalhes de implementao. A camada n de uma mquina se coca a munica com a camada n de outra mquina utilizando um conjunto de regras a e convenes chamado protocolo. Essas entidades situadas em mquinas diferco a entes so chamadas de pares. Na verdade, a camada n de uma mquina no a a a se comunica com a camada n da outra mquina diretamente. As informaes a co so passadas para as camadas inferiores at que se alcance a camada mais baixa. a e Abaixo desta est o meio f a sico atravs do qual a comunicao propriamente e ca dita ocorre. Entre as camadas adjacentes existe uma interface. A interface dene o conjunto de operaes e servios que a camada inferior pode oferecer co c a camada imediatamente superior. Em uma arquitetura em camadas deve-se estarem bem denidos quais so as funes de cada uma das camadas. a co Este tipo de arquitetura proporciona a independncia das camadas pere mitindo que a implementao de uma camada possa ser totalmente substitu ca da tendo como unico requisito da nova implementao oferecer no m ca nimo os mesmos servios oferecidos pela implementao anterior. Uma arquitetura em cac ca madas deve se preocupar com diversos aspetos como: Endereamento, Modo de c Transmisso(Simplex,Half-Duplex,Full-Suplex), Canais Lgicos(Dados,Controle), a o Controle de Erros, Controle de Fluxo, Fragmentao / Montagens, Multiplexao ca ca / Demultiplexao e Roteamento. ca
286
Cap tulo 30
Protocolos de Rede
30.1 ARP - Address Resolution Protocol
O protocolo ARP destinado a realizar a associao entre um endereo de e ca c camada 3 e um endereo de camada 2. O endereo de camada 3 um enc c e dereo lgico e est relacionado com protocolos como IP, IPX, Appletalk,etc. O c o a endereo mac um endereo f c e c sico que est relacionado com a interface de harda ware. Um computador pode ter inmeros endereos de camada 3 por interface, u c porem s pode ter um endereo f o c sico por interface de rede. Quando o computador tem dados para enviar para algum destinatrio repa resentado por um endereo IP, por exemplo, ele encapsula esses dados em um c pacote IP e ento tem que realizar algumas etapas antes de enviar. Primeiro ele a verica se o endereo IP destino pertence ou no a mesma rede em que ele est c a a conectado. Em caso armativo, ele precisa ento determinar qual o endereo a c f sico correspondente ao endereo IP destino, para que ento possa encapsular c a o pacote IP em um frame e coloc-lo no meio de transmisso. Para determinar a a o endereo f c sico destino o computador primeiramente verica se existe uma entrada em sua tabela de Cache de ARP. Caso exista,ele encapsula o pacote IP em um frame e envia, caso contrrio necessrio que se envie uma mensagem a e a ARP em broadcast com a seguinte pergunta: Quem possui o endereo IP end? c Todas as mquinas da rede local iro receber a mensagem e analisar o contedo. a a u Aquela que possuir endereo end responder a mensagem arp enviando seu enc a dereo f c sico.
30.2
DHCP - Dynamic Host Conguration Protocol
O DHCP (Dynamic Host Conguration protocol) um protocolo que objee tiva realizar a congurao dinmica de hosts em uma rede ou na Internet. O ca a DHCP consiste de dois componentes bsicos que so um protocolo para trocar a a mensagens e transportar informaes relativas a conguraes do host e um co co mecanismo para controlar a alocao de endereos de rede. ca c
287
O DHCP baseado no modelo cliente-servidor, onde o cliente requisita os e parmetros de congurao e os servidores recebem os pedidos, os analisa e prove a ca as conguraes para os hosts. Vale ressaltar que poss a coexistncia de co e vel e mais de um servidor DHCP em uma rede. Tambm poss e e vel o servidor DHCP estar fora da rede em que se encontram os hosts solicitantes (clientes). Neste caso, necessria a instalao de um e a ca agente de retransmisso DHCP (DHCP Relay Agent). A unica informao que a ca este agente precisa ter o endereo IP do servidor DHCP que est fora da rede. e c a As trs formas de assinalar um endereo IP so: e c a Alocao Automtica - um endereo IP fornecido para de forma permaca a c e nente pelo servidor de DHCP; Alocao Dinmica - as conguraes do host so fornecidas por um deca a co a terminado per odo de tempo chamado lease. As conguraes podem co ser canceladas antes desse per odo expirar caso seja de interesse do host; Alocao Manual - as conguraes do host so ajustadas manualmente ca co a pelo administrador da rede. Em geral em uma rede essas formas de assinalar endereos so utilizadas c a em conjunto. Entre os requisitos de um servio de DHCP em uma rede esto: c a garantir que um mesmo endereo no estar em uso mais de um host ao mesmo c a a tempo; estar preparado para funcionar em mais de um em uma rede de forma aumentar a performance e redundncia; estar preparado para lidar com hosts a estaticamente congurados. Entre os parmetros de congurao fornecidos pelo DHCP, esto, o ena ca a dereo de rede, a mscara de subrede, o tempo de durao da licena (lease), c a ca c endereo do gateway padro, endereo dos servidores de DNS, etc. c a c A alocao dinmica de endereo o mais importante servio fornecido pelo ca a c e c DHCP. Para um host adquirir conguraes as seguintes etapas so necessrias: co a a Um cliente faz um broadcast de uma mensagem DHCPDISCOVER para na sua rede local f sica. Caso o servidor de DHCP no esteja naquela rede a f sica, os agentes relay encaminham as mensagens para frente atravs dos e roteadores; Os servidores recebem a mensagem DHCPDISCOVER e respondem com uma mensagem DHCPOFFER com as conguraes que ele pode fornecer; co O cliente recebe uma ou mais mensagem DHCPOFFER e escolhe qual delas responder enviando um broadcast da mensagem DHCPREQUEST a indicando qual servidor escolheu e possivelmente adicionando novos requisitos de congurao; ca O servidor recebe a mensagem DHCPREQUEST e checa em sua base de dados se poss e vel fornecer as conguraes desejadas pelo host. Caso co seja poss vel, envia uma mensagem com o DHCPACK, seno envia um a 288
DHCPNAK. O processo reiniciado aps um tempo determinado por e o backo exponencial; O host, caso tenha recebido ACK, checa as conguraes fornecidas usco ando ARP, por exemplo, e caso detecte que conguraes no so vlidas, co a a a envia uma mensagem do tipo DHCPDECLINE, cancelando a negociao. ca
30.3
DNS - Domain Name System
Originalmente, o mapeamento de nomes em endereos era todo registrado em c um unico arquivo chamado HOSTS.TXT. Esse arquivo era gerenciado por uma entidade chamada NIC (Network Information Center). A distribuio das atca ualizaes desse arquivo era feita via FTP, o que consumia uma banda muito co grande. O perl do usurio de redes e da Internet mudou muito, ocorrendo um a grande crescimento das redes locais, com suas prprias necessidades de mapear o nomes que s faziam sentido em seus ambientes. O perl das aplicaes de Ino co ternet tambm evoluiu bastante, surgindo a necessidade de se criar um sistema e de mapeamento de nomes mais geral e eciente. Foi neste contexto que surgiu o DNS. O DNS (1) um banco de dados distribu implementado em uma hiere do arquia de servidores de nome, e (2) um protocolo de camada de aplicao que ca permite que hospedeiros consultem o banco de dados distribu do. Para tratar a questo da escala, o DNS usa um grande nmero de servidores organizados, a u de maneira hierrquica e distribu a da, por todo o mundo. Os principais componentes do DNS so: a Domain Name Space (Espao de Nomes): uma especicao para uma c e ca a rvore estruturada para armazenar os espaos de nomes. Esta rvore c a e dividida em ZONAS no-superpostas. Normalmente, cada zona tem um a servidor de nome principal (onde os registros so mantidos em disco) e um a ou mais servidores secundrios; a Resource Records (Registro de Recursos): A principal funo do DNS ca mapear nomes de dom e nios em registros de recursos (no somente ena dereo IP). Um registro de recurso uma tupla de cinco campos: Doc e main name (normalmente existem muitos registros, de tipos diferentes, para cada dom nio); Time to live (tempo de vida do registro); Class (IN quando relacionado ` Internet, outros cdigos so raramente encontraa o a dos); Type (tipo de registro); e Value (sua semntica depende do tipo de a registro). Os tipos de registros existentes so: a Name Servers (Servidores de Nomes): so programas servidores que detm a e informao sobre a estrutura da rvore de dom ca a nio e tambm tem a cae pacidade de registrar informaes. Resumidamente, h quatro classes de co a servidores de nomes: servidores de nomes raiz (cerca de 13 servidores); servidores DNS de dom de n superior (.int, .com, .mil, .net, .br, .jp, nio vel etc. - cerca de 200 servidores); servidores DNS com autoridade (chamados de AUTHORITH - os que detm os registros de recursos de servidores, e localizados em sua zona, que podem ser acessados publicamente); e servidores intermedirios; a 289
Tipo SOA A MX NS CNAME PTR HINFO TXT
Signicado In de autoridade cio Endereo IP de um host Inc teiro de 32 bits Troca de mensagens de correio Servidor de nomes Nome cannico o Ponteiro Descrio de host ca Texto
Valor Parmetro para essa zona a
Prioridade, dom nio disposto a aceitar correio eletrnico o Nome de um servidor para este dom nio Nome de dom nio Nome alternativo de um endereo IP c CPU e sistema operacional em ASCII Texto ASCII noa interpretado
Tabela 30.1: Principais tipos de registros de recursos do DNS para o IPv4 Resolvers (Resolvedores): so programas, executados tanto nos clientes a quanto nos servidores, que extraem informaes dos Name Servers em co resposta a requisies feitas por clientes. Esses programas so aptos a co a responder as queries diretamente ou ento encaminhar a queries caso a a informao no esteja dispon naquele Name Server. So programas que ca a vel a podem ser acessados diretamente por programas de usurios ou rotinas do a sistema operacional sem a necessidade de utilizao de protocolos; ca Cache DNS: uma caracter stica muito importante usada para aumentar o desempenho quanto a atraso e reduzir o nmero de mensagens DNS na Inu ternet. Em cada elemento da cadeia (cliente, servidores local, secundrios, a primrios, com autoridade, de n superior, etc.) informaes (registros) a vel co de respostas podem ser armazenadas em memria local. Para evitar o uso o de registros desatualizados, associado a cada registro um nmero TTL e u (Time to Live) que determina seu tempo de vida; Existem dois mtodos de consulta: recursiva, onde cada servidor que no e a tiver as informaes solicitadas poder encontr-las, por meio de novas consulco a a tas, em algum lugar e informar ao solicitante o que encontrou. Iterativa, onde quando a consulta no pode ser satisfeita no local, haver uma falha, mas a a e retornado o nome do prximo servidor a ser consultado, pelo solicitante, ao o longo da linha. Para cada consulta, os tipos bsicos de resposta so: authoritaa a tive answer (consulta resolvida pelo servidor com autoridade); positive answer; referral answer (no contm resoluo da consulta, e sim uma referncia para a e ca e uma nova consulta - usada no mtodo iterativo); e negative answer (ou o nome e pesquisado no existe ou o tipo de registro no confere - sempre indicado pelo a a servidor com autoridade). E importante observar que o DNS no somente prov o servio de traduo a e c ca de nomes em endereos IPs. Ele tambm prov outros servios mais sosticados, c e e c tais como: 290
Distribuio de carga: implementado por meio do tipo de registro A com ca mais de um IP de servidores replicados (ex. Web ou FTP) utilizados na distribuio de carga. Ao resolver o nome, o DNS faz um rod entre os ca zio 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 resoluo de nomes e TCP/53 para realizar ca transferncia de zonas. e O nome completo de um host da rede conhecido como FQDN - Full Qualie ded Domain Name. Por exemplo, ftp.abc.com.br um FQDN. ftp (a primeira e parte do nome) o nome de host e o restante representa o dom DNS no qual e nio est o host. a Dica Importante: O administrador do servidor DNS local pode desabilitar o recurso de recurso em um servidor DNS em situaes onde os usurios devem a co a estar limitados a utilizar apenas o servidor DNS da Intranet da empresa. Desta forma, somente os endereos internos (armazenados no disco do servidor DNS c local - AUTHORITH) sero resolvidos. a O nslookup uma ferramenta, comum ao Windows e ao Linux, utilizada e para se obter informaes sobre registros de DNS de um determinado dom co nio, host ou IP. Podemos utilizar esta ferramenta em dois modos diferentes. No modo direto, onde digitamos o comando nslookup e mais alguns parmetros, e a no modo interativo, onde digitamos somente o comando nslookup e um prompt aberto para que sejam realizadas consultas ao servidor DNS. Alguns exemplos e de parmetros/consultas so: nslookup nome do host/nomes e endereos do a a c servidor DNS e do host; nslookup -querytype=ANY nome do host/todas as informaes dispon co veis do servidor DNS e do host.
30.4
TCP - Transmission Control Protocol
O protocolo TCP (Transmission Control Protocol) um protocolo da camada e de transporte cujo principal objetivo prover um servio de conexo convel e c a a entre um par de processos que desejam se comunicar. prover facilidades como transferncia bsica de dados, controle de uxo, multiplexao, precedncia, e a ca e controle de conexes, e alguma segurana. A expresso conexo convel est o c a a a a relacionada com a capacidade do protocolo TCP em lidar com dados danicados, perdidos ou duplicados utilizando para isso nmeros de seqncia, ACKs, u ue buers de retransmisso. O TCP implementa tambm a multiplexao para a e ca permitir que mltiplos processos utilizem as facilidades do TCP em um mesmo u host. Para isso utiliza um identicador de conexo chamado soquete, que a e formado pela porta e endereo de rede. c
291
O cabealho do TCP formado pelos seguintes campos: (i) Source Port c e - porta de origem; (ii) Destination Port - porta de destino; (iii) Sequence Number - numero de seqncia do segmento; (iv) Acknowledgment Number ue - o numero de seqncia que o sender do segmento espera receber; (v) Data ue Oset - Indica onde os dados comeam. Mltiplo de 32 bits; (vi) Control c u Bits - (URG/ACK/PSH/RST/SYN/FIN); (vii) Window - tamanho da janela aceitvel. Indica range de nmeros de seqncia aceitos; (viii) Checksum a u ue Checksum calculado sobre headers e dados; (ix) Urgent Pointer - Indica o oset dos dados urgentes em um dado segmento. S tem sentido com o ag URG seo tado. (x) Options: opes adicionais (Ex: Maximum Segment Size. Esta opo co ca s deve ser utilizada no estabelecimento da conexo. Caso contrrio qualquer o a a tamanho de segmento aceito); (xi) Padding - usado para garantir que o header e seja mltiplo de 32 bits e o campo data oset trabalhe corretamente. u Para manter uma conexo TCP necessrio que se guarde o status de vrias a e a a variveis referentes a recebimento e envio de segmentos, informaes sobre o a co segmento corrente, informao sobre o estado da conexo e identicador da ca a conexo. Todas essas conexes so guardadas em uma estrutura chamada TCB a o a - Transmission Control Block. Entre as informaes guardadas nos TCBs esto, co a por exemplo, o tamanho da janela, numero de seqncia inicial da conexo e o ue a estado dos bits de controle. As conexes TCP podem se encontrar nos seguintes estados: o LISTEN - A espera de um pedido de conexo; a SYN-SENT - A aplicao comeou a abrir uma conexo; ca c a SYN-RECEIVED - Uma solicitao chegou. Espera por um ack; ca ESTABILISHED - Estado normal para envio de dados; FIN-WAIT-1 - A aplicao informou que acabou de transmitir; ca 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 conexo passa de um estado para o outro em resposta a eventos que so a a as chamadas as funes OPEN, SEND, RECEIVE, CLOSE, ABORT, STATUS co ou ento segmentos contendo ags SYN, ACK, RST, e FIN, alm dos timeouts. a e As duas causas de congestionamento so a sobrecarga na rede e a sobrea carga no receptor. E necessrio lidar com cada uma das causas separadamente. a Se o mecanismo de Janela de Transmisso for obedecido pelo transmissor, no a a haver problemas devido a sobrecarga de buers mas somente devido a congesa tionamentos internos da prpria rede. Para isso utiliza-se uma segunda janela o 292
chamada Janela de Congestionamento. O valor m nimo entre essas janelas reete o numero mximo de bytes que um a transmissor pode enviar. O mecanismo de janela de congestionamento funciona da seguinte maneira: Ao estabelecer a conexo o valor da janela de congestiona amento setado para o valor mximo do segmento (MSS) cordado na conexo. e a a E feita ento a transmisso de um segmento de tamanho MSS. Caso no tenha a a a ocorrido timeout, o valor da janela de congestionamento aumentado para duas e vezes o anterior. Esse procedimento segue at que uma transmisso resulte em e a timeout. Caso isso ocorra o procedimento reiniciado a partir do valor inicial. e Esse um algoritmo exponencial. Existe uma variante que permite a utilizao e ca de um limiar a partir do qual o crescimento passa a ser linear e no exponencial. a Na internet essa tcnica utilizada. e e O mecanismos de abertura de conexo conhecido como Three-Way Handa e 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 so: Timer de Retransmisso - responsvel a a a por indicar se um segmento deve ser retransmitido; Timer de Persistncia e utilizado para evitar o impasse quando o anuncio do tamanho de janela se perder, Timer de keepAlive - pode expirar quando uma conexo ca inativa por a muito tempo.E feita ento uma checagem para ver se o outro lado ainda est a a ativo; TIME WAIT - utilizado no estado da conexo. a
30.5
UDP - User Datagram Protocol
O UDP um dos principais protocolos da Internet. E um protocolo destinado e ao envio de mensagens custas. Por isso se diz que ele um protocolo orientado a e mensagens e tambm stateless. No proporciona nenhuma garantia de entrega e a nem ordenao. No entanto, muito mais leve e eciente do que o TCP. Esse ca e um dos motivos pelos quais o UDP muito utilizado em aplicaes sens e e co veis ao tempo. Entre as inmeras aplicaes do protocolo UDP esto os servios de RIP, u co a c SNMP, DHCP, DNS, VoIP, jogos online, aplicaes de multim co dia, entre outras. Em um servio de transmisso de voz, a retransmisso do dado no c a a a e util devido ao atraso, assim como em uma transmisso de v a deo. E um protocolo da camada de transporte e possui um cabealho simplicado com apenas c 4 campos que so:(i)Source Port;(ii) Destination Port;(iii)Lenght;(iv)Checksum. a Cada um formado por 16 bits. Os campos Source Port e Checksum so e a opcionais. Na prtica, o campo quase sempre utilizado, enquanto o campo a e Source Port pode ser utilizado quando se deseja receber uma resposta. E importante lembrar que na comunicao UDP no existem mensagens de conrmao. ca a ca Quando essas ocorrem se devem a iniciativa da aplicao que est utilizando o ca a UDP e no das regras de comunicao do protocolo em si. Exemplo: Uma a ca querie DNS enviada ao servidor que por sua vez responde utilizando tambm e e 293
uma mensagem UDP. Como o campos Source Port opcional, caso no seja preenchido, no moe a mento do calculo do Checksum ele considerado 0. Nos casos em que o Checke sum tambm no calculado, o valor enviado consiste em 16 bits 0. Caso o e a e checksum calculado seja 16 bits 0, o valor do checksum enviado composto por e 16 bits 1.
30.6
HTTP - Hyper Text Transfer Protocol
E o protocolo de CAMADA DE APLICACAO da Web denido no RFC 1945 (HTTP 1.0) e no RFC 2616 (HTTP 1.1). Ele implementado em dois proe gramas, um cliente e outro servidor, portanto, ele classicado como aplicao e ca cliente-servidor. Estes dois programas, executados em sistemas nais distintos, conversam entre si por meio de troca de mensagens HTTP. O HTTP dene a estrutura dessas mensagens e o modo como o cliente e o servidor as trocam. Uma pgina Web (ou documento) constitu de OBJETOS. Um objeto a e da e simplesmente um arquivo. Exemplos de objetos so: arquivo HTML, imagem a JPEG, imagem GIF, applet JAVA, etc. Cada objeto referenciado por uma e unica 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/gura.gif, www.universidade.br o nome do hospedeiro e /departamento/gura.gif o e e nome do caminho do objeto. Um BROWSER um AGENTE DE USUARIO para a Web. Eles implee mentam o lado cliente do HTTP a m de apresentar pginas Web e fornecer a numerosas caracter sticas de navegao e de conrmao. Vale salientar que ca ca dois browsers distintos podem apresentar pginas Web de formas ligeiramente a diferentes, pois o protocolo HTTP no dene nada sobre apresentao. Os a ca SERVIDORES WEB implementam o lado servidor do HTTP a m de abrigar objetos Web. Os Servidores Web mais utilizados atualmente so os Apache e o a Microsoft Internet Information Server (IIS). O HTTP usa o TCP como seu protocolo de transporte. Por padro, as pora tas utilizadas so as 80 (primria) e 8080 (alternativa). Desta forma, as trocas a a de mensagens so realizadas de forma orientada a conexo. Estas conexes poa a o dem ser persistentes ou no-persistentes. a As conexes no-persistentes seguem o seguinte uxo: o a O processo cliente abre uma conexo TCP executando a APRESENTACAO a DE TRES VIAS (three way handshake); Durante a terceira via do three way handshake, o processo cliente envia uma mensagem de requisio HTTP ao servidor; ca O processo servidor recebe a mensagem de requisio, encapsula o objeto ca requisitado em uma mensagem de resposta HTTP, e a envia ao cliente; O processo servidor solicita o encerramento da conexo TCP; a 294
Aps o tempo de transmisso da mensagem resposta, o processo cliente o a recebe a mensagem de resposta, extrai o arquivo da mensagem de resposta e o apresenta. Desta forma, para cada objeto transferido h a exigncia de abertura de a e uma nova conexo TCP. Como geralmente as pginas Web so consistidas de a a a um arquivo-base HTML e diversos objetos referenciados, este tipo de conexo a se mostrou um tanto quanto ineciente. O tipo de conexo persistente permite um aumento considervel na ecincia a a e das trocas de mensagens. Neste tipo de conexo, o servidor deixa a conexo TCP a a aberta aps enviar resposta. Ou seja, requisies e respostas subseqentes entre o co u os mesmos cliente e servidor podem ser enviadas por meio da mesma conexo. a Em geral, o servidor HTTP fecha uma conexo quando ela no usada durante a a e certo tempo (congurvel). a H duas verses de conexes persistentes: SEM PARALELISMO e COM a o o PARALELISMO. Na verso sem paralelismo, o cliente emite uma nova reqa uisio somente quando a resposta anterior foi recebida. O modo default do ca HTTP usa conexes persistentes com paralelismo. Nesse caso, o cliente emite o uma requisio logo que encontra uma referncia, mesmo antes de receber uma ca e resposta a uma requisio anterior (PIPELINE). ca Uma outra forma de paralelismo o cliente abrir conexes paralelas com um e o servidor. Nos modos default, a maioria dos browsers abre de cinco a dez conexes o TCP paralelas, cada uma delas manipula uma transao requisio/resposta. ca ca E importante salientar que o servidor envia as respostas HTTP ao cliente sem armazenar nenhuma informao de estado sobre este. Se um determinado ca cliente solicita o mesmo objeto duas vezes em um per odo de poucos segundos, o servidor no responde dizendo que acabou de enviar o objeto. Em vez disso, a ele envia novamente o objeto ao cliente. Em outras palavras, o HTTP um e PROTOCOLO SEM ESTADO. Como j se pode notar, as mensagens so de dois tipos: mensagem de reqa a uisio e mensagem de resposta. Antes de apresentar os principais campos do ca tipo de mensagem de requisiao, vamos a um exemplo t c pico.
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 escrita em texto ASCII a comum. Embora ela tenha cinco linhas, ela poderia ter de uma a diversas linhas. A primeira linha sempre denominada LINHA DE REQUISICAO. As e subseqentes so denominadas LINHAS DE CABECALHO. A linha de requ a uisio composta por trs campos: o campo do METODO; o da URL; e o da ca e e VERSAO do HTTP. A linha de cabealho Host especica o hospedeiro no qual o c
295
objeto reside (este campo utilizado para buscar objetos em servidores proxy). e Ao incluir a linha de cabealho Connection: close, o browser est encerrando c a a conexo. A linha de cabealho User-agent especica o agente de usurio, ou a c a seja, o tipo de browser (o servidor pode enviar verses diferentes de um mesmo o objeto). Por m, o cabealho Accept-language mostra que o usurio prefere c a receber uma verso em francs do objeto se este existir. a e O formato geral de uma mensagem de requisio mostrado na gura abaixo. ca e
Figura 30.1: Formato geral de uma mensagem de requisio HTTP ca Agora que j apresentamos um exemplo de mensagem de requisio, vamos a ca a um exemplo t pico 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 trs sees: a LINHA DE ESTADO; seis LINHAS DE e co CABECALHO; e CORPO DA ENTIDADE (contm os objetos propriamente e ditos). A linha de estado tem trs campos: o campo da VERSAO do HTTP; um e CODIGO DE ESTADO; e uma MENSAGEM de texto correspondente. A linha de cabealho Connection: close indica que o servidor fechar a conexo aps o c a a o envio da mensagem. A linha de cabealho Date indica a hora e a data em que c a resposta foi criada e enviada pelo servidor (no se refere ` data de criao do a a ca objeto nem de sua ultima alterao). A linha de cabealho Server mostra por ca c qual tipo de servidor a mensagem foi criada. A linha de cabealho Last-Modied c indica a hora e a data em que o objeto foi criado ou sofreu a ultima modicao ca (fundamental para a implementao de servidores proxy). A linha de cabealho ca c Content-Length indica o nmero de bytes do objeto que est sendo enviado. u a Por m, a linha de cabealho Content-Type mostra o tipo de objeto presente c 296
no corpo da mensagem. E importante notar a linha em branco antes do corpo da entidade. Esta linha obrigatria e indica que no h mais nenhuma linha e o a a de cabealho. c O formato geral de uma mensagem de resposta mostrado na gura abaixo. e
Figura 30.2: Formato geral de uma mensagem de resposta HTTP Os mtodos implementados pelo HTTP 1.1 so: e a GET - Este mtodo solicita um objeto, identicado por uma URL ine dicada na mensagem de requisio. Um GET condicional um tipo ca e espec co de GET. Ele deve possuir pelo menos uma linha de cabealho c do tipo If-Modied-Since ou If-UnModied-Since. De uma forma geral, ele permite melhorar o desempenho transmitindo apenas os dados que atendem determinada condio. Existe tambm o GET parcial que ca e permite que apenas parte da informao seja transmitida. Isso pode ser ca utilizado quando o cliente j possui uma parte dos dados. Para isso o a campo Range do cabealho deve ser preenchido. A grande maioria das c mensagens de requisio tem a forma de mtodo GET; ca e HEAD - Este mtodo semelhante ao GET, contudo utilizado para e e e trazer apenas os cabealhos da mensagem que so exatamente os retornac a dos pelo GET e no os objetos requisitados; a POST - Este mtodo utilizado para acrescentar informaes a uma reqe e co uisio. Por exemplo, quando o cliente preenche algum formulrio de ca a busca. Com esta mensagem, o cliente continua requisitando um objeto (ou objetos), mas seu contedo depende do contedo do formulrio. Os u u a contedos do formulrio so transmitidos no corpo da entidade. OBS: u a a no necessariamente as requisies geradas com um formulrio utilizam o a co a mtodo POST. E poss utilizar o mtodo GET com os contedos do fore vel e u mulrio como parte da URL (ex. www.somesite.com/animalsearch?monkey&bananas); a PUT - Este mtodo solicita o armazenamento de um objeto, enviado no e corpo da entidade, em um diretrio em um determinado Servidor Web o (indicados por uma URL). Na prtica este mtodo no muito utilizado a e a e hoje em dia;
297
DELETE - Este mtodo solicita que um objeto determinado por uma URL e seja deletado no Servidor Web; TRACE - Este mtodo requisita o destino nal a reetir (enviar de volta) e a mensagem que est recebendo. O campo de cabealho Max-Fowards a c pode ser preenchido de forma limitar o nmero de proxies para detectar u poss veis loops; CONNECT: No utilizado atualmente. Ele reservado para uso futuro; a e e OPTIONS: fornece um meio para que o cliente consulte o servidor sobre suas propriedades ou sobre as de um objeto espec co. Os CODIGOS DE ESTADO so cdigos para representar o atual estado do a o servidor. So separados nas seguintes classes: a 1xx (Informational) - Raramente utilizados na prtica. Ex. 100 - Indicam a que servidor concorda em atender ou continuar atendendo requisio do ca cliente; 2xx (Successful) - Indicam que a requisio foi corretamente recebida, ca entendida, aceita e que o contedo (se houver) est sendo retornado. Ex. u a 200 - requisio bem-sucedida; 204 - sem contedo; ca u 3xx (Redirection) - Indica que o cliente deve procurar em outro lugar, usando um URL diferente ou seu prprio cache. Ex. 301 - a pgina foi o a movida; 304 - a pgina no cache ainda vlida; a e a 4xx (Client Error) - Indica um erro do cliente ao fazer a requisio. Ex. ca 403 - pgina; a 5xx (Server Error) - Indica um erro do servidor ao processar a requisio. ca Cabe ressaltar que o HTTP no somente utilizado no contexto Web. Ele a e tambm frequentemente utilizado em aplicaes de comrcio eletrnico para e e co e o transferir arquivos XML de uma mquina para outra, sem que nenhuma dessas a mquinas envolva um browser ou um usurio. O HTTP tambm utilizado para a a e e transferir VoiceXML, WML e outros tipos de XML. Outra utilidade do HTTP servir como protocolo de transferncia de arquivos no compartilhamento de e e arquivos em redes P2P.
Outra observao importante o fato do HTTP no exigir conexes esca e a o pec cas e distintas para transferncia de mensagens de controle e para transe ferncia de mensagens de dados. Desta forma, dizemos que as mensagens de e controle so enviadas NA BANDA. a A verso 1.1 do HTTP totalmente compat com a verso 1.0, contudo a e vel a h algumas diferenas. As duas principais so: a c a A verso 1.0 no suporta conexes persistentes. J a verso 1.1 suporta a a o a a ambos os tipos de conexo, persistente e no-persistente; a a A verso 1.0 permite somente trs tipos de mtodos: GET, POST e a e e HEAD. 298
30.7
SMTP - Simple Mail Transfer Protocol
E o protocolo de CAMADA DE APLICACAO do modelo OSI denido pela RFC 2821. Ele o principal protocolo do correio eletrnico da Internet. Ele e o e implementado em dois programas, um cliente e outro servidor, portanto, ele e classicado como aplicao cliente-servidor. Estes dois programas, executados ca em sistemas nais distintos, conversam entre si por meio de troca de mensagens SMTP. Antes de apresentarmos as principais caracter sticas do SMTP, se faz necessrio a abordar alguns assuntos relevantes a cerca do sistema de correio eletrnico na o Internet. Uma grande caracter stica deste sistema o fato das comunicaes e co serem ass ncronas. Ou seja, as pessoas enviam e recebem mensagens quando for conveniente para elas. Este sistema composto basicamente por trs compoe e nentes: AGENTES DE USUARIOS; SERVIDORES DE CORREIO (tambm e chamado de AGENTE DE TRANSFERENCIA DE MENSAGEM); e o SMTP. Os Agentes de Usurios so executados localmente na mquina do usurio, a a a a permitindo-o a ler, responder, retransmitir, salvar e escrever mensagens. Exemplos de Agentes de Usurios com interface grca so: Eudora, Outa a a look e o Messenger da Netscape. Outros Agentes sem interface grca a so: mail, pine e elm; a Os Servidores de Correio formam o ncleo da infra-estrutura do sistema. u Cada usurio tem uma CAIXA POSTAL. Diversos Agentes de Usurios a a 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 correspondncia para e outros, age como um cliente SMTP. Quando um Servidor de Correio recebe correspondncia de outros, age como um servidor; e O SMTP dene 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 so realizadas de forma orientada a conexo. Por padro, a a a a porta utilizada a 25 e as conexes so sempre persistentes. Ou seja, em uma e o a mesma sesso SMTP, diversas mensagens podem ser enviadas. a
Para ilustrar uma operaao t c pica do SMTP, vamos recorrer a um cenrio a bem comum descrito pela gura 30.3. Suponha que Alice queira enviar a Bob uma simples mensagem ASCII. Os seguintes passos so seguidos: a Alice compe a mensagem e solicita ao seu Agente de Usurio a entregar o a esta mensagem a Bob; O Agente de Usurio de Alice envia a mensagem para seu Servidor de a Correio por meio do SMTP. Esta mensagem ser colocada em uma la a de mensagens. Na verdade, este Agente de Usurio poderia dialogar direa tamente com o Servidor de Correio de Bob, porm na prtica esta no e a a e uma abordagem to comum; a
299
O lado cliente do SMTP, que funciona no Servidor de Correio de Alice, v e a mensagem na la e abre uma conexo TCP para um servidor SMTP, que a funciona no Servidor de Correio de Bob. Caso esta conexo no possa ser a a aberta, em geral, novas tentativas sero feitas a cada 30 minutos, se no a a obtiver sucesso aps alguns dias, o Servidor de Correio de Alice remover a o a mensagem da la e a noticar. Os Servidores de Correio se encontram na a Internet usualmente consultando o DNS, mais especicamente o registro MX (Mail eXchange); Aps alguns procedimentos iniciais de apresentao, o cliente SMTP envia o ca a mensagem de Alice para dentro da conexo TCP; a No Servidor de Correio de Bob, o lado servidor do SMTP recebe a mensagem e a coloca na caixa postal dele; Bob chama seu Agente de Usurio para ler a mensagem quando for mais a conveniente para ele. Vale salientar que a comunicao entre o Agente de ca Usurio de Bob e seu Servidor de Correio no pode se dar via SMTP. Este a a ultimo passo do processo dever ser feito via um dos protocolos: HTTP, a POP3 ou IMAP.
Figura 30.3: Protocolos de e-mail e suas entidades comunicantes Uma diferena marcante entre o HTTP e o SMTP o fato do HTTP ser c e um PROTOCOLO DE RECUPERACAO DE INFORMACOES (pull proto col). Nesse tipo de protocolo, as conexes so abertas pelas mquinas que o a a desejam receber as informaes. J o SMTP um PROTOCOLO DE ENVIO co a e DE INFORMACOES. Neste tipo de protocolo, as conexes so abertas pelas o a mquinas que desejam enviar as informaes (cliente SMTP). E por este motivo a co que o ultimo passo da transferncia entre dois usurios, entre Agente de Usurio e a a destinatrio e seu Servidor de Correio, no pode ser feito via SMTP. a a
E importante observar que o SMTP normalmente no usa servidores de cora reio intermedirios para enviar correspondncia, mesmo quando os dois servia e dores esto localizados em lados opostos do mundo. Isto porque ele utiliza a o TCP como protocolo de transporte, que orientado a conexo. Portanto, e a geralmente os Servidores de Correio cliente e servidor se conectam diretamente (virtualmente falando). A cada comando enviado pelo cliente SMTP, haver uma resposta enviada a pelo servidor SMTP via um cdigo de resposta e eventualmente uma mensagem o de explicao. Os principais comandos so: ca a DATA: inicializa a transmisso do corpo da mensagem; a 300
HELO: identica o emissor da mensagem; HELP: solicita ao servidor SMTP informaes de ajuda; co MAIL FROM: inicializa uma transao de mail; ca QUIT: determina que o servidor SMTP envie um ok e ento feche a a conexo; a RCPT TO: identica o destinatrio da mensagem. Mltiplos destinatrios a u a so denidos por mltiplos usos deste comando; a u TURN: faz com que os cliente e servidor troquem de papel, o cliente passa a ser servidor e vice-versa; . (ponto): identica o m do corpo da mensagem. Todo correio eletrnico dividido em duas partes: MENSAGEM e ENo e VELOPE. O contedo da parte envelope determinado pelo protocolo de apu e resentao SMTP. A mensagem subdividida em CABECALHO e CORPO. ca e As informaes contidas no cabealho so determinadas no RFC 822. Cada co c a cabealho deve ter obrigatoriamente uma linha From: e uma To: e pode incluir c tambm uma Subject:, bem como outras linhas opcionais. E importante notar e que essas linhas de cabealho so diferentes dos comandos SMTP, ainda que c a contenham algumas palavras em comum. Uma caracter stica marcante do SMTP o fato dele exigir que o formato e de representao, tanto dos cabealhos quanto do corpo da mensagem, seja ca c ASCII. Desta forma, contedos no ASCII, por exemplo, imagens, udio, v u a a deo e caracteres especiais, devem ser codicados em ASCII antes de serem enviados pelo SMTP. Aps a transferncia, estes dados so decodicados novamente em o e a formato ASCII. Para que isto seja poss vel, h necessidade de incluir cabealhos a c adicionais na mensagem. Esses cabealhos extras so denidos no RFC 2045 e c a no RFC 2046, que so extenses do RFC 822 referentes ao MIME (Multipurpose a o Internet Mail Extentions). Os dois cabealhos MIME fundamentais para suporte c de multim dia so: Content-Type e Content-Transfer-Encondig. O primeiro a permite que o Agente de Usurio destinatrio realize uma ao adequada sobre a a ca a mensagem, por exemplo, execuo de uma rotina de descompresso JPEG. O ca a segundo alerta o Agente de Usurio destinatrio que o corpo da mensagem foi a a codicado em ASCII.
30.8
POP3 - Post Oce Protocol Version 3
E o protocolo de CAMADA DE APLICACAO do modelo OSI denido no RFC 1939. Ele um protocolo de acesso de correio eletrnico extremamente simples, e o e como conseqncia bastante limitado. Por padro, ele utiliza o TCP como ue a protocolo de transporte via porta 110. Seu funcionamento t pico da seguinte forma. O Agente de Usurio, agindo e a como cliente, abre uma conexo TCP com o Servidor de Correio que age como a servidor. Com a conexo ativada, o protocolo passa por trs fases: AUTORIZACAO, a e
301
TRANSACAO e ATUALIZACAO. Durante a fase de autorizao, o Agente de Usurio envia um nome de ca a usurio e uma senha (`s claras) para autenticar o usurio. Na fase de transao, a a a ca as mensagens so transferidas ao cliente. E tambm nesta fase que o Agente a e de Usurio pode marcar/desmarcar as mensagens que devero ser apagadas, e a a obter estat sticas de correio. A fase de atualizao ocorre aps o cliente ter ca o solicitado o encerramento da conexo. Nesse momento, o Servidor de Correio a apaga as mensagens que foram marcadas. Em uma transao POP3, o Agente de Usurio emite comandos e o Servidor ca a de Correio emite uma resposta a cada comando recebido. H duas respostas a poss veis: +OK: indica que correu tudo bem com o comando anterior. Esta resposta a `s vezes vem seguida de dados do servidor para o cliente; -ERR: indica que houve algo errado com o comando anterior. Os comandos do POP3 so denidos na RFC 1939. Os principais so: a a USER: informa o nome de usurio; a PASS: informa a senha de usurio; a 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 atualizao; ca QUIT: determina que o servidor envie um ok e ento feche a conexo. a a Uma caracter stica importante deste protocolo o fato dele realizar uma e conexo persistente, ou seja, em uma mesma sesso TCP entre cliente e servia a dor poss a transferncia de diversas mensagens. e vel e Um Agente de Usurio que utiliza POP3 frequentemente pode ser congua rado pelo usurio nal para LER-E-APAGAR ou para LER-E-GUARDAR. A a seqncia de comandos emitida por um Agente de Usurio depende desta conue a gurao. ca No modo ler-e-apagar, os seguintes comandos so emitidos: LIST, RETR e a DELE. Mltiplas mensagens so transferidas por meio de mltiplas seqncias u a u ue de comandos RETR e DELE, uma seqncia para cada mensagem. H um ue a problema com o modo ler-e-apagar. O usurio destinatrio pode ser nmade e a a o querer acessar sua caixa de postal de muitas mquinas. Desta forma, as mena sagens cam repartidas entre as mquinas que estabeleceram conexo com o a a Servidor de Correio, no permitindo a visualizao em uma mquina de mena ca a sagens baixadas por outra mquina diferente. a
302
No modo ler-e-guardar, o Agente de Usurio deixa as mensagens no Servidor a de Correio aps descarreg-las. Desta forma, o problema anterior de repartio o a ca de mensagens resolvido. e Cabe ressaltar que o Agente de Usurio, ao se conectar ao Servidor de Cora reio, descarrega todas as mensagens que esto na caixa postal. Por este fato, a diz-se que este protocolo o-line. Ou seja, o usurio nal recebe todas as suas e a mensagens e ento pode l-las e apaga-las do servidor de arquivo local mesmo a e estando oine. Portanto, este protocolo se mostra interessante para usurios a que pagam pelo acesso a Internet por tempo de conexo, por exemplo, conexo a a discada. Uma caracter stica bastante importante do POP3 o fato dele guardar e informaes de estados durante uma sesso POP3. Em particular, monitora co a as mensagens do usurio marcadas para apagar. Contudo, no mantm ina a e formaes de estado entre sesses POP3. Portanto, de certa forma diz-se que co o este protocolo COM ESTADO. e Este protocolo bastante difundido atualmente. Contudo, h desde 2003 e a uma proposta de atualizao que recebe o nome de POP4. Porm, praticamente ca e nenhum progresso tem sido observado na utilizao desta atualizao. ca ca
30.9
IMAP - Internet Mail Access Protocol
E o protocolo de CAMADA DE APLICACAO do modelo OSI denido no RFC 2060. Ele um protocolo de acesso de correio eletrnico complexo e com muitos e o recursos. Por padro, ele utiliza o TCP como protocolo de transporte via porta a 143. Seu funcionamento t pico se assemelha bastante com o funcionamento do POP3. Contudo, h alguns novos recursos bastante interessantes para o usurio. a a A principal diferena com relao ` possibilidade do usurio poder criar pastas, c e ca a a mover/copiar mensagens de uma pasta para outra e tambm realizar procurar e por palavras chaves. No POP3 todas essas funcionalidades s podem ser exeo cutadas com as mensagens na mquina local do cliente. Enquanto que o IMAP a implementa comandos que permitem fazer essas manipulaes com as mensagens co no Servidor de Correio, o que trouxe um avano considervel. c a
Uma outra caracter stica contrastante com o POP3 com relao ` manuteno e ca a ca de informaes de estado. O POP3 somente mantm informaes de estado duco e co rante uma sesso POP3, enquanto o IMAP mantm informaes tanto durante a e co sesses quanto entre sesses IMAP. Por exemplo, os nomes das pastas e quais o o mensagens esto associadas a elas devem ser mantidos. Portanto, diz-se que o a POP3 um protocolo COM ESTADO. e Uma explicao sucinta do uxo das mensagens a seguinte. O servidor ca e IMAP sempre associa as mensagens que chegam ` pasta INBOX do destinatrio, a a que, ento, pode transferir estas mensagens para uma nova pasta criada por ele, a l-las, apag-las e assim por diante. e a
303
Outra caracter stica importante do IMAP que ele tem comandos que pere mitem que um Agente de Usurio obtenha componentes de mensagens. Por a exemplo, um Agente de Usurio pode obter apenas o cabealho ou somente a c uma das partes de uma mensagem MIME multiparte. Essa caracter stica util e quando h uma conexo de largura de banda estria entre o Agente de Usurio a a e a e seu Servidor de Correio. Com uma conexo deste tipo, o usurio pode decidir a a no baixar todas as mensagens de sua Caixa Postal, evitando, em particular, a mensagens longas que possam conter, por exemplo, arquivos grandes. Hoje, um nmero cada vez maior de usurios est enviando e acessando u a a e-mails por meio de seus browsers Web. Esse tipo de servio provido por c e praticamente todos os sites ISPs, bem como universidades e empresas importantes. Com esse servio, o Agente de Usurio um browser Web comum e o c a e usurio se comunica com sua Caixa Postal, tanto enviando quanto recebendo a mensagens, via HTTP, e no via os protocolos SMTP, POP3 ou IMAP. Cona tudo, os Servidores de Correio continuam se comunicando entre si via SMTP. Essa soluo tambm extremamente conveniente quando o usurio est em ca e e a a trnsito. Pois, como ocorre com o IMAP, usurios podem organizar suas mena a sagens em uma hierarquia de pastas no servidor remoto. Na verdade, muitas implementaes de e-mail pela Web utilizam um servidor IMAP para prover a co funcionalidade de pastas e busca. Nesse caso, o acesso `s pastas e mensagens a 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 comparao entre ca IMAP e POP3. Caracter stica Onde o protocolo denido e Porta TCP usada Onde as mensagens so armazenadas a Como as mensagens so lidas a Tempo de conexo exigido a Utilizao de recursos do servidor ca Vrias caixas de correio (pastas) a Bom para usurio em trnsito a a Controle do usurio sobre o download a Downloads de mensagens parciais Quotas de disco consistem um problema Implementao simples ca POP3 RFC 1939 110 PC do usurio a Oine Pequeno M nima No a No a Pequeno No a No a Sim IMAP RFC 2060 143 Servidor Online Grande Intensa Sim Sim Grande Sim Poss vel No a
Tabela 30.2: Comparao entre IMAP e POP3 ca
304
30.10
LDAP - LightWeight Directory Access Protocol
O LDAP mais um protocolo de camada de aplicao que roda sobre o protoe ca colo TCP. O servio LDAP segue o modelo cliente servidor, onde um ou mais c servidores contem as informaes sobre os diretrios em uma rede. Um cliente co o LDAP se conecta ao servidor e faz um request, que respondido pelo servidor e ou ento redirecionado para outro servidor. Os servidores LDAP armazenam a informaes como direitos de acesso, espao dispon por usurios, entre outco c vel a ras. Cada um dos diretrios gerenciados pelo LDAP contm informaes a o e co seu repeito como CreatorsName, CreateTimestamp, ModiersName, ModiersTimestamp. As estruturas no LDAP so armazenadas de forma hierrquica a a e no existe limitao quanto a organizao hierrquica como nos sistemas de a ca ca a arquivos. Pode-se, por exemplo, adicionar as estruturas partes de nomes de dom nio, ou sistema operacional. As entradas no LDAP so chamadas Disa tinguished Names (DNs). Ao congurar um servidor utiliza-se o conceito de suxo (suxe) para determinar qual o n vel mais alto da hierarquia est sob a seu controle.
30.11
SNMP - Simple Network Management Protocol
O SNMP um protocolo da camada de aplicao que foi desenvolvido para pere ca mitir a execuo de vrias funes como: (i) Congurar Dispositivos Remotos; ca a co (ii) Monitorar Performance da Rede (iii) Detectar Problemas na Rede e Acessos Indevidos; (iv) Auditar a utilizao da Rede. ca Os componentes do servio de SNMP so o sistema de gerenciamento, que c a pode ser qualquer mquina rodando um software de gerenciamento, e os agentes a que so as mquinas gerenciadas. Essas mquinas podem ser computadores pesa a a soais, servidores, switches, roteadores, etc. O sistema de gerenciamento envia um request para um agente ou tambm pode enviar informaes em alguns cae co sos. O servio de SNMP pode ser congurado para especicar quais informaes c co devem ser informadas ao sistema de gerenciamento e quais sistemas de gerenciamento esto autorizados a requisitar informaes. Em geral, so os sistemas de a co a gerenciamento que requisitam informaes dos agentes, porm os agentes podem co e utilizar mensagens chamadas traps para comunicar algo ao sistema em ocasies o especiais. Exemplos dessas situaes so temperatura elevada, tentativas de inco a vaso, altas taxas de utilizao de memria ou CPU, etc. a ca o Os sistemas de gerenciamento so organizados em comunidades por propsitos a o administrativos e segurana. Quando um sistema de gerenciamento requisita c alguma informao dos agentes, os agentes recuperam as informaes de uma ca co base chamada MIB - Managment Information Base. As mensagens do protocolo SNMP so as seguintes: (i) Get - A mensagem mais simples onde o sistema de a gerencia solicita uma informao espec ca ca; (ii) Get-Next - Pesquisa por uma informao em toda a MIB; (iii) Set - Se for permitida a escrita na MIB; (iv) ca Getbulk - Solicita que os dados enviados pelo agente sejam o maior poss vel
305
respeitando um determinado valor e o MTU da linha; (v) Trap - Mensagem no solicitada enviada do agente para o sistema de gerenciamento. O protocolo a SNMP utiliza o as portas UDP/161 e UDP/162 (traps).
30.12
FTP - File Transfer Protocol
E o protocolo de CAMADA DE APLICACAO do modelo OSI no RFC 959. Ele implementado em dois programas, um cliente e outro servidor, portanto, ele e classicado como aplicao cliente-servidor. e ca Como segurana m c nima o protocolo FTP implementa um processo de autenticao e outro de permisso. A autenticao vericada atravs de um ca a ca e e cdigo de usurio e senha, j a permisso, dada em n de diretrios e aro a a a e vel o quivos. Em uma sesso FTP t a pica, o usurio, sentado ` frente de um hospedeiro (o a a local), quer transferir arquivos de ou para um hospedeiro remoto. Na realidade, um usurio tambm pode transferir arquivos de um hospedeiro remoto para a e outro hospedeiro remoto. Para acessar a conta remota, o usurio deve fornecer a uma identicao e uma senha (processo de autenticao). O usurio nal inca ca a terage com o FTP por meio de um AGENTE DE USUARIO FTP. Alguns dos agentes mais utilizados atualmente so: SmartFTP; Cute FTP; FTP via Web; a Filezilla; Core FTP; WS FTP; LeechFTP; e gFTP. Assim como o HTTP, o FTP tambm usa o TCP como protocolo de cae mada de transporte. Contudo, h algumas diferenas importantes. Diferente a c do HTTP, o FTP usa duas conexes TCP paralelas para transferir um aro quivo: uma CONEXAO DE CONTROLE e uma CONEXAO DE DADOS. A primeira utilizada para enviar informaes de controle, por exemplo, identie co cao de usurio, senha, comandos para trocar diretrio remoto e comandos ca a o de inserir/pegar arquivos. A conexo de dados usada para enviar efetivamente a e os dados. Como so usadas conexes distintas para controle e dados, dizemos a o que o FTP envia informaes de controle FORA DA BANDA. Por padro, as co a portas utilizadas so as 21 (conexo de controle) e 20 (conexo de dados). a a a Diferentemente do HTTP, o FTP precisa manter informaes de estado soco bre cada usurio conectado ao servidor. Em particular, o servidor deve associar a a conexo de controle com uma conta de usurio espec a a ca e tambm deve e monitorar o diretrio corrente do usurio enquanto este passeia pela arvore do o a diretrio remoto. Portanto, diz-se que o FTP um PROTOCOLO COM ESo e TADO. Uma caracter stica bastante importante do FTP o fato da conexo de cone a trole permanecer aberta durante toda uma sesso enquanto necessria uma a e a nova conexo de dados para transferncia da cada arquivo. Ou seja, se for a e necessria a transferncia de dois arquivos entre os mesmos cliente e servidor, a e em uma mesma sesso FTP, somente uma conexo de controle ser aberta, mas a a a sero abertas duas conexes de dados, uma para cada arquivo. a o
306
O FTP implementa trs modos de transferncias. So eles: e e a Modo Ativo: o cliente responsvel pela abertura da conexo de controle e a a e o servidor responsvel pela abertura da conexo de dados. O processo e a a acontece da seguinte forma. O cliente abre uma conexo de controle em a uma porta randmica, por exemplo 1553, com o servidor que est escuo a tando em sua porta 21. O cliente envia ao servidor, por meio do comando PORT, uma outra porta randmica, por exemplo 1500, e seu endereo IP. o c Ento, o servidor abre uma conexo de dados com o cliente utilizando sua a a porta 20 e a porta 1500 do cliente; Modo Passivo: o cliente responsvel pela abertura de ambas as conexes. e a o O processo acontece da seguinte forma. O cliente abre uma conexo de a controle em uma porta randmica, por exemplo 1553, com o servidor que o est escutando em sua porta 21. O cliente envia um comando PASV ao a servidor informando que o modo de conexo ser passivo. Em resposta, o a a servidor envia, por meio do comando PORT, uma porta randmica, por o exemplo 1728, e seu endereo IP. Ento, o cliente abre uma conexo de c a a dados com o servidor utilizando uma outra porta randmica, por exemplo o 1500, e a porta 1728 do servidor; Modo Passivo Estendido: este modo muito similar ao modo passivo. e Contudo, o servidor, ao enviar o comando PORT, transmite ao cliente somente o nmero da porta randmica (no transmite seu endereo IP) u o a c que estar escutando para o estabelecimento da conexo de dados. O a a cliente assume ento que ele dever se conectar ao mesmo endereo IP a a c que foi originalmente conectado. Este modo foi adicionado no protocolo por meio da RFC 2428. Cabe salientar que toda conexo randmica acontece em portas maiores que a o 1023 e so conexes no privilegiadas. Os processos de conexo em moto ativo a o a a e passivo so exemplicados na gura 30.4. a O FTP implementa dois tipos de conexo: a annima e a com autenticao. a o ca A primeira a mais utilizada, onde no necessrio o usurio informar login e a e a a e senha, basta identicar-se como anonymous. Contudo, somente arquivos e diretrios pblicos do servidor de arquivo remoto sero acessados. Dependendo o u a da implementao do servidor FTP, solicitada ao usurio a entrada de seu ca e a endereo de e-mail como campo de senha. Isto permite aos administradores c algum tipo de controle. Em alguns casos o prprio servidor FTP suprime a o solicitao de senha preenchendo este campo com valores padres (ex. lftp@ e ca o mozilla@example.com). O protocolo FTP, assim como o HTTP, envia comandos e respostas por meio da conexo de controle no formato ASCII. Contudo, o FTP permite que o cliente a especique o formato dos dados armazenados a serem transferidos na conexo a de dados. Os formatos mais utilizados so: ASCII, Binary, EBCDIC e USASCII. a A lista de comandos do FTP de tamanho considervel. Os principais so: e a a CD: permite alterar o diretrio de trabalho remoto; o
307
Figura 30.4: Modos de transmisso do FTP a CLOSE: solicita o encerramento da sesso FTP, ou seja, o encerramento a da conexo de controle; a DELE: solicita ao servidor a deletar um arquivo no servidor remoto; EPSV: informa ao servidor a entrada no modo de transferncia passivo e estendido (no especicada na RFC 959, especicada em outra RFC); a GET: solicita ao servidor a transferncia de uma cpia de um arquivo e o do servidor remoto (no especicada na RFC 959, especicada em outra a RFC); HELP: retorna a documentao sobre como usar o FTP, inclusive a lista ca de comandos; FTP: inicia uma seo FTP (inicializa o programa FTP); ca LIST: retorna a listagem de arquivos em um diretrio remoto ou contedo o u de um arquivo do servidor remoto; OPEN: abre uma conexo com um servidor FTP, ou seja, abre uma a conexo de controle servidor remoto; a PASS: informa ao servidor a senha do usurio; a PASV: informa ao servidor a entrada no modo de transferncia passivo; e PORT: envia um endereo IP e uma porta que sero utilizados na abertura c a de uma conexo futura, ou pelo servidor ou pelo cliente; a PUT: realiza a transferncia de uma cpia de um arquivo da mquina local e o a ao servidor remoto (no especicada na RFC 959, especicada em outra a RFC); PWD: informa o diretrio de trabalho corrente no servidor remoto; o 308
QUIT: fecha uma seo FTP (naliza o programa FTP); ca RETR: solicita ao servidor a transferncia de uma cpia de um arquivo e o do servidor remoto; REST: solicita ao servidor o rein da transferncia de uma cpia de um cio e o arquivo do servidor remoto a partir de certo ponto; STOR: realiza a transferncia de uma cpia de um arquivo da mquina e o a local ao servidor remoto; TYPE: congura o formato de arquivo a ser transferido; USER: informa ao servidor remoto o nome do usurio. a No FTP, cada comando seguindo de uma resposta, que enviada do servie e dor ao cliente. Assim como no HTTP, as respostas so codicadas em nmeros a u de trs d e gitos com uma mensagem opcional aps o nmero. As respostas mais o u t picas, junto com suas poss veis mensagens so as seguintes: a 1xx: Resposta preliminar positiva. A ao requisitada se iniciou, mas ca haver uma outra resposta antes de seu comeo; a c 2xx: Resposta denitiva positiva. A ao requisitada se completou. Agora ca o cliente pode fazer outra solicitao; ca 3xx: Resposta intermediaria positiva. O comando teve sucesso, mas um outro comando necessrio antes do servidor poder executar efetivamente e a a solicitao feita; ca 4xx: Resposta preliminar negativa. O comando no foi bem sucedido, mas a o cliente pode tent-lo novamente; a 5xx: Resposta denitiva negativa. O comando no foi bem sucedido e o a cliente no deve solicit-lo novamente; a a x0x: A falha se deu por motivos de erro de sintaxe; x1x: Resposta a uma solicitao de informao. Por exemplo, 125 ca ca Conexo de dados j aberta, iniciando transferncia; a a e x2x: Resposta a uma solicitao de informao referente ` conexo. Por ca ca a a exemplo, 425 - No poss abrir a conexo de dados; a e vel a x3x: Resposta a uma solicitao de informao referente autenticao e ca ca ca conta de usurio. Por exemplo, 331 - Nome de usurio OK, senha requia a sitada; x4x: Ainda no especicada; a 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) uma e opo para quem no necessita da robustez do protocolo FTP. O TFTP usa o ca a protocolo UDP/69 para fazer a entrega dos pacotes, ao contrrio do protocolo a FTP que usa o protocolo TCP. As principais caracter sticas deste protocolo so: no permite visualizao dos diretrios; no implementa autenticao de a a ca o a ca usurios; e no implementa mecanismos de criptograa. As operaes de esa a co crita/leitura so descritas pelas guras 30.5 a
Figura 30.5: Processo de escrita/leitura do TFTP
30.13
IP - Internet Protocol
O IP (Internet protocol) um protocolo de camada de rede que prove mecane ismos de fragmentao e remontagem de unidades chamadas datagramas para ca a transmisso por diversas redes com diferentes unidades mximas de transa a ferncias. O protocolo IP no orientado a conexo e no possui controle e a e a a de uxo, conrmaes ou sequenciamento. O IP utiliza um esquema de enco dereamento de 32 bits que dividido em tres partes que so rede, subrede e c e a host. Os endereos IP podem der divididos em classes de acordo com o nmero c u de bits que reservam para identicao da rede. As mascaras de sub-rede servem ca para identicar qual a rede e quantos host so poss a veis na rede. As mascaras so compostas por diversos bits 1 seguidos de bits 0. As formas de enderear a c um pacote IP so o unicast, multicast e broadcast. a O cabealho do IP formado pelos seguintes campos: (1) Verso: Indica c e a a verso utilizada. (2) IP Header Lenght: Indica o tamanho do cabealho em a c mltiplo de 32 bits. (3) Type of Service: Especica a maneira com a qual os prou tocolos de camadas superiores querem que o pacote IP seja tratado. Os n veis 310
de QoS so assinalados por meio desse campo do cabealho. (4) Total Lenght: a c Tamanho total do datagrama (dados e cabealho). (5) Identication: Identic ca a qual datagrama pertence um fragmento. (6) Time to Live: Contador de tempo de vida do pacote. Decrementado a cada hop. (7) Protocol: Identica qual protocolo de camada superior est encapsulado. (8) Header Checksum: a Identica se cabealhos estam corrompidos. (9) Source/Destination Address. c (10) Options e Padding: Suporta opes (Ex: Segurana) e Preenchimento. co c Com o crescimento das redes os endereos IP esto se tornando um probc a lema para os administradores da Internet. Apesar de matematicamente serem poss veis em torno de 4 bilhes de endereos, muitos deles no podem ser utio c a lizados ou simplesmente so desperdiados devido ao esquema de distribuio a c ca de endereos inadequado baseado em classes. Um outro problema decorrente c e a sobrecarga das tabelas de roteamento. Para solucionar o problema surgiu o IPv6 porem at que a migrao ocorra por completo sero necessrios alguns e ca a a anos segundo especialistas. Uma outra soluo para este problema chamada IP ca e Classless. O esquema de endereamento padro divide os endereos nas classes c a c A,B e C onde a diferena entre a quantidade de endereos em cada uma das c c classes muito grande, fazendo com que ocorra um desperd e cio muito grande de endereos. O esquema IP Classless utiliza uma mascara de 32 bits para c identicar a rede. Exemplos de mascara so: a 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11100000 11111111 00000000 11111111 00000000 00000000 255.255.255.0 00000000 255.255.0.0 11111000 255.255.255.252 00000000 255.32.0.0
Com esta estratgia poss criar redes com tamanhos mais adequados as e e vel necessidades. Para identicar como um datagramas deve ser encaminhado por um roteador, por exemplo, feito um AND lgico da mascara com o endereo e o c IP de destino do datagramas para pesquisar por qual linha ele deve sair. O endereo de broadcast em uma rede IP sempre o ultimo endereo da c e c faixa. Por exemplo: Na rede 10.0.0.0/24, o endereo de broadcast 10.0.0.255, c e enquanto em na rede 172.22.4.0/22 o endereo de broadcast seria 172.22.7.255. c
30.14
TELNET - TELetype NETwork
E o protocolo de CAMADA DE APLICACAO do modelo OSI denido no RFC 854 (na verdade tambm em diversos outros RFCs). Ele um protocolo popular e e utilizado para fazer login remoto entre qualquer par de hospedeiros. Por padro, a ele utiliza o TCP como protocolo de transporte via porta 23. Na verdade, nada impede que sejam utilizadas outras portas. Este protocolo implementado em dois programas, um cliente e outro servie dor, portanto, ele classicado como aplicao cliente-servidor. Porm, o termo e ca e Telnet tambm utilizado para se referir ao software que implementa o proe e grama cliente do protocolo. A mquina que abre a conexo a que pretende a a e enviar caracteres, e portanto, a considerada cliente. A mquina que recebe os e a
311
caracteres enviados a considerada servidora. e As trs caracter e sticas mais marcantes deste protocolo so: a Todos os dados, inclusive senhas, no so criptografados (o que o torna a a bastante vulnervel); a No h autenticao para se garantir que o servidor realmente quem ele a a ca e diz que ; e Cada caractere digitado pelo usurio (no cliente) ser enviado ao hosa a pedeiro remoto e este devolver uma cpia (eco) do caractere digitado a o que ser apresentado na tela do Telnet do usurio. Esse eco utilizado a a e para garantir que os caracteres vistos pelo usurio do Telnet j foram rea a cebidos e processados no local remoto. Assim, cada caractere atravessa literalmente a rede duas vezes. A gura 30.6 apresenta o cenrio t a pico de envio de caracteres via Telnet. A seguir, so examinados os segmentos TCP que so enviados entre o cliente e a a o servidor deste cenrio. Admite-se que os nmeros de seqncia iniciais sejam a u ue 42 e 79 para cliente e servidor, respectivamente. Lembre-se que estes nmeros u representam os nmeros dos segmentos aguardados cada mquina. Vamos aos u a segmentos: O primeiro enviado do cliente ao servidor, contendo em seu campo de e dados um byte com a representao ASCII para a letra C (digitada pelo ca usurio). Este segmento tambm tem 42 em seu campo de nmero de a e u seqncia. E mais, como o cliente ainda no recebeu nenhum dado do ue a servidor, esse segmento ter o nmero 79 (no foi incrementado) em seu a u a campo de nmero de reconhecimento; u O segundo enviado do servidor ao cliente. Esse segmento tem dupla e nalidade. A primeira fornecer um reconhecimento para os dados que o e servidor recebeu. Ao colocar 43 no campo de reconhecimento, o servidor esta dizendo ao cliente que recebeu com sucesso tudo at o byte 42 e que e est aguardando os bytes de 43 em diante. A segunda nalidade ecoar a a e letra C. Ele tem o nmero de seqncia 79, que o numero de seqncia u ue e ue inicial do uxo de dados de servidor para cliente dessa conexo TCP. Note a que o reconhecimento para dados do cliente para servidor levado em um e segmento que carrega dados do servidor para o cliente. Tecnicamente essa carona recebe o nome de PIGGYBACK; O terceiro enviado do cliente ao servidor. Seu unico propsito e recone o hecer os dados que recebeu do servidor. Ele tem o campo de dados vazio, tem o numero 80 no campo de nmero de reconhecimento porque o cliente u agora est aguardando os bytes de 80 em diante. a Vale a pena comentar que este protocolo vem perdendo bastante espao para c o protocolo SSH. Pois o SSH prov todas as funcionalidades do Telnet com a e adio de uma forte criptrograa de dados, inclusive senhas, e de uso de chaves ca pblicas para a realizao de autenticao. Com este tipo de autenticao, se u ca ca ca garante que o servidor realmente quem ele diz que . e e 312
Figura 30.6: Cenrio t a pico de envio de caracteres via Telnet
313
Cap tulo 31
O Modelo de Referncia e OSI

O modelo de referncia OSI (Open Systems Interconnection) foi o primeiro passo e para a padronizao internacional dos processos de comunicao de sistemas ca ca abertos. Sistemas abertos so aqueles que esto abertos a comunicao com a a ca outros sistemas. Os princ pios aplicados para se chegar ao modelo de 7 camadas foram os seguintes: Uma camada deve ser criada onde houver necessidade de abstrao acional; ca Cada camada deve executar tarefa bem denida; O limite das camadas deve minimizar o uxo de informaes sobre as co interfaces. O modelo OSI no uma arquitetura, pois no especica servios e protoa e a c colos exatos de cada camada. Ele apenas indica o que cada camada deve fazer. As 7 camadas propostas no modelo OSI e suas respectivas funes so: co a 1. Camada F sica - Responsvel pela transmisso de bits brutos por um canal a a de comunicao. As questes mais comuns so representao dos bits 0 e ca o a ca 1, tempo de vida de um bit, permitir ou no transmisses simultneas nos a o a dois sentidos, pinagens, etc; (2)
2. Camada de Enlace - Transformar o canal de comunicao bruto em uma ca linha que parea livre de erros para a camada de rede. Deve implementar c mecanismos de fragmentao e montagem, controle de uxo, tratamentos ca de erros e mecanismos de conrmao caso o servio seja convel. Para ca c a melhorar o desempenho pode-se utilizar a tcnica de Pipelining. Deve e possuir tambm mecanismos de retransmisso; e a 3. Camada de Rede - Determinar como os pacotes so roteados da origem ao a destino. Evitar congestionamentos e atrasos excessivos. Deve se preocupar tambm com endereamento e tamanhos de pacotes,que podem ser e c diferentes nas diversas redes. E papel da camada proporcionar interoperabilidade entre as redes. Deve implementar servios orientados a conexo c a (circuitos virtuais) e no orientados a conexo (datagramas). a a 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 chegaro cora retamente ao destino. E a camada que realiza o controle m-a-m. Um processo em uma mquina h mantm uma conversao diretamente com a a e ca um processo em alguma outra mquina. Entre as tarefas mais comuns a realizadas pelos protocolos dessa camada esto transferncia bsica de a e a dados, multiplexao, abertura de conexes, controle de uxo e congesca o tionamento; 5. Camada de Sesso - Permite que usurios de diferentes mquinas estaa a a beleam sesses entre eles. Os servios so controle de dilogo (quem c o c a a deve transmitir a cada momento), gerenciamento de token (impedindo que duas mquinas tentem executar sesso cr a a tica ao mesmo tempo) e a sincronizao (que permite que transmisses longas parem e reiniciem do ca o ponto onde ocorreu interrupo); ca 6. Camada de Apresentaao - Preocupa-se com a sintaxe e a semntica das c a informaes transmitidas. O objetivo permitir a transferncia de dados co e e entre entidades com diferentes representaes de dados. Denem as estruco turas de dados a serem intercambiadas juntamente com a codicao dos ca dados; 7. Camada de Aplicao - Contm os protocolos que implementam de fato ca e as aplicaes dos usurios. co a
315
Cap tulo 32
Roteamento
Trs importantes protocolos roteveis so o IP, o IPX e o AppleTalk. O IP o e a a e protocolo ocial da Internet e faz parte da pilha de protocolos TCP/IP, por isso o mais importante. Embora a maior ateno deve ser dada no IP, impore ca e tante saber que existem outros protocolos roteveis (IPX/SPX e o AppleTalk). a Protocolos como o IP, o IPX/SPX e o AppleTalk fornecem suporte ` camada 3 a e so, portanto, roteveis. a a Entretanto, h protocolos que no suportam a camada 3. Eles so classia a a cados como protocolos no-roteveis. O mais comum desses protocolos noa a a roteveis o NetBEUI. O NetBEUI um protocolo pequeno, rpido e eciente, a e e a cuja execuo se limita a um segmento. Para um protocolo ser rotevel, ele deve ca a propiciar a habilidade de atribuir um nmero de rede, assim como um nmero u u de host, a cada dispositivo individual. Alguns protocolos, como o IPX, exigem apenas que voc atribua um nmero de rede, porque usam um endereo MAC e u c de host para o nmero f u sico. Outros protocolos, como o IP, exigem que voc e fornea um endereo completo, alm de uma mscara de sub-rede. O endereo c c e a c de rede obtido pela operao AND do endereo com a mscara de sub-rede. e ca c a 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, seleo do melhor ca caminho e comutao). Tais mapas tornam-se parte da tabela de roteamento ca de cada roteador. Os dois tipos de protocolos de roteamento so os Exterior Gateway Proa tocols (EGPs) e os Interior Gateway Protocols (IGPs). Os Exterior Gateway Protocols roteiam os dados entre sistemas autnomos. Um exemplo de EGP o o e BGP (Border Gateway Protocol), o principal protocolo de roteamento externo da Internet. Os protocolos RIP, OSPF, IGRP e EIGRP so exemplos de IGPs. a O administrador de rede pode inserir as informaes manualmente no roteador. co 316
Os roteadores podem conhecer as informaes uns dos outros durante o proco cesso. As entradas manuais nas tabelas de roteamento so chamadas de roa tas estticas. As rotas descobertas automaticamente so chamadas de rotas a a dinmicas. Quando um algoritmo de roteamento atualiza uma tabela de roteaa mento, seu principal objetivo determinar as melhores informaes para incluir e co na tabela. Cada algoritmo de roteamento interpreta ` sua maneira o que a e melhor. O algoritmo gera um nmero, chamado valor mtrico, para cada camu e inho atravs da rede. Geralmente, quanto menor o nmero da mtrica, melhor e u e o caminho. Voc pode calcular a mtrica com base em uma unica carace e e ter stica do caminho; voc pode calcular mtricas mais complexas combinando e e vrias caracter a sticas. As mtricas comumente usadas pelos roteadores so as e a seguintes: Largura de banda - a capacidade de dados de um link; Atraso - o tempo necessrio para mover um pacote por cada link, da a origem at o destino; e Carga - a quantidade de atividade em um recurso de rede, como um roteador ou um link; Conabilidade - geralmente se refere ` taxa de erros de cada link da rede; a Nmero de hops - o nmero de roteadores atravs dos quais um pacote u u e 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 arbitrrio, geralmente baseado na largura de banda, a despesas monetrias ou outras medidas, atribu por um administrador a do de rede.
32.1
Link State e Distance Vector
A maioria dos algoritmos de roteamento pode ser classicada como um dos dois algoritmos bsicos: a Vetor de Distncias (Distance Vector ); a Estado do Link (Link State).
A abordagem do roteamento de vetores de distncia determina a direo a ca (vetor) e a distncia de todos os links na internetwork. A abordagem do link a state (tambm chamado de shortest path rst) recria a topologia exata da ine ternetwork inteira (ou de pelo menos da parte onde o roteador est situado). A a abordagem h brida balanceada combina aspectos dos algoritmos do link state e do vetor de distncia. A seguir so apresentados os procedimentos e os proba a lemas de cada um desses algoritmos de roteamento e apresentam tcnicas para e minimizar os problemas. Cada roteador que usa roteamento de vetor de distncia comea identicando a c ` seus prprios vizinhos. A medida que o processo de explorao de rede de vetor o ca 317
de distncia prossegue, os roteadores descobrem o melhor caminho para as redes a de destino, com base nas informaes que recebem de cada vizinho. Quando co a topologia em uma rede de protocolo de vetor de distncia alterada, devem a e ocorrer atualizaes na tabela de roteamento. Da mesma forma que acontece co com o processo de explorao da rede, as atualizaes das alteraes na topoloca co co gia prosseguem passo a passo, de roteador para roteador. Os algoritmos de vetor de distncia solicitam que cada roteador envie toda a sua tabela de roteaa mento para cada um dos vizinhos adjacentes. As tabelas de roteamento incluem informaes sobre o custo total do caminho (denido pela sua mtrica) e o enco e dereo lgico do primeiro roteador no caminho para cada rede contida na tabela. c o Loops de roteamento podem ocorrer se a convergncia lenta de uma rede em e uma congurao nova provoca entradas de roteamento inconsistentes. Os algoca ritmos de roteamento de vetores de distncia so autocorrig a a veis, mas um problema de loop de roteamento pode exigir primeiro uma contagem at o innito. e Para evitar esse problema prolongado, os protocolos de vetores de distncia dea nem o innito como um nmero mximo espec u a co. Esse nmero se refere a u uma mtrica de roteamento (por exemplo, um contador de saltos simples). e O segundo algoritmo bsico usado para roteamento o algoritmo de link a e state. Os algoritmos de roteamento baseados em link state, tambm conhecie dos como algoritmos SPF (shortest path rst - primeiro caminho mais curto), mantm um banco de dados complexo de informaes sobre a topologia. Ene co quanto o algoritmo de vetor de distncia tem informaes no espec a co a cas sobre redes distantes e nenhum conhecimento sobre roteadores distantes, um algoritmo de roteamento de link state mantm conhecimento completo sobre roteadores e distantes e de como esto interconectados. O roteamento de link state usa: a LSAs (Link-State Advertisements - aviso de estado do link); Um banco de dados topolgico; o O algoritmo SPF e a rvore SPF resultante; a 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 alterao enviam ca informaes para outros roteadores ou para um roteador designado, as quais co todos os outros roteadores podem usar para atualizaes. Isso envolve o envio co de informaes comuns de roteamento a todos os roteadores na internetwork. co Existem duas questes relacionadas ao link state: o Requisitos de processamento e memria: Executar protocolos de roteao mento de link state, na maior parte das situaes, requer que os roteadores co usem mais memria e executem mais processamento que os protocolos o de roteamento de vetor de distncia. Para roteamento de link state, a a memria deve ser capaz de reter informaes de diversos bancos de dados, o co da rvore de topologia e da tabela de roteamento. Usar o algoritmo de a Dijkstra para calcular o SPF requer uma tarefa de processamento proporcional ao nmero de links na internetwork, multiplicado pelo nmero de u u roteadores na internetwork; 318
Requisitos de largura de banda: consumida para a sobrecarga inicial do pacote de link state. Durante o processo inicial de explorao, todos os ca roteadores usando protocolos de roteamento de link state enviam pacotes LSA para todos os outros roteadores. Essa ao sobrecarrega a internetca work ` medida que os roteadores fazem uma demanda em massa de largura a de banda e reduzem temporariamente a largura de banda dispon para vel o trfego roteado que transporta dados de usurios. Depois dessa sobrea a carga inicial, os protocolos de roteamento de link state requerem geralmente apenas uma largura de banda m nima para enviar pacotes LSA raros ou desencadeados por eventos que reitam alteraes na topologia. co
32.1.1
Vetor de Distncias vs. Estado do Link a
Voc pode comparar o roteamento de vetor de distncia com o roteamento de e a link state em diversas reas-chave: a O roteamento de vetor de distncia obtm dados topolgicos das informaes a e o co da tabela de roteamento dos vizinhos. O roteamento de link state obtm e uma ampla viso de toda a topologia da internetwork acumulando todos a os LSAs necessrios; a O roteamento de vetor de distncia determina o melhor caminho, adicioa nando ao valor mtrico recebido ` medida que informaes de roteamento e a co so passadas de roteador para roteador. Para o roteamento de link state, a 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 distncia, a atualizaes de alteraes na topologia chegam em atualizaes peridicas co co co o de tabelas. As informaes passam de roteador para roteador, geralmente co resultando em uma convergncia mais lenta. Com protocolos de roteae mento de link state, as atualizaes so normalmente desencadeadas por co a alteraes na topologia. LSAs relativamente pequenos passados para todos co os outros roteadores resultam geralmente em um tempo de convergncia e mais rpido em qualquer alterao na topologia da internetwork. a ca Os protocolos de roteamento h brido balanceado usam vetores de distncia a com mtricas mais precisas para determinar os melhores caminhos at as redes e e de destino. Entretanto, eles diferem da maior parte dos protocolos de vetores de distncia porque utilizam alteraes na topologia para desencadear atuala co izaes de bancos de dados de roteamento. O protocolo de roteamento h co brido balanceado converge rapidamente, como os protocolos de link state. Entretanto, ele difere dos protocolos de vetor de distncia e de link state porque usa menos a recursos, como largura de banda, memria e sobrecarga de processador. Exo emplos de protocolos h bridos so o IS-IS (Intermediate System-to-Intermediate a System) da OSI e EIGRP (Enhanced Interior Gateway Routing Protocol) da Cisco.
319
32.2
32.2.1
Protocolos de Roteamento
RIP - Routing Information Protocol
O protocolo mais comumente usado para transferir informaes de roteamento co entre roteadores localizados na mesma rede o Routing Information Protocol e (RIP). Esse Interior Gateway Protocol (IGP) calcula a distncia para um host a de destino em termos do nmero de hops. O RIP permite aos roteadores atuu alizar suas tabelas de roteamento em intervalos programveis, normalmente a a cada 30 segundos. Uma desvantagem dos roteadores que usam RIP o fato deles e estarem constantemente se conectando aos roteadores vizinhos para atualizar as suas tabelas de roteamento, criando assim uma grande quantidade de trfego de a rede. O RIP um protocolo de vetor distncia. Como o contador de saltos a e a e unica medida de roteamento usada pelo RIP, ele no seleciona necessariamente a o caminho mais rpido para um destino. a Quando se usa o RIP, o nmero mximo de saltos pelos quais os dados podem u a ser encaminhados 15. Alguns avanos foram introduzidos na nova verso do e c a RIP, chamada de RIP2. Esta nova verso trata da questo de VLSMs (mscara a a a de tamanho varivel), autenticao, e atualizaes de roteamento simultneas a ca co a (multicast). RIP2 no apresenta avanos expressivos em relao ao RIP porque a c ca ainda apresenta limitaes na contagem de hops e lenta convergncia, o que co e essencial nas grandes redes atuais.
32.2.2
OSPF - Open Shortest Path First
Uma descrio pode ser determinao de um caminho timo, pois esse Interior ca ca o Gateway Protocol realmente usa vrios critrios para determinar a melhor rota a e para um destino. Esses critrios incluem as medidas de custo, que so subdividie a das em itens como a velocidade de rota, o trfego, a conabilidade e a segurana. a c H duas caracter a sticas principais no OSPF. A primeira, um protocolo de e padro aberto,. A segunda, um protocolo baseado no algoritmo SPF (linka e state), tambm chamado de algoritmo de Dijkstra. O OSPF utiliza o conceito e de roteamento hierrquico. a OSPF apresenta algumas caracter sticas importantes que so: a No h limite na contagem de hops; a a
O uso eciente de VLSM muito util na alocao de endereos IP; e ca c OSPF usa multicast de IP para enviar atualizaes de link-state. Isto co garante menor processamento nos roteadores que no esto escutando os a a pacotes OSPF; Apresenta melhor convergncia que o RIP; e Permite um melhor balanceamento de carga;. Permite uma diviso lgica da rede, onde roteadores podem ser divididos a o em reas. Isto limita a exploso de atualizaes de link state por toda a a a co
320
rede. Tambm fornece um mecanismo para agregar roteadores a limita a e propagao desnecessria de informaes de subrede; ca a co Permite a autenticao de rota utilizando diferentes mtodos para a autca e enticao de senha; ca Permite a transferncia e marcao de rotas externas inseridas em um Sise ca tema Autnomo-AS. Isto rastreia rotas externas inseridas por protocolos o externos como o BGP.
32.2.3
IGRP e EIGRP
O IGRP(Interior Gateway Routing Protocol) e o EIGRP(Enhanced Interior Gateway Routing Protocol) so protocolos de roteamento desenvolvidos pela a Cisco Systems, Inc. e, portanto, so considerados protocolos de roteamento a proprietrios. O IGRP foi desenvolvido especicamente para tratar problemas a associados ao roteamento em grandes redes de vrios fabricantes, que estivessem a alm do escopo de protocolos como o RIP. Como o RIP, o IGRP um protocolo e e de vetor de distncia. Entretanto, ao determinar o melhor caminho, ele tambm a e leva em considerao itens como largura de banda, carga, atraso e conabilidade. ca Os administradores de rede podem determinar a importncia dada a qualquer a uma dessas mtricas ou permitir que o IGRP calcule automaticamente o melhor e caminho. O EIGRP uma verso avanada do IGRP. Especicamente, o EIGRP e a c fornece ecincia operacional superior e une as vantagens dos protocolos de Link e State com as dos protocolos de vetor de distncia. a
321
Cap tulo 33
Redes Ethernet
A rede Ethernet um padro de rede local que foi padronizado pelo comit e a e IEEE 802 como IEEE 802.3. As redes Ethernet vm sendo, desde 1990, as mais e utilizadas para implementao de LANs. ca A Ethernet foi originalmente baseada na idia de comunicar computadores e a partir de um cabo coaxial compartilhado que funcionava como um meio de transmisso em broadcast. Dessa forma, os computadores disputam o meio para a realizar uma transmisso e podem ocorrer colises. Para controlar o acesso a o ao meio de transmisso e as colises, as redes Ethernet utiliza um protocolo a o chamado CSMA/CD (Carrier Sense for Multiple Access with Colision Detection), que ser detalhado mais adiante. a No entanto, essa congurao era problemtica na medida que problemas ca a em qualquer parte do cabo interrompiam a comunicao em toda a rede. Para ca contornar esse problema, foram introduzidos os os hubs. Porm, em termos do e dom nio de coliso, no h diferenas entre um hub e um cabo unico compara a a c tilhado, o que impe restries prticas ao tamanho da rede. A soluo para o co a ca esse problema a utilizao de switches, que limitam o dom e ca nio de coliso ` um a a enlace ponto-a-ponto.
33.1
Protocolo CSMA/CD
O CSMA/CD um protocolo que permite acesso mltiplo ao meio de transe u misso baseando-se em trs mecanismos bsicos que so: (i) escuta da pora e a a tadora; (ii) deteco de colises e (iii) mecanismo de conteno. O protocolo ca o ca funciona da seguinte maneira: 1. Um adaptador pode comear a transmitir a qualquer tempo, ou seja, no c a so utilizados compartimentos slots; a 2. Um adaptador nunca transmite um quadro quando percebe que que algum outro adaptador est transmitindo. Para isso, um adaptador que deseja a transmitir precisa escutar a portadora;
322
3. Um adaptador que est transmitindo aborta sua transmisso quando percebe a a que algum outro adaptador est transmitindo, ou seja, detecta colises. a o Alm disso, ao detectar uma coliso, um adaptador que est transmitindo e a a tambm emite um sinal de reforo de 48 bits (jam signal ) para garantir e c que os demais adaptadores tambm tomaro conhecimento da coliso; e a a 4. Aps abortar a transmisso o adaptador entra em fase de conteno, duo a ca rante a qual ter que esperar um tempo aleatrio antes de tentar transa o mitir novamente. Esse tempo determinado pelo algoritmo de backo e exponencial. O algoritmo de backof exponencial diz que, aps a deteco da n-sima coo ca e liso, um adaptador dever esperar por um tempo igual a 512Kt0 , onde t0 o a a e tempo de transmiso de um bit e K um valor escolhido com igual probabilia e dade entre o conjunto {0, 1, 2, ..., 2m 1}, sendo m igual ao m nimo entre n e 10. Dessa forma, aps um adaptador detectar uma coliso pela primeira vez (n = o a 1) escolher um valor de K no conjunto {0, 1}. No caso de uma rede de 10Mbps, a o tempo de transmisso de um bit igual a 0.1 microssegundos e supondo que a e o K escolhido seja 1, ento o adaptador ter que esperar por um tempo igual a a a 51.2 microssegundos antes de uma nova tentativa de transmisso. Aps a a o segunda deteco de coliso, o valor de K ser escolhido entre 0, 1, 2, 3. A partir ca a a da dcima coliso o valr de K ser escolhido no conjunto {0, 1, 2, 4, ..., 1023}. e a a
33.2
Fast Ethernet
O Padro Fast Ethernet (IEEE 802.3u) foi lanado em 1995 como a evoluo a c ca do padro Ethernet original. As principais modicaes introduzidas foram o a co aumento da velocidade de transmisso de 10 para 100 Mbps, a possibilidade a de transmisso no modo full-duplex. O protocolo de acesso ao meio utilizado a o CSMA/CD, assim como no padro Ethernet. No modo full-duplex, um e a adaptador est apto a receber e transmitir a qualquer momento e a utilizao a ca do CSMA/CD dispensada, na medida em que no existem mais colises nem e a o disputa pelo meio. No padro Fast Ethernet tambm foi introduzido um mecanismo de controle a e de uxo. Quando um receptor deseja que o tansmissor interrompa a transmisso a 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 transmisso a (time-to-wait). O padro Fast Ethernet subdividido em sub-padres de acordo com o meio a e o de transmisso utilizado. As principais sub-divises do padro Fast-Ethernet so a o a a as seguintes: 100Base-TX: E o sub-padro mais utilizado para redes Fast Ethernet. a Ele funciona sobre cabos UTP de categoria 5 ou superior, embora utilize apenas os pares laranja e verde do cabo de acordo com o padres de o terminao TIA/EIA-568A e TIA/EIA-568B. Cada enlace pode ter no ca 323
mximo 100 metros de comprimento. O esquema de codicao utilizado a ca no padro 100Base-TX o MLT-3; a e 100Base-FX: Essa uma verso que utiliza um par de bras pticas multie a o modo com terminadores do tipo SC, ST ou MIC. O esquema de codicao ca utilizado o NRZI; e 100Base-SX: Assim como o padro 100Base-FX, tambm utiliza um par de a e bras pticas multimodo. O padro SX difere do FX por utilizar ptica o a o de ondas de comprimento curto (short wavelength), o que o torna mais acess vel. No entanto, o padro FX permite alcanar distncias maiores; a c a 100Base-BX: Transmisso e recebimento so realizados por um unico cabo a a de bra, utiliza para isso, tcnicas de multiplexao por comprimento e e ca onda.
33.3
Gigabit Ethernet
Em 1999, o padro Gigabit Ethernet (IEEE 802.3z) extendeu a velocidade das a redes Ethernet de 100 Mbps para 1 Gbps. Assim como o Fast-Ethernet, o padro a Gigabit permite operao nos modos half e full-duplex e utiliza o mecanismo ca de controle de uxo baseado em pause frames.No modo half-duplex ainda utie lizado o protocolo CSMA/CD. No entanto, com aumento da velocidade de transmiso, para garantir que as a colises sejam corretamente detecadas pelo CSMA/CD, foi necessrio extender o a o slot-time m nimo de 64 para 512 bytes. Para cumprir este requisito utilizado e o campo carrier extension, que preenchido at que o slot-time de um quadro e e pequeno alcance 512 bytes. No receptor, o contedo do campo de extenso e u a descartado. A diferena entre o quadro Ethernet original e o quadro do padro c a Gigabit mostrada na gura 33.3. e
Figura 33.1: Quadros Ethernet e Gigabit Ethernet Utilizada puramente, esta modicao afeta o desempenho na transmisso ca a de quadros pequenos devido a grande quantidade de carga intil transmitida. u Para contornar esse problema, o padro Gigabit tambm utiliza o recurso de a e transmisso em rajadas (frame bursting), permitindo que um conjunto de paa cotes pequenos sejam transmitidos em conjunto dentro de um unico quadro. Assim como o padro Fast Ethernet, o padro Gigabit tambm tem suas a a e sub-divises. As princiapais so: o a 324
1000Base-SX: Este padro opera utilizando ptica de ondas de compria o mento curto sobre um par de bras multimodo. Com bras pticas de o qualidade j poss alcanar distncias maiores que 500 metros com a e ve c a esse padro; a 1000Base-LX: Opera utilizando ptica de ondas de comprimento longo, o permitindo alcanar distncias de at 20 kilmetros com bras monomodo. c a e o Quando utilizado com bras multi-modo permite distncias de at 500 a e metros; 1000Base-T: E o padro para redes gigabit que utiliza cabos UTP. O a requisito m nimo do padro um cabo da categoria 5, porm, cabos da a e e categoria 5e ou 6 so recomendados. A distncia mxima alcanada com a a a c este padro de 100 metros; a e 1000Base-CX: Criado como uma alternativa para distncias de at 25 a e metros. Ao invs de bra ptica, utiliza cabos twiaxiais. Na prtica so e o a a pouco utilizados, uma vez que o o padro 1000Base-T usa cabos UTP, que a so mais baratos e podem desempenhar a mesma funo; a ca 1000BASE-ZX e 1000BASE-LH: Esses dois padres utilizam transmisso o a em bra monomodo, usando um comprimento de onda de 1550 nanmetros o para alcanar distncias de at 70 kilmetros. c a e o
325
Cap tulo 34
Cabeamento Estruturado
34.1 Par Tranado c
O cabeamento por par tranado (Twisted pair) um tipo de ao na qual c e ca dois condutores so enrolados ao redor dos outros para cancelar interferncias a e magnticas de fontes externas e interferncias mtuas (crosstalk) entre cabos e e u vizinhos. A taxa de giro (normalmente denida em termos de giros por metro) parte da especicao de certo tipo de cabo. Quanto maior o nmero de e ca u giros, mais o ru cancelado. Foi um sistema originalmente produzido para do e transmisso telefnica analgica. Utilizando o sistema de transmisso por par a o o a de os aproveita-se esta tecnologia que j tradicional por causa do seu tempo ae de uso e do grande nmero de linhas instaladas. u Existem dois tipos de cabos par tranado: c Unshielded Twisted Pair - UTP (cabo sem blindagem): So quatro pares a de os entrelaados e revestidos por uma capa de PVC o mais usado c e atualmente e mais barato. Shield Twisted Pair - STP (cabo com blindagem): E igual ao UTP a diferena que possui uma blindagem feita com a malha do cabo, que o c e protege mais que o UTP. Porm mais caro, menos usado e necessita de e e aterramento. Este gnero de cabo, por estar revestido diminui as intere ferncias eletromagnticas externas, protege mais da umidade, etc. e e
Considerando que o fator principal para determinar o alcance mximo poss a vel de um sistema a atenuao do sinal ao longo do cabo, foi necessrio estabelecer e ca a alguns modos de classicao para o cabeamento em par metlico e o respectivo ca a hardware de conexo. Criou-se ento a subdiviso em uma srie de categorias e a a a e classes por capacidades de desempenho. Nessa classicao, uma categoria ou ca classe de desempenho superior do cabo signica maior ecincia e uma menor e atenuao. Dentre as categorias destacam-se a 5e e a 6. ca
34.1.1
Interferncias nos Cabos de Par Tranado e c
O Crosstalk no ocorre apenas no par adjacente (pair to pair NEXT), mas em a todos os outros pares de um cabo UTP podem interferir com seus prprios n o veis
326
em ambas as extremidades do cabo, multiplicando o efeito dessa interferncia e sobre o par transmissor ou receptor. Em razo destes n a veis de interferncia poderem debilitar redes de alta velocie dade, alguns fabricantes de cabos comearam a apresentar as taxas de NEXT, c FEXT, PSNEXT, ELFEXT e PS-ELFEXT para seus cabos CAT5e e Categoria 6. A Figura ?? ilustra essas interferncias e
Figura 34.1: Interferncias entre os em um cabo de par tranado e c O NEXT (Near-End Crosstalk) a interferncia no sinal de um par sobre e e um outro na mesma extremidade do cabo. O PS-NEXT uma medida de crosstalk mais rigorosa que inclui a soma e total de todas as interferncias que podem ocorrer entre um par e todos os e pares adjacentes de um cabo. O FEXT mede a interferncia de um par em uma extremidade do cabo em e outro par na outra extremidade do cabo. Essa medida utiliza operao full ca duplex para detectar onde os sinais so gerados simultaneamente em ambas as a extremidades. O ELFEXT (Equal-Level Far-End Crosstalk) mede o FEXT em relao ao ca n vel do sinal recebido medido no mesmo par. Ele mede basicamente a interferncia sem os efeitos da atenuao. e ca O PS-ELFEXT, uma medida comum em progresso, mede a soma total a de todas as interferncias dos pares de uma extremidade em um par da outra e extremidade sem os efeitos da atenuao. ca
34.2
Categorias 5e
A letra eno nome da categoria signica Enhanced, ou seja, a categoria 5e representa uma melhoria das caracter sticas dos materiais utilizados na categoria 5, permitindo um melhor desempenho. Pode ser usado para freqncias de at ue e 100MHz em redes 1000BASE-T e 1000BASE-TX. Ele igual a categoria 5, e porm com especicaes adicionais como os parmetros PS NEXT, Balano, e co a c PS ELFEXT, Return Loss. O cabeamento Categoria 5 normalmente direcionado para o mercado resie dencial, mas sua utilizao vem caindo devido ao seu custo ser praticamente o ca mesmo da Categoria 5e. Reforando essa armativa, nos projetos atuais de infrac estrutura recomendada a utilizao de cabeamento de, no m e ca nimo, Categoria 5e para pequenas redes com poucos servios ou que tenham carter provisrio c a o e Categoria 6 para as redes novas ou de maior porte.
327
34.3
Categoria 6
A Categoria 6 pode ser vista como um aperfeioamento no projeto de infrac estrutura das redes locais. Ela segue seus predecessores, as categorias 3, 4, 5 e 5e, cada uma provendo maior capacidade de transporte de informao para usurios ca a nais. Torna-se uma opo que oferece alta performance para a distribuio horca ca izontal em um sistema estruturado, permitindo suporte para aplicaes como co voz tradicional (telefone analgico ou digital), VoIP, Ethernet (10Base-T), Fast o Ethernet (100Base-TX) e Gigabit Ethernet a 4 pares (1000Base-T), com melhor performance em relao a Categoria 5e. Ela permite ainda suporte para ca aplicaes ATM e novas tecnologias como Ethernet a 10Gbps sem investimenco tos adicionais na infra-estrutura existente. Os sistemas Categoria 6 foram projetados para atender basicamente os seguintes objetivos: manter boa relao custo x benef dos sistemas UTP, bem como facilitar ca cio sua instalao e operao; ca ca garantir a interoperabilidade com os atuais sistemas Categoria 5e; roporcionar uma nova infra-estrutura com capacidade para servios fuc turos (redes de prxima gerao). o ca
34.4
Categoria 5e vs. Categoria 6
A principal diferena entre a Categoria 5e e a Categoria 6 est na performance c a de transmisso e na largura de banda estendida de 100MHz da Categoria 5e para a 250MHz da Categoria 6. A largura de banda a medida da faixa de freqncia e ue que o sinal de informao ocupa. O termo tambm usado em referncia `s ca e e e a caracter sticas de resposta em freqncia de um sistema comunicao. No senue ca tido mais qualitativo, a largura de banda proporcional ` complexidade dos e a dados transmitidos. J a performance se traduz em uma menor atenuao, mela ca hor NEXT, perda de retorno e ELFEXT, possibilitando uma melhor relao ca sinal/ru do. Devido a esses fatores (performance e largura de banda), associando uma melhor imunidade `s interferncias externas, os sistemas que operam em Cata e egoria 6 so mais estveis em relao aos sistemas baseados na Categoria 5e. a a ca Isto signica reduo nas retransmisses de pacotes, proporcionando uma maior ca o conabilidade e estabilidade para a rede. Outro fato que deve ser considerado que os requisitos para o link (meio de e transmisso entre dois pontos, no incluindo a conexo de equipamentos) e canal a a a (meio de transmisso m-a-m entre dois pontos no qual existem equipamentos a de aplicaes espec co cos conectados) na Categoria 6 so compat a veis com os da Categoria 5e, fazendo com que os projetistas escolham a Categoria 6, substituindo as redes Categoria 5e. A tabela 34.2 resumo as principais informaes co sobre as categorias de cabos UTP.
328
Figura 34.2: Principais Caracteristicas do cabeamento UTP
34.5
Cabeao Estruturada Norma EIA/TIA ca 568
Pode-se denir a cabeao estruturado como um sistema baseado na padronizao ca ca das interfaces e meios de transmisso, de modo a tornar o cabeao independente a ca da aplicao e do layout. O cabeao estruturado descreve ainda os sistemas de ca ca rede interna e de campus e sua interconexo com a planta externa. a
34.5.1
Sistemas de Cabeamento Estruturado
Reconhecendo a necessidade de padronizar o Sistema de Cabeao Estrutuca rado diversos prossionais, fabricantes, consultores e usurios reuniram-se sob a a orientao de organizaes como ISO/IEC, TIA/EIA, CSA, ANSI, BICSI e ca co outras para desenvolver normas que garantissem a implementao do conceito ca do mesmo. Apesar deste trabalho resultar em diversas normas a mais conhecida no Brasil a ANSI/TIA/EIA 568-A (verso revisada da ANSI/TIA/EIA 568 e a que inclui as especicaes para cabeao categoria 4 e 5) co ca O conceito de Sistema de Cabeao Estruturada baseia-se na disposio ca ca de uma rede de cabos, com integrao de servios de dados e voz, que facilca c mente pode ser redirecionada por caminhos diferentes, no mesmo complexo de cabeao, para prover um caminho de transmisso entre pontos da rede distinca a tos. Um Sistema de Cabeao Estruturada EIA/TIA 568A formado por seis ca e subsistemas conforme ilustrado na gura 34.3 e descritos a seguir.
Entrada do Edif cio; Sala de Equipamentos; Cabeao do Backbone; ca Armrio de Telecomunicaes; a co Cabeao Horizontal; ca Area de Trabalho. As instalaes de entrada no edif fornecem o ponto no qual feita a interco cio e face entre a cabeao externa e a cabeao intra-edif e consistem de cabos, ca ca cio 329
Figura 34.3: Sistema de Cabeao Estruturada ca equipamentos de conexo, dispositivos de proteo, equipamentos de transio a ca ca e outros equipamentos necessrios para conectar as instalaes externas ao sisa co tema de cabos local. As salas de equipamento geralmente alojam equipamentos de maior complexidade que os do armrio de telecomunicaes. Qualquer uma ou todas das a co funes de um armrio de telecomunicaes podem ser atendidas por uma sala co a co de equipamentos. Ela tambm contm a conexo cruzada principal ou a conexo e e a a secundria, usada conforme a hierarquia do sistema de cabeao backbone. a ca O subsistema de cabeamento backbone, tambm chamado de cabeamento e vertical, propicia a interligaao entre os armrios de telecomunicaes, salas c a co de equipamento e instalaes de entrada. Ele consiste dos cabos de Backco bone, cross-connects intermedirio e principal, terminaes mecnicas e cabos a co a de conexo ou de jumper utilizados para a ligao de backbone para backbone. a ca Isto inclui: Ligao vertical entre os pisos (subidas ou risers) ca Cabos entre a sala de equipamentos e o local das instalaes de entrada co dos cabos no prdio e Cabos entre os prdios (inter-prdios) e e
Os cabos homologados na norma EIA/TIA 568A para utilizao como Backca bone so mostrados na tabela 34.1: a Tipos Cabo UTP de 100 ohms (22 ou 24 AWG) Cabo STP (par tranado blindado) de 150 ohms c Fibra Optica Multimodo de 62,5/125 m Fibra Optica Monomodo de 8,5/125 m Distncias Mximas a a 800 metros(2625 ps) Voz e 90 metros(295 ps) Dados* e 2000 metros (6560 ps) e 3000 metros (9840 ps) e
Tabela 34.1: Cabos homologados para cabeao Backbone e as respectivas ca distncias mximas a a 330
Vale ressaltar que o alcance do Backbone depende da aplicao. As distncias ca a mximas especicadas acima so baseadas na transmisso de voz em UTP e de a a a dados em STP e bras pticas. A distncia de 90 metros para STP d-se para o a a aplicaes com um espectro de largura de banda de transmisso de 20 a 300 co a MHz. Esta mesma distncia tambm se aplica ao UTP para espectros com a e 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 so: a Topologia em estrela No possuir mais do que dois n a veis hierrquicos de cross-connects a No so permitidos Bridge Taps a a Os cabos de conexo ou de jumper no cross-connect principal ou intera medirio no podem exceder 20 metros (66 ps) a a e Evitar a instalao em areas onde existam fontes de interferncias eletroca e magnticas ou de rdio freqncia. e a ue As guras 34.4 e 34.5 representam o modelo geral de cabeamento backbone em topologia estrela e as respectivas conguraes limites. co
Figura 34.4: Cabeamento Backbone em topologia estrela
Figura 34.5: Estrutura geral e as conguraes limites para o subsistema de co cabeao Backbone ca
331
O armrio de telecomunicaes a rea dentro de um edif a co e a cio que aloja o equipamento do sistema de cabeamento de telecomunicaes. Inclui as terco minaes mecnicas e/ou cross-connects para o sistema de cabeamento horizonco a tal e backbone. O subsistema de Cabeao Horizontal compreende os cabos que vo desde a ca a Tomada de Telecomunicaes da Area de Trabalho at o Armrio de Telecomuco e a nicaes. O subsistema de Cabeao Horizontal possui os seguintes elementos: co ca Cabeao Horizontal; ca Tomada de Telecomunicaes, tambm chamado Sa de Informao; co e da ca Terminaes de Cabo; co Cross-Connections. Existem trs tipos de meios de transmisso a serem considerados como opes e a co para o cabeamento horizontal, todos para a distncia mxima de 90 metros: a a Cabo UTP de 4-pares, 100 ohms (condutores slidos de 24 AWG) o Cabo STP de 2-pares, 150 ohms Cabo de Fibra Optica de 2-bras, 62,5/125 m Atualmente o cabo coaxial de 50 ohms reconhecido como um meio de e transmisso. Entretanto, no recomenda-se a sua utilizao em instalaes noa a ca co vas. Espera-se a remoo deste meio na prxima reviso desta norma. ca o a A gura 34.6 apresenta as distncias limites para o subsistema de cabeo a ca horizontal bem como para o subsistema da rea de trabalho que ser apresentado a a em seguida.
Figura 34.6: Distncias limite para os subsistemas de cabeao horizontal e rea a ca a de trabalho A norma prev 100 metros total para a Cabeao Horizontal: 90 metros entre e ca o Armrio de Telecomunicaes e as Tomadas de Telecomunicaes (conectores a co co de parede); 10 metros para cabos entre uma estao de trabalho e o conector ca
332
de parede, (em geral, 3 metros) mais as conexes internas do Armrio de Teleo a comunicaes e entre este e os equipamentos ativos (7 metros restantes). Em co complemento, cada rea de trabalho deve ter no m a nimo DUAS posies de co sa de informao: uma para voz e outra para dados. da ca
Figura 34.7: Tomada de Telecomunicaes co Os componentes da rea de trabalho estendem-se da tomada de telecomua nicaes at o equipamento da estao. A ao da rea de trabalho projetada co e ca ca a e para ser de interconexo relativamente simples, de forma que deslocamentos, exa panses e alteraes possam ser efetuados com facilidade. Os componentes da o co a rea de trabalho so: a Equipamento da estao: computadores, terminais de dados, telefone, etc.; ca Cabos de ligao - cordes modulares, cabos de adaptao, jumpers de ca o ca bra; Adaptadores. Nesse contexto, a gura 34.8 ilustra o Sistema de Cabeo Estruturada ca EIA/TIA 568:
Figura 34.8: Sistema de Cabeao Estruturada ca
34.6
Desempenho do Hardware e Meios de Transmisso a
A norma EIA/TIA 568 classica o sistema de cabeao em categorias levando ca em considerao aspectos de desempenho, largura de banda, comprimento, ca atenuao e outros fatores de inuncia neste tipo de tecnologia. A seguir, ca e 333
sero apresentadas as categorias de cabeao com tecnologia de par tranado a ca c UTP e de bra ptica. o
34.6.1
Cabeamento UTP
Os cabos UTPs so compostos de pares de os tranados no blindados de 100 a c a Ohms. Este tipo de cabo, nos dias de hoje, so projetados para alto desempenho a na transmisso de dados ou voz. Segundo a norma, o cabo UTP pode ser a classicado em trs categorias como mostrado abaixo: e Categoria 3 - Utiliza cabos com pares de os tranados slidos de bitola 24 c o AWG. Os os AWG24 apresentam uma impedncia t a pica de 100 Ohms, a 16 MHz. Estes cabos so utilizados para transmisso de sinais at 16 a a e MHz. Categoria 4 - Utiliza cabos com pares de os tranados slidos de bitola c o 22 ou 24 AWG, com impedncia de 100 Ohms a 20 MHz. Este cabos so a a utilizados para transmisso at uma largura de banda de 20 MHz; a e Categoria 5 - Utiliza cabos com pares de os tranados sem blindagem c de bitola 22 ou 24 AWG e impedncia de 100 Ohms a 100 MHz. Este a tipo de categoria recomendvel para aplicaes com taxa de transmisso e a co a elevada, por exemplo, para transmisso de imagens e dados a 100 Mbps. a A atenuao comumente derivada da medida do sinal de varredura da ca e freqncia na sa de um cabo de comprimento maior ou igual a 100 metros ue da (328 ft), ou seja, a perda de potncia do sinal no meio, em funo da distncia a e e ca a uma determinada freqncia. As perdas por diafonia ou NEXT so comumente ue a derivadas de medidas de varredura de freqncia. Por exemplo, na comunicao ue ca de voz, seus efeitos so sentidos por linhas cruzadas, isto , vozes estranhas que a e so escutadas durante uma ligao telefnica. A impedncia caracter a ca o a stica do cabo UTP para Cabeao Horizontal e Backbone de 100 Ohms + 15% de 1 ca e MHz at a maior freqncia da categoria (16, 20 ou 100 MHz). e ue Em complemento, os Terminadores para cabo UTP devem utilizar contatos por deslocamento por isolador (IDC). Os limites mximos para jumper/cordes a o de ligao so: ca a 20 m para cross-connect principal; 20 m para cross-connect intermedirio; a
6 m no armrio de telecomunicaes; a co 3 m na estao de trabalho. ca A terminao dos cabos horizontais dever ser feita com material de conexo ca a a da mesma categoria ou superior do cabo UTP utilizado na Cabeao Horizontal. ca Por outro lado, os cabos utilizados para cordes de ligao e jumpers de crosso ca connect devem pertencer ` mesma categoria do cabo UTP usado na Cabeao a ca Horizontal. Assim, um sistema de cabeao UTP s poder ser classicado como ca o a categoria 3, 4 ou 5 se todos os componentes do sistema de cabeao atenderem ca aos requisitos da categoria.
334
34.6.2
Fibra Optica
A bra ptica pode ser utilizada tanto para a Cabeao Horizontal como para a o ca Vertical. A bra para Cabeao Horizontal do tipo multimodo de 62,5/125mm ca e com um m nimo de duas bras. A Cabeao Vertical ou Backbone utiliza bras ca dos tipos multimodo de 62,5/125mm e monomodo formados em grupos de 6 ou 12 bras. As premissas para uma Cabeao Backbone com bra pticas, tm sido ca o e e continuam a ser baseadas em bras multimodo de 62,5/125mm, devido ` a possibilidade de uso de transmissores pticos com LED nessas bras. Com o o rpido crescimento dos requisitos de largura de banda, atualmente, tem-se a instalado bras pticas monomodo em adio `s bras multimodo, para atender o ca a os requisitos atuais e futuros. Sistemas de bras monomodo atendem tanto maiores bandas de freqncias como tambm tm maior capacidade para longas ue e e distncias do que as bras pticas multimodo. A Figura 34.9 ilustra os tipos de a o bras pticas empregados. o
Figura 34.9: Tipos de Fibras Opticas Os conectores especicados para bra ptica so os 568SC. Os conectores o a o pticos seguem um esquema de cores para sua identicao. A cor bege especica ca o conector/acoplamento multimodo de 62,5/125mm e a cor azul especica o conector/acoplamento monomodo de 8,3/125mm. Para assegurar que os conectores 568SC mantero uma correta polarizao a ca atravs do sistema de cabeao, deve-se ter uma correta orientao do adaptador e ca ca utilizado. A Cabeao Horizontal deve ser instalada de tal forma a casar um ca nmero u mpar da bra com o prximo nmero par da bra, por exemplo: bra o u 1 com bra 2; bra 3 com bra 4 e assim sucessivamente. Cada segmento da cabeao deve ser instalado seguindo a orientao invertida (cross-over) do par, ca ca de tal modo que bras de nmero u mpar so posio A numa ponta e posio B a ca ca na outra ponta, enquanto que bras de nmero par so posio B numa ponta u a ca e posio A na outra ponta. ca A orientao invertida (cross-over) deve ser conseguida pelo uso consecutivo ca da numerao das bras (por exemplo 1, 2, 3, 4, ...) em ambos os lados da ca bra, 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 especicao dos conectores de bra 568SC a ca e padronizao com a norma IEC Europia. Hoje so muito utilizados conectores ca e a ST. Entretanto, recomendado a substituio gradativa dos conectores ST por e ca 568SC. 335
A norma EIA/TIA 568A especica, tambm, as sa e das de telecomunicaes co para bra ptica com as seguintes caracter o sticas: A caixa de montagem em superf deve ser xada diretamente sobre a cie caixa eltrica, seguindo um padro de 4x 4; e a A capacidade de terminao para um m ca nimo de duas bras, por acoplamento 568SC; Possibilidade de armazenar um m nimo de 1 metro de cabo de duas bras.
34.7
Cdigo de Cores para Sistemas de Cabeo o ca UTP
A EIA/TIA 568A dene um sistema de codicao com quatro cores bsicas, ca a em combinao com o branco, para os condutores UTP de 100 Ohms, assim ca como a ordem dos pares no conector RJ-45, conforme ilustrado na gura 34.10.
Figura 34.10: Cdigo de cores EIA/TIA 568A o Um outro padro de cores da cabeao UTP, derivado da EIA/TIA 568A, o a ca padro EIA/TIA 568B, no muito utilizado nos dias atuais, dene a seqncia a a ue de cores da gura 34.11.
Figura 34.11: Cdigo de cores EIA/TIA 568B o
336
Cap tulo 35
Redes sem o
Os principais elementos de uma rede sem o so: a Hospedeiros sem o: So os sistemas nais que executam as aplicaes, a co por exemplo, um celulare, um PDA, um notebook etc; Enlace sem o: Os hospedeiros se conectam ao restante da rede por meio de um enlace de comunicao sem o. Tecnologias de enlace sem o tm ca e diferentes taxas de transmisso e podem transmitir ` distncias diferentes. a a a Outra caracter stica relevante dos enlaces sem o a grande taxa de erros e de bits, que obriga os protocolos de enlace sem o a empregarem mecanismos mais sosticados de deteco de erros e retransmiso; ca a Estao-base: E a responsvel pelo envio e recebimento dos dados de e ca a para os hospedeiros sem o ` ela associados. Exemplos de estao-base a ca so torres celulares, pontos de acesso de uma rede 802.11 etc. Em geral, a as estaes-base esto ligadas ` uma infra-estrutura maior de rede (uma co a a LAN cabeada, a internet etc.) que responsvel pelo fornecimentos dos e a servios mais comuns como atribuio de endereo e roteamento. Quando c ca c isso acontece dito que a rede est operando no modo de infra-estrutura. e a Algumas tecnologias de rede sem o permitem que os dispositivos mveis se o comuniquem diretamente sem a necesidade de uma estao base. Esse modo de ca operao chamado ad hoc. Nesse caso os prrprios hospedeiros sem o devem ca e o ser capazes de fornecer servios bsicos de atribuio de endereo, roteamento, c a ca c resoluo de nomes etc. ca
35.1
O padro IEEE 802.11 a
O IEEE 802.11, tambm conhecido como Wi-Fi, a tecnologia mais utilizada e e atualmente para implementaao de redes locais sem o. Entre os padres 802.11 c o que mais se destacam esto o 802.11a, 802.11b e 802.11g. Esses trs padres a e o compartilham caracter sticas como formato do quadro, protocolo de acesso ao meio, capacidade de reduzir taxa de transmisso para alcanar distncias maiores a c a e a possibilidade de operar tanto em modo de infra-estrutura como em modo ad hoc. As diferenas entre os padres a, b e g se concentra na camada f c o sica de acordo com a tabela 35.1. 337
Padro a 802.11b 802.11a 802.11g
Faixa de Frequncia e 2.4-2.485 GHz 5.1-5.8 GHz 2.4-2.485 GHz
Taxa de Dados at 11 Mbps e at 54 Mbps e at 54 Mbps e
Tabela 35.1: Resumo dos Padres 802.11 o O padro 802.11b atualmente o mais utilizado devido ` sua boa relao a e a ca custo-benef cio. Em seguida est o padro 802.11g, que vm se estabelecendo a a e por permitir operao ` taxas mais elevadas e distncias equivalentes ao padro ca a a a 802.11b. Embora alcance taxas to elevadas quanto o o padro 802.11g, o a a padro 802.11a alcana distncias menores. Em contrapartida, o padro 802.11a a c a a menos suscet e vel `s intereferncias introduzidas por telefones celulares, mia e croondas e bluetooth, que operam na faixa de 2.4 GHz assim como os padres o 802.11b e 802.11g.
35.1.1
CSMA/CA
O protocolo de acesso ao meio utilizado pelas redes do padro 802.11 o a e CSMA/CA (Carrier Sense for Multiple Access with Colision Avoidance). Esse protocolo se baseia no fato de que extremamente dif detectar colises em e cil o enlaces sem o, e por isso, tenta evit-las sempre que poss a vel. O CSMA/CA funciona da seguinte maneira: 1. Se a estao perceber que o canal est ocioso, ela transmitir o quadro ca a a aps um curto espao de tempo conhecido como DIFS (Distributed Intero c Frame Space); 2. Caso contrrio, a estao escolher um valor aleatrio de backo e iniciar a ca a o a a contagem regressiva a partir desse valor assim que detectar o canal ocioso; 3. Quando o contador chegar a zero, a estao transmitir o quadro inteiro ca a e car esperando por uma conrmao. Caso o receptor receba o quadro a ca corretamente, ele esperar um tempo curto chamado SIFS (Short Intera Frame Space) e ento enviar a conrmao; a a ca
4. Se a estao receber a conrmao e tiver outro quadro para transmitir, ca ca ento ela ela ir iniciar o protocolo a partir da fase 2. Caso no receba nena a a huma conrmao, voltar para fase 2 porm ir escolher por um backo ca a e a dentro de um intervalo de tempo maior. A caracter stica mais importante do protocolo CSMA/CA que mesmo que e uma estao detecte que o canal est ocioso, ela adia a transmisso por um ca a a curto per odo de tempo aleatrio. Se ao detectar o canal ocupado cada uma o das estaes escolher um valor de backo diferente das demais, ento uma delas co a ir comear a trasmitir primeiro. As demais, ao escutar o canal ocupado, intera c romperam seus contadores e aguardarm pelo trmino da transmisso. e a
338
O padro 802.11 conta ainda com um mecanismo de reserva de canal que a ajuda a evitar colises. O mecanismo baseado no envio de quadros especiais o e chamados RTS (Request to Send ) e CTS (Clear to Send ). Quando um transmissor deseja enviar um quadro de dados DATA, ele pode solicitar a reserva do canal enviando um quadro RTS para a estao-base. O RTS indica o tempo ca total necessrio para a transmisso de DATA. Ao receber o RTS, a estaoa a ca base envia um quadro CTS em broadcast para toda a rede. O quadro CTS tem como nalidade dar permisso para o envio do quadro DATA e instruir os a demais transmissores a no enviarem nada durante o tempo reservado. a
35.1.2
Formato do Quadro 802.11
A caracter stica mais marcante de um quadro 802.11 que ele tm 4 campos e e de endereo, cada um podendo conter um endereo MAC de 6 bytes. Em redes c c 802.11 operando no modo infra-estrutura 3 desses campos so necessrios (o a a outro s utilizado no modo ad hoc). O campo endereo 1 contm o MAC o e c e do dispositivo sem o destinatrio, enquanto o endereo 2 contm o MAC do a c e dispositivo sem o remetente. O campo endereo 3 contm o endereo MAC do c e c dispositivo Ethernet com o qual a estao base est conectada, por exemplo, ca a um roteador. A estao-base , portanto, o dispositivo de camada de enlace ca e responsvel por intermediar a comunicao dos dispositivos sem o com a rede a ca cabeada. Alm dos campos de endereo, tambm merecem destaque os campo CRC e c e (Cyclic Redundancy Check ), que permite deteco de erros de bits, e o campo ca de nmero de sequncia, que permite que o mecanismo de conrmao funcione. u e ca O formato completo do quadro 802.11 pode ser visto na gura 35.1.2.
Figura 35.1: Formato do quadro 802.11
339
Cap tulo 36
Elementos de Interconexo a de Redes de Computadores

36.1 Repetidores
So elementos que interligam dois segmentos de um mesmo dom a nio de coliso. a Os sinais eltricos que trafega em ambos sentidos so amplicados analogicae a mente permitindo comunicaoes em maiores distncias. Portanto, estes elemenc a tos operam na CAMADA F ISICA do modelo OSI. Estes equipamentos deixaram de ser largamente utilizados devido ao fato dos hubs ativos, switches, gateways e roteadores terem passado a exercer tambm a e funo de amplicao. ca ca
36.2
Hubs
Este um termo genrico para CONCENTRADORES. Eles so elementos de e e a CAMADA F ISICA do modelo OSI. Portanto, todos os ns conectados a um hub, o ou a um conjunto de hubs interconectados, fazem parte de um mesmo dom nio de coliso (topologia barramento). Desta forma, cada n deve ser capaz de dea o tectar colises e decidir o momento de realizar transmisses e/ou retransmisses. o o o Duas caracter sticas importantes so: como um hub dene um unico dom a nio de coliso comum a todas as portas, a princ a pio ele no permite a interconexo a a de segmentos que utilizam tecnologias distintas (taxas, protocolo de camada 2, etc.); um hub no implementa nenhum tipo de controle de acesso, e sim encama inha os bits de uma porta para as demais. Estes concentradores podem ser classicados em quatro grupos: Hubs Passivos: hubs que no implementam a funo de repetio, ou seja, a ca ca no funcionam como repetidores. Estes equipamentos no necessitam de a a nenhuma alimentao eltrica. Eles no possuem nenhum mdulo microca e a o processado. Um exemplo so os patch painels; a
340
Hubs Ativos: hubs que implementam a funo de repetio. Assim como ca ca os passivos, eles no possuem nenhum mdulo microprocessado. A grande a o maioria dos hubs utilizados ultimamente pertence a este grupo; Hubs Inteligentes: hubs que possuem mdulos microprocessados que reo alizam monitoramento e diagnstico. As funcionalidades dependem do o projeto do fabricante, por exemplo, eles podem: detectar e se preciso desconectar da rede estaes com problemas, evitando que uma estao co ca faladora prejudique o trfego ou mesmo derrube a rede inteira; detectar a e impedir tentativas de invaso ou acesso no autorizado ` rede; monia a a torar/informar o n de utilizao de cada porta; e possibilitar operao vel ca ca de taxas diferentes entre as portas (ex. 10Mbps e 100Mbps). Geralmente estes hubs tambm so classicados como ativos; e a Hubs Empilhveis: hubs que possuem portas denominadas Up-Links. Esa tas portas permitem o empilhamento de hubs atravs de CABOS DIREe TOS. Na prtica, qualquer hub pode ser empilhado a outro, a diferena a c que no caso de hubs no-empilhveis (sem porta do tipo Up-Link) deve e a a ser utilizado um CABO CROSS-OVER.
36.3
Switches
Estes so elementos de CAMADA DE ENLACE do modelo OSI tambm denoma e inados de COMUTADORES. Geralmente eles funcionam tambm como repetie dores. Diferentemente dos hubs, os switches dividem a rede em dom nios de coliso (um dom a nio por porta). Desta forma, o switch ao comutar um quadro de um dom nio para outro deve ser capaz de implementar algum tipo de controle de acesso para ser poss detectar colises e decidir o momento de realizar vel o transmisses e/ou retransmisses. o o Uma outra caracter stica importante presente no switches a possibilidade e deles interconectarem segmentos com tecnologias distintas. Ou seja, este tipo de comutador pode ser multiprotoloco (exige converso de um tipo de quadro a em outro - ex. Ethernet em FDDI). Alguns switches tambm so capazes de e a administrar mltiplas taxas de transmisso. Quando ele capaz de detectar u a e automaticamente a taxa de transmisso utilizada em uma determinada porta e a se auto congurar para esta taxa, diz-se que este switch AUTO-SENSING. e
As comutaes so realizadas por meio de consultas a tabelas dinmicas que co a a armazenam endereos f c sicos, e seus respectivos, nmero da interface (porta) u e horrio da ultima comutaao. Os switches so equipamentos plug-and-play a c a devido ao fato de sua tabela de comutao ser preenchida de forma automtica ca a 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 no h nenhuma entrada na tabela a a para o endereo f c sico de destino, ele replica este quadro em todas as outras interfaces (portas). Todas as vezes que um n envia um quadro a qualquer o outro n, seu endereo f o c sico registrado na tabela juntamente com o nmero e u da interface onde ele est conectado ao switch. a
341
Todo switch realiza no m nimo duas operaes bsicas utilizando sua tabela co a de comutao. A FILTRAGEM que a capacidade de determinar se um quadro ca e deve ser repassado para alguma interface ou se ele deve ser descartado. E o REPASSE que a capacidade de determinar para qual interface o quadro deve e ser dirigido. Estes comutadores podem operar em duas formas distintas. So elas: a Store-and-forword - a seqncia de comutao a seguinte: o quadro ue ca e e recebido na porta de entrada; este quadro armazenado em um buer e interno; realizada a ltragem/repasse; o quadro copiado no buer da e e porta de sa da. Este tipo de comutao geralmente implementado por ca e elementos de hardware e software (principalmente) em conjunto; Cut-Through (Acelerada ou De Corte) - a seqncia de comutao a ue ca e seguinte: ` medida que o quadro vai sendo recebido de forma seqencial a u na porta de entrada, assim que os primeiros bits que denem o endereo c f sico de sa acabam de chegar, a ltragem/repasse realizada e ento da e a este quadro j vai sendo copiado no buer da porta de sa a da. E importante notar que o quadro j comea a ser copiado no buer de sa antes a c da mesmo dele ter sido totalmente recebido na porta de entrada. Nos casos onde os bueres de sa esto geralmente vazios (sem la de transmisso), da a a esta forma de operao traz benef ca cios considerveis no desempenho da coa mutao. Este tipo de comutao geralmente implementado por somente ca ca e elementos de hardware.
36.4
Bridges
As bridges (PONTES) so muito semelhantes aos switches. Na verdade, muitas a pessoas usam ambos os termos de forma intercambivel. A principal diferena a c que os switches so usados com maior freqncia para conectarem computae a ue dores individuais, enquanto as bridges so mais usadas para conectarem redes. a Contudo, todas as caracter sticas dos switches apresentadas na seo anterior ca tambm esto presentes nas bridges. e a
36.5
Roteadores
So elementos da CAMADA DE REDE do modelo OSI. Eles tambm gerala e mente funcionam como repetidores, ou seja, regeneram os sinais recebidos antes de realizarem a comutao. Assim como os switches e bridges, os roteadores ca tambm so COMUTADORES, porm com uma complexidade muito maior. O e a e que reete no tempo de comutao e tambm nos recursos dispon ca e veis. Seu papel fundamental escolher, por meio de algum algoritmo de roteae mento, uma dentre as eventuais muitas rotas entre um n de origem e um n o o de destino. Vale ressaltar que no caso dos switches e bridges a comutao ca e mais fcil, visto que a rota unica, o que nem sempre acontece no caso das a e roteadores. Uma caracter stica muito importante dos roteadores a capacidade e
342
de interconectar redes que utilizam tecnologias diferentes (arquiteturas diferentes). Isto s poss quando o roteador capaz de entender e converter oe vel e um datagrama de uma tecnologia em outro datagrama de outra tecnologia (ex. IP e ATM). Outras caracter sticas tambm importantes so: a comutao no se limita a e a ca a uma SPANNING-TREE (grafo sem loopings - caminhos unicos entre quaisquer dois ns) como os comutadores de camada de enlace; possibilita proteo contra o ca broadcast em excesso; possibilita proteo de rewall; e no um equipamento ca a e plug-and-play tendo em vista que os endereos de rede so lgicos (no-xos) e c a o a no f a sicos (xos) e devem ser programados de alguma forma; e a comutao ca necessariamente realizada no modo store-and-forword (nunca no modo cute through).
36.6
Gateways
Estes elementos podem ser divididos em duas grandes classes: Gateways Conversores de Meio e Gateways Tradutores de Protocolos. Os Conversores de Meio so exatamente os roteadores multiprotocolo. Ou a seja, so elementos de CAMADA DE REDE do modelo OSI. a J os Tradutores de Protocolos podem ser elementos de CAMADA DE a TRANSPORTE ou CAMADA DE APLICACAO. Fundamentalmente os primeiros realizam converses entre segmentos (unidade de camada de transporte) de proo tocolos distintos e os ultimos realizam converses entre mensagens (unidade de o camada de aplicao) de protocolos distintos. Vale ressaltar que durante as conca verses o que se busca e manter a semntica dos dados. Por isso, nem sempre o a e poss converter um protocolo em outro. vel
343
Cap tulo 37
Redes Multim dia

37.1 Qualidade de Servio c
Um uxo uma sequncia de pacotes de uma origem at um destino. Em uma e e e rede orientada a conexes os pacotes de um determinado uxo seguem uma o mesma rota, enquanto em uma rede no orientada a conexes, eles podem seguir a o rotas diferentes. Nesse contexto, Qualidade de Servio (QoS) pode ser denido c em termos do conjunto de requisitos de um determinado uxo de pacotes. Os requisitos mais comuns so os seguintes: a Conabilidade: Garantia da entrega dos pacotes e da integridade dos dados transmitidos. Retardo: Atraso total na transmisso de um pacote da origem at o desa e tino. Flutuao (Jitter ): E a variao do atraso entre os pacotes. Em outca ca ras palavras, a variaao do intervalo de tempo entre os recebimento de e c pacotes subsequentes de um determinado uxo. Largura de Banda: Taxa com a qual os dados so transmitidos. a A rigidez dos requisitos das aplicaes mais comuns mostrada na tabela a co e 37.1: No que diz respeito ` conabilidade, por exemplo, pode-se dizer que o servio a c de correio eletrnico mais sens do que uma aplicao de v o e vel ca deo sob demanda, j que o corrompimento dos dados pode invalidar por completo uma mensagem. a Em uma aplicao de v ca deo sob demanda pode conviver com alguns pacotes com erro sob pena da perda parcial da qualidade do v deo. E por esse motivo que em redes TCP/IP aplicaes de multim co dea, geralmente, utilizam servios c da camada de transporte baseados em UDP e no em TCP, evitando os atrasos a gerados pelo estabelecimento de conexo, conrmaes e retransmisses. a co o No entanto, para alcanar qualidade de servio de forma eciente e segura c c necessrio combinar vrias tcnicas que podem ir alm da escolha de um e a a e e protocolo. Exemplos de tcnicas para alcanar QoS so: e c a
344
Aplicao ca Correio Eletrnico o Transferncia de Arquivos e Acesso ` Web a Login Remoto Audio por demanda V deo por demanda Telefonia Videoconferncia e
Conabilidade Alta Alta Alta Alta Baixa Baixa Baixa Baixa
Retardo Baixa Baixa Mdia e Mdia e Baixa Baixa Alta Alta
Jitter Baixa Baixa Baixa Mdia e Alta Alta Alta Alta
Largura de Banda Baixa Mdia e Mdia e Baixa Mdia e Alta Baixa Alta
Tabela 37.1: Rigidez dos Requisitos das Alicaes de Rede co Superdimensionamento: Consiste em fornecer tanta capacidade de buers e largura de banda de forma que dicilmente os pacotes sero descartados a ou sofrero atrasos. Logicamente essa a soluo tem um custo altamente a e ca elevado; Armazenamento em Buers: Consiste em armazenar os uxos em buers no lado do receptor e entreg-los apenas no momento oportuno suavizando a o jitter. Essa tcnica no inclui alteraes na largura de banda, porm e a co e aumenta o atraso e exige buers maiores do lado do receptor. Muitos reprodutores de udio e v a deo se utilizam dessa tcnica; e Moldagem de Trfego: Muitas vezes uma mquina pode transmitir pacotes a a com espaamento no uniforme, o que pode gerar congestionamento na c a rede. A moldagem de trfego est relacionada ` regulagem da taxa mdia a a a e de transmisso dos dados. Para realizar tal tarefa so utilizadas tcnicas a a e como o algoritmo do balde furado (leaky bucket) ou o algoritmo do balde de s mbolos (token bucket); Reserva de Recursos: Se for poss fazer com que todos os pacotes de um vel uxo sigam a mesma rota, torna-se poss reservar recursos para garanvel tir que a capacidade necessria estar dispon a a vel. Portanto, As aplicaes co so responsveis por denir os seus requisitos quanto a utilizao dos rea a ca cursos de CPU, espao em buers e largura de banda. O conjunto desses c parmetros chamado especicao de uxo, e com base nele que os a e ca e roteadores ao longo da rota decidem se vo ou no aceitar o uxo. Ao a a longo do caminho da origem ao destino, os requisitos da especicao ca de uxo podem ser alterados para baixo (ex: diminuio da largura de ca banda, diminuio do pacote de tamanho mximo etc.). Ao m do camca a inho origem destino os parmetros esto ajustados conforme a capacidade a a dos roteadores intermedirios, e a transmisso pode ser iniciada ou no. a a a Esse processo conhecido como controle de admisso; e a Enleiramento Prioritrio: Utilizao de mltiplas las, cada uma com a ca u uma prioridade asociada. Cada pacote que chega direcionado ` uma das e a las de acordo com sua classe. Os pacotes a serem transmitidos so sempre a aqueles da la de maior prioridade que ainda no est vazia. Algumas a a 345
implementaes permitem a interrupo de uma transmisso de um pacote co ca a de prioridade mais baixa para transmisso de um pacote de prioridade a masi alta (preempo). ca Varredura C clica e WQF: Na varredura c clica os pacotes so classicaa dos e colocados em las de sa da mesma forma que no enleiramento da prioritrio. No entanto, nessa disciplina o escalonador alterna o direito de a transmitir de forma c clica a cada per odo (Ex: la 1, la 2, la 3, la 1, la 2, la 3 etc.). No WQF (Weighted Fair Queuing ou Enleiramento Justo Ponderado) o direito de transmitir ponderado entre as las. (Ex: e la 1, la 1, la 1, la 2, la 3, la 3, la 1, la 1, la 1, la 2, la 3, la 3 etc.).
37.2
Servios Integrados - IntServ c
A arquitetura de servios integrados tem duas caracter c sticas fundamentais que so a reserva de recursos e o estabelecimento de chamada. O Intserv fornecer a e qualidade de sevio a uxos individuais garantindo que, antes do estabelecic mento de uma sesso, todos os roteadores entre a origem e o destino possuem a recursos sucientes para garantir o atendimento das exigncias de Qos. As etae pas envolvidas no processo de aceitao da chamada so as seguintes: ca a Caracterizao do Trfego e Especicao de Qos desejada: Para que um ca a ca roteador dena se pode ou no atender as exigncias de uma sesso ele a e a precisa conhecer a exigncias de QoS (Rspec) e as caracter e sticas de trfego a (Tspec). Tspec e Rspec so chamados especicaes de uxo owspecs; a co Sinalizao para o estabelecimento da chamada: A Tspec e o Rspec deca vem ser transportados para todos os roteadores nos quais sero reservados a recusos; Aceitao da chamada: Assim que recebe Tspec e Rspec o roteador pode ca determinar se pode ou no aceitar a chamada. a Na Internet, o protocolo RSVP (Resource Reservation Protocol ) o protoe colo de sinalizao preferido Ele foi especialmente desenvolvido para servios ca c integrados de Internet e permite que as prprias aplicaes requeiram da rede o co reservas de recursos necessrios para seus diversos servios. O RSVP exa c e ecutado nos hosts, para denir as especicaes de uxo, e nos roteadores, co para propagao das especicaes pela rota e para manuteno do estado da ca co ca conexo. a Outra caracter stica importante na arquitetura IntServ so as classes de a servio oferecidos. As classes so os modelos de qualidade de servio oferecic a c dos. As duas grandes classes de servio do intServ so: (i)Servio de Qualidade c a c Garantida e (ii) Servio de Rede de Carga Controlada. c A primeira grande desvantagem da arquitetura IntServ esto relacionadas a com a escalabilidade, uma vez que os roteadores precisam manter o estado de cada um dos uxos transmitidos, o que pode ocasionar sobrecarga em roteadores de backbone. A segunda desvantagem do IntServ que ela atende apenas um e nmero pequeno de classes de servio. u c 346
37.3
Servios Diferenciados - DiServ c
A arquitetura de servios diferenciados (Diserv) tem por objetivo prover diferc enciao de servios mais escalvel e ex ca c a vel. Para isso o DiServ prope que o as operaes de controle mais complexas devem ser feitas pela borda da rede, co aliviando a sobrecarga no ncleo da rede. Dessa forma, a arquitetura Intserv u consiste de dois elementos funcionais que so: a Funes de Borda: Entende-se por borda como o primeiro dispositivo co habilitado a DiServ (host ou roteador) no caminho entre a origem e o destino. A funo dos dispositivos de borda so a classio dos pacotes ca a ca e o condicionamento do trfego. A classicao do trfego consiste na a ca a marcao do campo DS (Dierentiated Service), que na verdade o campo ca e ToS (Type of Service) do pacote IP. O condicionamento do trfego est a a relacionado com a limitao de parmetros pr-acordados como taxa mdia ca a e e de envio, taxa de pico etc. Funo Central: Quando um pacote marcado com DS chega a um roteador ca habilitado a DiServ ele repassado de acordo com o seu comportamento e de salto (per-hop behavior - PHB) associado a sua classe. O PHB inuencia na maneira como os buers e a largura de banda so compartilhados entre a as classes de trfego no roteador. Os dois tipos de PHB denidos at agora a e so o PHB de repasse acelerado (expedited forwarding - EF), que garante a a taxa de partida de uma determinada classe ser maior ou igual do que a uma taxa congurada, e o PHB de envio assegurado (assured forwarding AF), que permite criao de regras de descarte preferencial entre as classes. ca Um aspecto de fundamental importncia na arquitetura DiServ que o a e comportamento de salto dos pacotes depende unica e exclusivamente de sua classe de trfego. a
347
Cap tulo 38
Redes X.25 e Frame Relay

38.1 X.25
O conjunto de protocolos X.25 foi projetado no nal da dcada de 70. Nessa e poca, os PCs e as estaes de trabalho no estavam amplamente disseminados e co a e no dispunham de muito suporte para rede. Basicamente, eram usados os a chamados terminais burrospara acessarem os mainframes atravs das redes e de computadores. Dessa forma, para dar o suporte necessrio aos terminais a burrosos projetistas da X.25 decidiram injetar inteligncia na rede. Como e sabemos hoje, essa losoa oposta ` losoa da Internet, que coloca muito da e a complexidade nos sistemas nais e espera o m nimo dos servios de camada de c rede. Outra parte importante do contexto tecnolgico do nal dos anos 70 e do o comeo dos anos 80 se refere aos enlaces f c sicos. Naquela poca, quase todos e os enlaces terrestres eram de cobre, apresentavam ru dos e estavam propensos a erros. Os enlaces de bra ptica ainda no tinham sa dos laboratrios de o a do o pesquisa. As taxas de erros de bits sobre enlaces de longa distncia eram muitas a ordens de grandeza maiores do que so agora sobre o enlaces pticos. Devido `s a o a altas taxas de erros, tinha sentido projetar o protocolo X.25 com recuperao de ca erros em cada enlace. Em particular, sempre que um protocolo X.25 envia um pacote, ele conserva uma cpia do pacote at que o comutador seguinte (na rota o e do pacote) devolva um reconhecimento, indicando que o pacote foi recebido livre de erros. A recuperao de erros por enlace reduz signicativamente a taxa de ca transmisso, o que era consistente com o contexto tecnolgico da poca altas a o e taxas de erros de enlace e terminais no inteligentes. Alm disso, o projeto da a e X.25 tambm pede controle de uxo por enlace. e
38.2
Frame Relay
Projetada no nal da dcada de 80 e amplamente disseminada na dcada de 90, a e e Frame Relay , em vrios aspectos, uma X.25 de segunda gerao. Como a X.25, e a ca ela usa circuitos virtuais, opera na camada 2 do modelo OSI e usa multiplexao ca estat stica e compartilhamento de porta. Contudo, como se baseia em enlaces de bras pticas, ela naturalmente foi projetada para taxas de erros muito mais o baixas. A essncia da Frame Relay um servio de comutao de pacotes de e e c ca 348
circuitos virtuais sem recuperao de erros e sem controle de uxo. Quando ca um comutador Frame Relay detecta um erro em um pacote, seu unico curso de ao poss descartar os dados. Isso resulta em uma rede com carga de ca vel e processamento mais baixas e taxas de transmisso mais altas que a X.25, mas a exige sistemas nais inteligentes para garantir a integridade dos dados. Embora o protocolo Frame Relay tenha sido desenvolvido para ser o mais simples poss vel, e a sua premissa bsica determinar que os eventuais problemas a de erros da rede deveriam ser resolvidos pelos protocolos dos equipamentos de usurio, surgiram ao longo do tempo necessidades que levaram os rgo de a o a padronizao a denir mecanismos de sinalizao para trs tipos de situaes: ca ca e co Aviso de congestionamento Aviso Expl cito de Congestionamento Aviso Impl cito de Congestionamento Elegibilidade para Descarte Estado das conexes o Sinalizao SVC ca Entretanto, a implementao desses mecanismos opcional e, embora a rede ca e seja mais eciente com a sua adoo, os equipamentos que no os implementam ca a devem atender pelo menos as recomendaes bsicas do Frame Relay. co a Atualmente, na maioria dos casos, as redes Frame Relay so de propriedade a de um provedor de servios de rede pblica (por exemplo AT&T, Sprint e etc) c u e seu uso contratado em base multianual por clientes empresariais. Hoje, a e Frame Relay usada de maneira extensiva para permitir que LANs localizadas e em diferentes ambientes enviem dados ao mesmo tempo a velocidades razoavelmente 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 simplicada, conforme demonstram a gura e a descrio a seguir: ca
Figura 38.1: Estrutura do Frame
Figura 38.2: Estrutura do Cabealho c
349
Flags - indicam o in e o m de cada frame. cio Cabealho - carrega as informaes de controle do protocolo. E composto c co por 2 bytes com as seguintes informaes: co DLCI (Data Link Connection Identier), com 10 bits, representa o nmero (endereo) designado para o destinatrio de um PVC dentro u c a de um canal de usurio, e tem signicado local apenas para a porta a de origem (vide gura 38.2); C/R (Command / Response), com 1 bit, usado pela aplicao e ca usuria; a FECN (Foward Explicit Congestion Notication), com 1 bit, usado e pela rede para informar um equipamento receptor de informaes que co procedimentos de preveno de congestionamento devem ser iniciaca dos; BECN (Backward Explicit Congestion Notication), com 1 bit, e usado pela rede para informar um equipamento transmissor de informaes que procedimentos de preveno de congestionamento deco ca 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, usado para indicar que o cabealho e c tem mais de 2 bytes, em caso especiais; Informao de usurio - contm as informaes da aplicao usuria a ca a e co ca a serem transportadas atravs da rede Frame Relay. e FCS - o FCS (Frame Check Sequence) representa o CRC padro de 16 bits a usado pelo protocolo Frame Relay para detectar erros existentes entre o Flag de in cio do frame e o prprio FCS, e pode ser usado apenas para o frames com at 4096 bytes. e
38.2.2
Envio de um datagrama IP de Ethernet para Frame Relay e Ethernet
Considere a transmisso de um datagrama IP entre dois sistemas nais que esto a a 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 ` camada de rede. A camada de rede a passa o datagrama IP ` placa de interface Frame Relay. Essa placa encapsula a o datagrama IP em um quadro Frame Relay. Ela tambm calcula o CRC (2 e bytes) e insere o valor resultante no campo CRC. O campo de camada de enlace (2 bytes) contm um campo de nmero de circuito virtual de 10 bits. A placa e u de interface obtm o nmero do CV de uma tabela que associa nmeros de rede e u u IP a nmeros de CV. Ela ento transmite o pacote. u a A placa de interface transmite o pacote Frame Relay a um comutador Frame Relay prximo, de propriedade de um provedor de servios Frame Realy. O o c comutador examina o campo de CRC. Se o quadro tiver um erro, o comutador o descartar. Se no houver erro no quadro, o comutador usar o nmero de a a a u 350
CV do quadro para rote-lo at o prximo comutador (ou at o roteador de a e o e destino). O roteador de destino remove os campos frame relay e, ento, passa o a 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 o problema. a
38.3
Interligao de Redes LAN ca
A interligao das redes LAN de vrios escritrios compondo uma rede WAN, ca a o uma aplicao t e ca pica para o uso da tecnologia Frame Relay. O trfego usual a das redes de dados normalmente de 2 tipos: interativo (comando - resposta), e ou seja, solicitao de usurios e aplicaes clientes e respostas de aplicaes ca a co co servidoras, e por rajadas (bursty), quando grandes quantidades de dados so a transferidas de forma no cont a nua. O Frame Relay, atravs de roteadores ou equipamentos de acesso (FRAD) e instalados nos escritrios, permite utilizar uma porta unica em cada escritrio o o para compor redes do tipo malha (meshed) onde a comunicao de um escritrio ca o com todos os outros poss sem a complexidade do uso de mltiplas portas e vel u e mltiplos circuitos dedicados. u
Figura 38.3: Interligao de lans com Frame Relay ca Alm disso, o uso dos circuitos virtuais do Frame Relay para compor a rede e permite tempos de provisionamento muito menores e recongurao de rede ou ca aumento de banda com maior facilidade.
38.3.1
Voz sobre Frame Relay (VoFR)
A tecnologia Frame Relay tambm possui facilidades para o transporte de Voz, e fax e sinais de modens analgicos atendendo os requisitos de atraso (delay) o espec cos para esse tipo de aplicao. ca 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 atravs da mesma porta Frame Relay e usando procedimentos comuns e de gerenciamento e manuteno atende os requisitos de reduo de custos e de ca ca complexidade das grandes redes corporativas. Deve-se entretanto levar em considerao a qualidade do servio prestado ca c pela rede multisservios de terceiros para que o resultado nas aplicaes de c co Voz, fax e modem possam ainda atender os requisitos aplicveis aos servios a c convencionais.
351
Figura 38.4: Voz sobre Frame Relay
38.3.2
Interao entre Frame Relay e ATM ca
Para buscar aumentar a interoperabilidade do Frame Relay com outros protocolos de dados, o FR Frum e o ATM Frum, os rgos responsveis pelo o o o a a desenvolvimento de Acordos de Implementao (IAs), desenvolveram padres ca o para interligar equipamentos dessas tecnologias atravs de PVCs. e Foram padronizadas duas formas de interoperabilidade. A primeira, chamada de Frame Relay/ATM Network Interworking for PVCs, padroniza uma funcionalidade responsvel pelo encapsulamento dos PVCs para que os mesmos a possam ser transportados indistintamente nas redes da 2 tecnologias. Seu uso t pico ocorre quando a rede Frame Relay tem com ncleo uma rede ATM, para u otimizar ainda mais o uso de banda e a segurana. A gura a seguir apresenta c esta soluo. ca A segunda forma de interoperabilidade, chamada de Frame Relay/ATM Service Interworking for PVCs, padroniza uma funcionalidade responsvel pela a converso dos protocolos (FR ATM), que pode ser incorporada tantos aos a equipamentos de acesso como aos equipamentos da rede. Seu uso t pico ocorre quando o usurio possui redes Frame Relay em alguns escritrios que devem se a o interligar com a rede ATM da matriz. A gura a seguir apresenta esta soluo. ca
38.3.3
CIR (Taxa de Informao Comprometida) ca
A Frame Relay faz uso de um mecanismo inovador chamado de taxa de informao comprometida (committed information rate - CIR), de forma que cada ca 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 transmisso detera minada pela CIR. Pode-se dizer que, em muitos aspectos, o servio CIR um c e predecessor do servio diferenciado da Internet. c Nas redes Frame Relay, os pacotes podem pertencer a um de dois n veis de prioridade: alta ou baixa. Atribui-se prioridade aos pacotes marcado um bit especial no cabealho do pacote o denominado bit de descarte preferencial c (discard eligibility- DE) -, com 0 para alta prioridade e 1 para baixa prioridade. Se um quadro for de alta prioridade, a rede dever entregar o pacote no destino a sob todas e quaisquer condies de rede, incluindo per co odos 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 condies extremas, a rede pode at descartar pacotes de alta co e prioridade.
352
A CIR, nesse contexto, est envolvida no processo de marcao dos pacotes a ca com valores 1 ou 0. Entretanto alguns conceitos devem ser discutidos para se entender exatamente como a CIR funciona. A taxa de acesso a taxa de acesso e ao enlace, isto , a taxa do enlace do roteador fonte at o comutador de borda e e Frame Relay. Essa taxa freqentemente 64Kbps, mas mltiplos inteiros de e u u 64 Kbps at 1544 Mbps tambm so comuns. Chamemos essa taxa de R. O e e a comutador de borda responsvel pela marcao dos pacotes que chegam do e a ca roteador fonte. Para fazer a marcao, o roteador de borda examina os horrios ca a de chegada dos pacotes vindos do roteador fonte em intervalos xos de tempo, chamados de intervalos de medio e designados por Tc. ca Dessa forma, a cada CV que provm do roteador fonte atribu uma CIR, e e da que expressa em unidades de bits/seg. A CIR nunca maior que R, a taxa de e e acesso. Os clientes pagam por uma CIR espec ca; quanto maior a CIR, maior o valor pago ao provedor. Se o CV gerar pacotes a uma taxa menor do que a e CIR, ento todos os pacotes so marcados como de alta prioridade. Contudo, a a se a taxa na qual a CV gerar pacotes exceder a CIR, ento a frao de pacotes a ca do CV que excederem a taxa ser marcada como pacotes de baixa prioridade. a Mais especicamente, a cada intervalo d medio Tc, para os primeiros CIR.Tc ca 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 servio Frame Relay use um interc valo de medio Tc=500 ms. Suponha que a taxa de enlace de acesso seja R=64 ca Kbps e que a CIR atribu `quele CV em particular seja 32 Kbps. Suponha da a tambm, para facilitar, que cada pacote Frame Relay consista em exatamente e L=4000 bits. Isso signica 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 so marcados como pacotes de baixa prioridade. a 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 chamado de e excesso de reserva. Como o excesso de reserva permitido, um enlace de acesso e pode transmitir pacotes de alta prioridade a uma taxa de bits correspondente que esceda a CIR (mesmo que cada CV individual envie pacotes prioritrios a a uma taxa que no exceda a CIR). a
353
Cap tulo 39
Redes Virtuais Locais

39.1
39.1.1
VLANs
Denio ca
Uma Virtual Lan, ou simplesmente vlan, um mtodo para se criar redes lgicas e e o independentes dentro de uma rede f sica. As vlans facilitam a administrao da ca rede separando logicamente segmentos lgicos de uma lan, por exemplo, deparo tamentos distintos. As vlans reduzem o dom nio de broadcast, diminuindo o trfego na rede. Ou seja, os pacotes ARP broadcast enviados por um host A a que deseja descobrir o endereo MAC de um host B, ambos de uma mesma vlan c V, no sero escutados por um host C que no pertena a vlan V. Uma vlan a a a c uma subrede na qual os computadores no necessariamente precisam estar e a conectados no mesmo segmento f sico. O que torna as vlans extremamente exiveis o fato de os administradores da rede podem congurar as vlans atravs e e de software.
39.1.2
Protocolo 802.1q
As vlans operam na camada de enlace do modelo de referncia OSI, no entanto, e os administradores de rede geralmente conguram uma vlan para mapear diretamente uma rede ou subrede IP, o que d a impresso de que esta uma a a e tecnolgia que envolve a camada de rede. Atualmente, o protocolo IEEE 802.1q o mais popular para implementao de vlans. e ca Para desenvolver a tecnologia de vlans, a tarefa mais d cil enfrentada pelo comit 802 do IEEE foi denir como armazenar o identicador da vlan dentro e de um quadro Ethernet. Depois de muita discurso o comit fez o impensvel a e a e mudou o cabealho do quadro Ethernet, adicionando uma tag VLAN. Uma c mudana do cabealho Ethernet s foi poss pois o comit 802 mostrou que c c o vel e o campo VLAN s realmente utilizado pelos switches e pontes e no pelas o e a mquinas dos usurios. Assim, a sa para o problema foi a seguinte: se a a a da origem no gerar a tag VLAN, o primeiro switch ou bridge que for capaz de a identicar a VLAN para o quadro acrescentar o quadro, enquanto o ultimo a dispositivo do percurso remover a tag para entregar o quadro ` maquina de a a 354
destino. Embora muitas das novas placas Ethernet j sejam compat a veis com o padro 802.1q, geralmente o quadro marcado com a tag vlan por um switch. a e Dessa forma, apenas os switches precisam ser congurados. Na verdade, o padro 802.1q adicionou ao cabealho Ethernet um campo a c chamado Tag Protocol ID (TPID) e um campo Tag Control Information (TCI), que por sua vez subdividido em trs partes que so CFI, Pri, e VID. Um e e a quadro 802.1q reconhecido quando o campo TPID possui o valor 0x8100. O e campo CFI utilizado para compatibilizao com redes Token Ring, enquanto e ca o campo VID o identicador de vlan de fato. O campo Pri possui 3 bits e e utilizado para implementar mecanismos de prioridade no n de enlace. O e vel modo como deve ser utilizado o campo Pri denido no padro IEEE 802.1p. e a O novo cabealho do Ethernet pode ser visto na gura 39.1.2. c
Figura 39.1: Frame 802.1q
355
Cap tulo 40
Redes de Circuito Virtuais

40.1 Redes ATM
Uma rede ATM (Asyncronous Transfer Mode) tem como principal caracter stica o fato de ser orientada a conexo, Portanto, antes do in da transmisso de a cio a dados necessrio que todos os roteadores entre a origem e o destino registrem a e a existncia da conexo e reservem recursos para ela. Essas conexes so chamadas e a o a de circuitos virtuais, que podem ser dinmicos (Switched Virtual Circuit - SVC) a ou permanentes (Permanent Virtual Circuit - PVC). O protocolo de sinalizao ca utilizado para estabelecimento das conexes o Q.2931. o e A idia bsica do ATM transmitir as informaes em pequenos pacotes e a e co chamdos clulas. As clulas ATM possuem o tamanho xo de 53 bytes, sendo 5 e e para o cabealho e 48 para a carga util. O fato das clulas terem tamanho xo c e permite que todo o roteamento das clulas seja feito via hardware. A estrutura e de uma clula ATM pode ser vista na gura (est faltando) ??. e a VPI (Virtual Path Identier ): representa o nmero da rota virtual at o u e destinatrio da informao util; a ca VCI (Virtual Channel Identier ):representa o nmero do canal virtual u dentro de uma rota virtual espec ca; PT (Payload Type): identica o tipo de informao que a clula contm: ca e e de usurio, de sinalizao ou de manuteno; a ca ca
CLP (Cell Loss Priority): indica prioridade da clula caso sejam necessrios e a descartes por motivos de congestionmento; HEC (Header Error Correction): Permite correo de erros de um bit e ca deteco de erros de mais de um bit. ca Os campos VPI e VCI so utilizados no processo de comutao das clulas. a ca e E importante destacar que os valores de VPI e VCI so alterados a medida que a a clula trafega pela rede. Por ser baseada em circuitos virtuais, a rede ATM e garante a ordenao na entrega das clulas. No entanto, no capaz de garantir ca e a e a entrega. Quando um detecta um erro de mais de um bit a partir do campo
356
HEC, a clula descartada. e e As redes ATM tm seu prprio modelo de referncia, diferente do modelo e o e OSI e do modelo TCP/IP. O ATM um modelo tridimensional, sendo composto e no s por camadas, mas tambm por planos, como mostrado na gura 40.1. a o e
Figura 40.1: Modelo de Referncia ATM e O plano de usurio responsvel pelo transporte de dados, pelo uxo de a e a controle e pela correo de erros, enquanto o plano de controle trata do gerenciaca mento de conexes. No modelo ATM todas as camadas possuem funcionalidades o de usurio e de controle. A descrio de cada uma das camadas e mostrada a a ca seguir: Camada F sica: prov os meios para transmitir as clulas ATM. A sube e camada TC (Transmission Convergence) mapeia as clulas ATM no fore mato dos frames da rede de transmisso (SDH, SONET, PDH, etc.). A a sub-camada PM (Physical Medium) temporiza os bits do frame de acordo com o relgio de transmisso; o a Camada ATM: responsvel pela construo, processamento e transe a ca misso das clulas, e pelo processamento das conexes virtuais. Esta caa e o mada tambm processa os diferentes tipos e classes de servios e controla e c o trfego da rede; a
Camada de Adaptao ATM ou AAL (ATM Adaptation Layer ): reca e sponsvel pelo fornecimento de servios para a camada de aplicao sua c ca perior. A sub-camada CS (Convergence Sublayer ) converte e prepara a informao de usurio para o ATM, de acordo com o tipo de servio, alm ca a c e de controlar as conexes virtuais. A sub-camada SAR (Segmentation and o Reassembly) fragmenta a informao para ser encapsulada na clula ATM. ca e A camada AAL implementa ainda os mecanismos de qualidade de servio c e sinalizao. ca Os tipos de servio oferecidos pelas redes ATM so os seguintes: c a CBR (Constant Bit Rate): Garantida uma taxa de transmisso constante. a Aplicaes t co picas que necessitam desse tipo de servio so telefonia e c a distribuio de udio e v ca a deo (televiso, pay-per-view etc.); a 357
VBR (Variable Bit Rate): Garantida uma taxa mdia de transmisso e e a um valor mximo de pico. Aplicaes t a co picas deste servio so voz com c a taxa varivel de bits e v a deo comprimido (MPEG, por exemplo); ABR (Available Bit Rate): Garantida uma taxa m nima de transmisso. a Aplicado a conexes que transportam trfego em rajadas que podem preo a scindir da garantia de banda, variando a taxa de bits de acordo com a disponibilidade da rede ATM. Aplicaes t co picas deste servio tambm c e so as interligaes entre redes e a emulao de LANs; a co ca UBR (Unspecied Bit Rate): A capacidade de transmisso restante aloa e cada ao trfego. Utilizada para trfego que no possui requisitos de atraso a a a ou jitter, como transferncia de arquivos e email. e
40.2
MPLS - Multiprotocol Label Switching
A medida em que a Internet foi crescendo e os servios nela oferecidos foram se c tornando mais sosticados foi se tornando necessrio desenvolver novas tcnicas a e para garantir n veis de qualidade de servio altos. Enquanto o IETF se concenc trou na concepo das arquiteturas de servios integrados e servios diferenciaca c c dos, vrios fabricates se concentravam desenvolvimento de mtodos de encama e inhamento melhores. Esse trabalho se concentrou na incluso de um rtulo no a o in de cada pacote, de forma que o roteamento pudesse ser feito com base nos cio rtulos e no mais a partir do endereo de destino. Dessa forma, os engenheiros o a c pretendiam tornar o processo de encaminhamento muito mais eciente. Uma das motivaes da poca era o fato de que pacotes IP no podiam ser encamco e a inhados completamente via hardware (hoje j poss ae vel), e com o MPLS, isso poderia ser feito. O MPLS um protocolo que permite emular algumas propriedades de redes e de comutao de circuitos utilizando para isso a tecnica de circuitos virtuais. ca O MPLS opera entre as camadas de enlace e de rede de forma independente, e por isso muitas vezes dito ser um protocolo de camada 2.5. Poe esse moe tivo poss contruir switches MPLS capazes de encaminhar tanto pacotes IP, e vel clulas ATM ou outros. Da o nome Multiprotocol Label Switching. e O MPLS funciona adicionado aos pacotes um cabealho adicional contendo c um ou mais rtulos (labels), formando uma pilha de rtulos. Cada um dos o o rtulos composto por quatro campos que so: o e a Label: 20 bits utilizados para indicar o valor do rtulo propriamente dito. o E com base no valor desse campo que os pacotes so encaminhados; a CoS: 3 bits utilizados para indicar a classe de servio; c S: 1 bit que quando setado para 1 indica que o rtulo o ultimo da pilha; o e TTL: 8 bits para indicar o mximo nmero de hops que um pacote pode a u dar antes de ser descartado.
358
Figura 40.2: Formato do rtulo MPLS o
Figura 40.3: Empilhamento de rtulos MPLS entre as camadas 2 e 3 o O processo de encaminhamento ocorre da seguinte maneira. Quando um pacote rotulado com MPLS chega a um rotedor, o rtulo o campo label analo e isado a m de determinar por qual linha de sa o pacote deve sair. O roteador da tambm responsvel por determinar com qual rtulo o pacote dever sair. A e e a o a essa operao de troca de rtulos d-se o nome de swap. ca o a Quando um pacote ainda no rotulado chega a um rotedor e precisa passar a por um tnel MPLS, o rotedor deve primeiro determinar a classe de equivalncia u e do pacote (forwarding Equivalence Class - FEC) para ento adicionar um ou a mais rtulos ao pacote. O FEC um mecanismo de agregao que permite usar o e ca um unico rtulo para pacotes de conexes diferentes mas tm o mesmo destino o o e ou pertencem a mesma classe de servio. Isso pemite diminuir o nmero da c u tabela de encaminhamento e aumentar a velocidade de encaminhamento. Alm da operao de troca de rtulos (swap), o MPLS possui ainda mais e ca o duas operaes que so a adio de um novo rtulo (push) e a remoo de co a ca o ca um rtulo (pop). A adio de um novo rtulo serve para encapsular o pacote o ca o em outra camada de MPLS, permitindo por exemplo, a criao de VPNs. A ca operao de remoo do rtulo dita desencapsulamento. Quando o ultimo ca ca o e rtulo removido diz-que que o pacote deixou o tnel MPLS. o e u Assim como em outras tecnologias de circuito virtual, o MPLS utiliza protocolos auxiliares para criar e desfazer suas conexes. Atualmente so utilizados o a o CR-LDP (Contraint-based Routing - Label Distribution Protocol ) e o RSVPTE (Resource Reservation Protocol - Trac Engineering). Ambos realizam a distribuio de rtulos com base em restries de qualidade de servio, rotas ca o co c obrigatrias etc. o
Outra considerao importante sobre a tecnologia MPLS que, diferenteca e mente de outras tecnologias de circuito virtual como ATM, uma conexo MPLS a unidirecional. Uma conexo MPLS tambm chamada LSP (Label Switched e a e e Path). Para estabelecimento de uma comunicao bidirecional necessrio esca e a tabelecer dois LSPs. Isso feito de forma independente entre origem e destino, e de forma que os dados em um sentido podem seguir por uma rota diferente dos dados no sentido oposto.
359
Cap tulo 41
Arquitetura TCP/IP
41.1 Viso geral a
A arquitetura TCP/IP surgiu com a criao de uma rede chamada ARPANET, ca que foi uma rede criada para manter comunicao entre os rgos do governo ca o a 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 quatro camadas: F sica (host/Rede), Rede (Inter-Rede ou Internet), Transporte e Aplicao; onde cada uma executa um conjunto bem denido de funes de coca co municao. Nesta arquitetura no existe uma estruturao formal para cada caca a ca mada conforme ocorre no modelo OSI. Ela procura denir um protocolo prprio o para cada camada, assim como a interface de comunicao entre duas camadas ca adjacentes. A gura ?? 1 mostra a arquitetura TCP/IP.
41.2
Comparao entre a arquitetura OSI e TCP/IP ca
Os modelos de referncia OSI e TCP/IP tm muito em comum. Os dois se bae e seiam no conceito de pilha de protocolos independentes. Alm disso, as camadas e tm praticamente as mesmas funes. Apesar dessas semelhanas, os modelos e co c tm muitas diferenas. e c O modelo OSI torna expl cita a diferena do conceito de servio, de interface c c e de protocolo. Enquanto que o modelo TCP/IP no diferencia com clareza a esses conceitos. Por esse motivo, o modelo OSI os protocolos so bem mais ena capsulados que os do TCP/IP e podem ser substitu dos com relativa facilidade. O modelo TCP/IP no nem um pouco abrangente e no consegue descrever a e a outras pilhas de protocolo que no a pilha TCP/IP. a Uma diferena expl c cita est no nmero de camadas. O modelo OSI possui a u sete e o TCP/IP possui quatro. Outra diferena est na rea de comunicao c a a ca sem conexo e orientada a conexes. Na camada de rede, o modelo OSI a o e compat com a comunicao sem conexo e orientada a conexes. No entanto, vel ca a o na camada de transporte, o modelo aceita apenas comunicao orientada a ca conexes. O modelo TCP/IP s tem um modo de operao na camada de rede o o ca (sem conexo), mas aceita ambos os modos na camada de transporte. a
360
No modelo TCP/IP, a camada f sica no realmente uma camada no sentido a e em que o termo usado no contexto dos protocolos hierarquizados. Trata-se, e na verdade, de uma interface entre a camada de redes e de enlace de dados. E ainda, o modelo no faz distino entre as camadas f a ca sicas e de enlace de dados.
41.3
Camada F sica (host/rede)
A arquitetura TCP/IP no deni muito bem o que acontece nesta camada, apea nas especica que o host tem que se conectar ` rede utilizando algum protocolo a para que seja poss enviar pacotes IP. Esse protocolo no denido e varia vel a e de host para host e de rede para rede. Esta camada tambm chamada de camada de abstrao de hardware, pois e e ca sua funo principal ser uma interface do modelo TCP/IP com os diversos tipos ca de rede (X25, ATM, FDDI, Ethernet, Token Ring, Frame-Relay, etc.). Como h uma grande variedade de tecnologias de rede, que utilizam diferentes velocia dades, protocolos, meios de transmisso, etc., esta camada no normatizada a a e pelo modelo TCP/IP, o que prov uma das grandes vantagens do modelo: a e possibilidade de interconexo e interoperao de redes heterogneas. a ca e Os protocolos desta camada so: a PPP (Point-to-Point Protocol): um protocolo ponto a ponto utilizado e para transportar datagramas atravs de uma conexo serial entre dois dise a positivos de rede, por exemplo, entre modems (do usurio e do provedor a de Internet). Ele aceita a deteco de erros, negociao de opes, comca ca co pactao de cabealhos e, opcionalmente, a transmisso convel com o ca c a a uso de um formato de quadro do tipo HDLC. ARP (Address Resolution Protocol): um protocolo utilizado para dee scobrir o endereo f c sico (MAC) de uma mquina a partir de seu endereo a c IP; RARP (Reverse ARP): um protocolo utilizado descobrir o endereo IP e c de uma mquina a partir de um endereo f a c sico. Pode-se dizer que os protocolos ARP e RARP pertencem tambm ` camada e a Inter-Rede.
41.4
Camada de Inter-Rede
A camada de Inter-Rede a primeira normatizada pelo modelo TCP/IP. Cone hecida tambm como camada Internet (Rede), esta camada dene o protocolo e IP (Internet Protocol) responsvel pelo endereamento dos hosts e roteadores. a c A tarefa desta camada entregar pacotes IP onde eles so necessrios. O roteae a a mento de pacotes uma questo de grande importncia nesta camada, assim e a a como a necessidade de evitar o congestionamento. Alm do protocolo IP, a camada de Inter-Rede dene alguns outros protoe colos: ICMP (Internet Control Message Protocol): um protocolo utilizado para e transmisso de mensagens de controle ou ocorrncia de problemas; a e 361
OSPF (Interior Gateway Routing Protocol): um protocolo de roteae mento em um Sistema Autnomo; o IP (Routing Information Protocol): um protocolo que permite a troca de e informaes de roteamento entre gateways utilizando o algoritmo Vectorco Distance; BGP (Boder Gateway Protocol): um protocolo de roteamento entre e Sistemas Autnomos. o
41.5
Camada de Transporte
A camada de transporte o ncleo de toda a hierarquia de protocolos. E uma e u camada m a m, isto , uma entidade desta camada da mquina de origem s e a o se comunica com uma entidade par da mquina de destino. Sua funo prover a ca e uma transferncia de dados convel e econmica entre a mquina de origem e e a o a a mquina de destino, independente das redes f a sicas em uso no momento. Dois protocolos m a m so denidos nesta camada. O primeiro deles, a o TCP (Transmission Control Protocol) um protocolo orientado a conexo e a convel que permite a entrega sem erros de um uxo de bytes, vericando se a a ordem e a seqncia dos dados recebidos e enviados esto corretas. O segundo ue a protocolo, O UDP (User Datagram Protocol) um protocolo sem conexo e e a no-convel, ou seja, no oferece nenhuma garantia em relao ` entrega dos a a a ca a dados ao destino. Para distinguir entre vrias aplicaes, a camada de Transporte associa um a co identicador a cada processo de aplicao. Esse identicador chamado de ca e porta. Para uma aplicao falarcom outra numa mquina remota, preciso ca a e conhecer no apenas o endereo IP da mquina destino, mas tambm a porta a c a e associada a cada aplicao. O UDP e o TCP fornecem um conjunto de portas ca que permite a mltiplos processos dentro de uma unica mquina usarem os u a servios providos pelo UDP e TCP simultaneamente. O protocolo TCP utiliza c o conceito de sockets para caracterizar uma conexo entre a origem e o destino. a O socket consiste no endereo IP da mquina e a porta. c a
41.6
Camada de Aplicao ca
E formada pelos protocolos utilizados pelas diversas aplicaes do modelo TCP/IP. co Esta camada no possui um padro comum, cada aplicao dene o seu prprio a a ca o protocolo. E esta camada que trata a compatibilidade entre os diversos formatos representados pelos variados tipos de estaes da rede. co Os principais protocolos desta camada so: a TELNET (TeleType Network): um protocolo utilizado para acessar sise temas remotos por meio de um terminal. Utiliza a porta 23 do protocolo TCP; FTP (File Transfer Protocol): um protocolo utilizado para servios de e c transferncia, renomeaao e eliminao de arquivos, alm da criao, mode c ca e ca icao e excluso de diretrios. Utiliza duas conexes TCP: uma para ca a o o
362
controle, porta 21, e outra para dado, porta 20. As transferncias de e arquivos podem ser no modo texto ou binrio; a SNMP (Simple Network Management Protocol): um protocolo utilizado e trafegar informaes sobre dispositivos da rede, ou seja, gerenciamento da co rede. Utiliza duas conexes UDP: uma para requisies, porta 161, e uma o co para as mensagens de trap, porta 162; DNS (Domain Name Server): um protocolo utilizado para realizar o mae peamento entre nomes e endereo IP. Utiliza a porta 43 do protocolo UDP c para resoluo de nomes e a porta 53 do protocolo TCP para transferncia ca e de zonas; DHCP (Dynamic Host Conguration Protocol): um protocolo que pere mite realizar a congurao automtica de endereos de hosts em uma ca a c rede ou na Internet; SMTP (Simple Mail Transfer Protocol): um protocolo utilizado para e enviar mensagens de correio eletrnico. Usualmente, utiliza a porta 25 do o protocolo TCP; HTTP (HyperText Transfer Protocol): um protocolo de transferncia e e de mensagens utilizado na WWW. Usualmente, utiliza a porta 80 ou 8080 do protocolo TCP; NFS (Network File System): um protocolo que permite montardiscos e ou parte deles de dispositivos remotamente e oper-los como se fossem a locais. Inicialmente este protocolo utiliza a porta 2049 do protocolo UDP, mas a verso NFS4 utiliza a porta 2049 do protocolo TCP; a
363
Cap tulo 42
Camada de Aplicao ca
42.1 Proxy Cache
Um proxy cache, ou simplesmente proxy, uma entidade de rede que atende e requisies HTTP em nome de um servidor Web de origem. Um proxy tem seu co prprio disco de armazenagem onde mantm cpias dos objetos recentemente o e o requisitados. Alguns dos objetivos da utilizao de um proxy a reduo na ca e ca utilizao dos links de a acesso a internet e a diminuio do atraso percebido ca ca pelo usurio no atendimento de uma requisio. Os dois principais tipos de a ca proxy so: a Interceptao: Trabalha interceptando o trfego da rede de forma transca a parentemente, no sendo necessria nenhuma congurao adicional nos a a ca browsers. So utilizados especialmente pelos ISPs. a Intermedirio: Geralmente utilizados em ambientes que constituem um a dom nio administrativo (empresas, universidades etc.), uma vez que e necessria a conguraao dos browsers. Esse tipo de proxy pode ainda a c implementar outras funes como autenticao e ltros de contedo. co ca u Para que um proxy possa atender as requisies dos usurios de forma corco a reta necessrio que ele determine se um documento que est em cache vlido e a a e a ou no. Para isso, os servidores proxy utilizam alguns campos do cabealho das a c respostas HTTP. O campo Max-Age, por exemplo, informa por quanto tempo em segundos a resposta ser valida. Quando o documento em cache no possui a a a informao max-age, o proxy pode utilizar o mtodo GET em conjunto com o ca e campo If-Modied-Since (GET condicional) para solicitar ao servidor uma nova cpia do mesmo caso ele tenha sido modicado desde a data denida. o Os proxies podem ainda serem organizados de forma hierrquica, de modo a que um proxy possa consultar outros sobre seu contedo e, baseado nos temu pos de respostas, decide qual cache entregar um dado objeto. Para essa coa municao so utilizados protocolos como o ICP (Internet Cache Protocol ) e ca a HTCP (Hyper Text Caching Protocol ). Outro mecanismo de implementar a comunicao entre proxies utilizando o chamado Cache-Digest, que consiste de ca e um sumrio do contedo do cache de um servidor que trocado periodicamente a u e
364
com outros servidores pertencentes ` hierarquia. a
365
Parte VII
Gerncia de Redes e
366
Cap tulo 43
O protocolo SNMP
O SNMP (Simple Network Management Protocol ) um protocolo da camada de e aplicao que facilita a troca de informaes de gerenciamento entre dispositivos ca co de rede. O SNMP o padro de fato para gerenciamento de redes. e a Uma rede gerenciada por SNMP composta basicamente por trs elementos e e que so: (i) os dispositivos gerenciados; (ii) os agentes de monitoramento e (iii) a os sistemas de gerenciamento de rede (Network Management Systems - NMSs). Um dispositivo gerenciado qualquer elemento da rede (hub, switch, roteador, e servidor etc.) que contenha um agente SNMP. Os disposivos gerenciados coletam e armazenam informaes e as tornam dispon co veis para os NMSs atravs e do protocolo SNMP. Essa informaes so armazenadas nas chamadas MIBs co a (Management Information Base). Um agente um software que reside em um dispositivo gerenciado e tem cone hecimento sobre as informaes de gerenciamento e reponsvel pela traduo co e a ca dessas para um formato compat com o SNMP. vel Um NMS executa uma aplicao que monitora e controla os dispositivos ca gerenciados. Existem duas formas bsicas de comunicao entre os agentes e os a ca NMSs. Na primeira, o NMS envia uma mensagem GET para o agente solicitando o envio de alguma informao. Geralmente os NMSs so congurados para ca a coletar informaes dos agentes periodicamente para armazen-las em bases de co a dados para serem anlisados posteriormente. Um NMS pode ainda solicitar a a alterao de alguma informao enviando uma mensagem SET ao agente. As ca ca mensagens enviadas do NMS para o agente utilizam a porta UDP 161. Para recuperar todos os objetos de uma determinada subrvore da MIB pode ser a utilizada a operao GETNEXT. ca Na segunda forma, o agente envia uma mensagem para o NMS quando detecta alguma situao pr denida. As mensagens enviadas do agente para ca e o NMS so cahamadas traps. O protocolo SNMP conta com algumas traps a nativas, porm os agentes podem ser contru e dos para enviar traps em outras 367
situaes no previstas pelo protocolo SNMP. As traps so enviadas utilizando co a a a porta UDP 162. Um conjunto de dispositivos SNMP (disposiotivos gerenciados e NMSs) podem ser agrupados em comunidades. Uma mensagem SNMP originada por um dispositivo SNMP que de fato pertence a comunidade SNMP referenciada cone siderada uma mensagem SNMP autntica. e Atualmente existem duas verses do protocolo SNMP que so SNMPv1 e o a SNMPv2. O SNMPv2 introduziu duas novas operaes que so GETBULK e co a INFORM. A GETBULK permite o NMS recuperar grandes blocos de dados aumentando a ecincia do protocolo, enquanto a operao INFORM permite e ca a comunicao entre dois NMSs na mesma rede. ca
Figura 43.1: Arquitetura SNMP
43.1
Management Information Base
A Management Information Base (MIB) uma coleo de informaes orgae ca co nizada de forma hierrquica como uma rvore de raiz no nomeada. A MIB a a a composta por objetos gerenciados, cada um deles identicado por um OID e (object identiers) unico.
Os IDs de n mais alto pertencem a diferentes organizaes de padronizao vel co ca (ISO, ITU etc.), enquanto os IDs de n imediatamente inferior so alocados vel a para organizaes associadas. Fabricantes podem denir ramos na rvore para co a incluir objetos gerenciados para seus produtos. A estrutura de uma MIB e mostrada na gura 43.2. Os ramos mais comuns na estrutura de uma MIB so os seguintes: a .1.3.6.1.2.0 ou (iso.org.dod.internet.mgmt.mib): Caminho para MIB verso a 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, denida pela RFC 1213 para ser utilizada no gerenciamento de redes baseadas na pilha TCP/IP. A MIB-II subdividida nos 11 grupos de e informao mostrados na gura 43.2; ca .1.3.6.1.4.1 ou (iso.org.dod.internet.private.enterprises): Caminho para MIBs proprietrias. A MIB dos equipamentos da Cisco, por exemplo, cam a abaixo de .1.3.6.1.4.1.9 ou (iso.org.dod.internet.private.enterprises.cisco).
369
Parte VIII
Segurana da Informao c ca
370
Cap tulo 44
Pol ticas de Segurana de c Informao ca

44.1 Pol ticas de Segurana c
A pol tica de segurana tem por objetivo prover ` administrao uma direo c a ca ca e apoio para a segurana da informao. A administrao deve estabelecer c ca ca uma pol tica clara e demonstrar apoio e comprometimento com a segurana da c informao atravs da emisso e manuteno de uma pol ca e a ca tica de segurana da c informao para toda a organizao (ISO/IEC 17799:2000). ca ca Uma pol tica de segurana a expresso formal das regras pelas quais c e a e fornecido acesso aos recursos tecnolgicos da empresa. O principal propsito de o o uma pol tica de segurana informar aos usurios, equipe e gerentes, as suas c e a obrigaes para a proteo da tecnologia e do acesso ` informao. A pol co ca a ca tica deve especicar os mecanismos atravs dos quais estes requisitos podem ser e alcanados. c Outro propsito oferecer um ponto de referncia a partir do qual se possa o e e adquirir, congurar e auditar sistemas computacionais e redes, para que sejam adequados aos requisitos propostos. Portanto, uma tentativa de utilizar um conjunto de ferramentas de segurana na ausncia de pelo menos uma pol c e tica de segurana impl c cita no faz sentido (RFC 2196). a A pol tica deve especicar as metas de segurana da organizao, onde as c ca responsabilidades recaem, e qual o comprometimento da organizao com a ca segurana. c Uma vez que a pol tica um estatuto, necessrio que a sua elaborao, e e a ca aprovao e aplicao sigam os ritos internos da instituio na qual ser aplicada. ca ca ca a O carter estratgico de uma pol a e tica de segurana deve garantir que a mesma c aborde questes que so essenciais para a corporao como um todo. Cada o a ca regra da pol tica serve como referncia bsica para a elaborao do conjunto de e a ca regras particulares e detalhadas que compem as normas e os procedimentos de o segurana. c Com o intuito de tornar a pol tica de segurana um instrumento que viabilize c a aplicao prtica e a manuteno de uma infra-estrutura de segurana para a ca a ca c instituio, necessrio que a pol ca e a tica seja desdobrada em estatutos mais detalhados. Estes estatutos podem ser referidos como pol ticas espec cas, normas,
371
regras complementares, ou controles. Outros n veis podem existir, tal qual numa hierarquia, sendo que o limite ser ditado pelas necessidades e convenincias da a e instituio para a qual so elaborados as regras de segurana. Cabe ressaltar ca a c que, quanto mais baixo o n hierrquico de um documento de segurana em vel a c relao ` pol ca a tica, mais detalhado e de carter operacional ser. a a E importante lembrar que toda regra aplicada a uma instituio deve estar ca em consonncia com os objetivos ns da mesma. A segurana no um m em a c a e si mesma, mas um meio para se chegar a um objetivo maior. A pol tica de segurana como um elemento institucional da organizao posc ca sui um ciclo de vida indenido e deve prever todos os mecanismos de defesa contra qualquer ameaa conforme estabelecido no estudo de custos x benef c cios. Considerando a mutabilidade de tais elementos e dos prprios objetivos e metas o da organizao, uma pol ca tica s apresentar efetividade ao longo do tempo se o a sofrer constantes reavaliaes e atualizaes. co co ISMS - Information Security Management System, ou Sistema de Gerenciamento da Segurana da Informao (SGSI) - o resultado da aplicao planejada c ca e ca de objetivos, diretrizes, pol ticas, procedimentos, modelos e outras medidas administrativas que, de forma conjunta, denem como so reduzidos os riscos para a segurana da informao. c ca
44.2
Projeto de Segurana c
A estratgia de segurana da informao de uma empresa exige a elaborao de e c ca ca um projeto de segurana (n mais alto de abstrao) que descreva todos os c vel ca aspectos da segurana da informao na empresa. Um desses aspectos consiste c ca na elaborao de um plano de segurana. O projeto de segurana, segundo ca c c Oppenheimer (1999), envolve vrias etapas de trabalho: a Identicao dos ativos da empresa em termos de informaes; ca co Anlise dos riscos de segurana; a c Anlise dos requisitos de segurana e compromissos; a c Desenvolvimento de um plano de segurana; c Denio de uma norma de segurana; ca c Desenvolvimento de procedimentos para implantar a norma e uma estratgia de implementao; e ca Implementao, gerenciamento e auditoria dos procedimentos de seguca rana. c
44.3
Plano de Segurana c
Plano de Segurana um documento de alto n c e vel que prope o que uma oro ganizao deve fazer para satisfazer os requisitos de segurana, contendo a ca c relao dos servios de TI disponibilizados, quais reas da empresa disponica c a bilizam os servios, quem ter acesso aos servios, a descrio detalhada de c a c ca sua implementao, dos procedimentos de controle dos ambientes, incidentes e ca 372
contingncias. O plano especica o tempo, as pessoas e outros recursos que e sero necessrios para desenvolver uma norma de segurana e alcanar a implea a c c mentao tcnica da norma. ca e O plano deve estar baseado na anlise de ativos de redes e riscos. Deve fazer a referncia ` topologia de rede e incluir uma lista de servios de rede que sero e a c a fornecidos, como por exemplo, FTP, Web, correio eletrnico e outros. Esta lista o deve especicar quem fornecer os servios, quem ter acesso aos servios, o a c a c modo como o acesso ser fornecido e quem ir administrar os servios. a a c Um dos aspectos mais importantes do plano de segurana uma especicao c e ca das pessoas que devem estar envolvidas na implementao da segurana de rede: ca c Sero contratados administradores de segurana especializados? a c Como os usurios nais e seus gerentes estaro envolvidos? a a Como os usurios nais, gerentes e pessoal tcnico sero treinados sobre a e a normas e procedimentos de segurana? c Para ser util, um plano de segurana precisa ter o apoio de todos os n c veis de funcionrios dentro da organizao. E muito importante que a administrao a ca ca corporativa apoie plenamente o plano de segurana. O pessoal tcnico da rede c e e de locais remotos deve se envolver no plano, da mesma forma que os usurios a nais (Oppenheimer, 1999).
44.4
Normas de Segurana c
Norma de segurana uma declarao formal das regras `s quais as pessoas que c e ca a tm um determinado acesso a tecnologia e aos ativos de informaes de uma e ` co organizao devem obedecer. (RFC 2196, The Site Security Handbook). ca Pode-se denir ainda, norma de segurana como sendo um estatuto no qual c esto transcritas regras de n intermedirio, ou seja, entre o n estratgico a vel a vel e e o de descrio de procedimentos, cujo cumprimento visa garantir a segurana ca c das informaes e recursos de uma instituio, dentro de um segmento particular co ca do ambiente desta corporao. ca A norma de segurana informa aos usurios, gerentes e ao pessoal tcnico de c a e suas obrigaes para proteger os ativos de tecnologia e informaes. A norma co co deve especicar os mecanismos pelos quais estas obrigaes podem ser cumprico das. Da mesma forma que o plano, a norma de segurana deve ter o comproc metimento de funcionrios, gerentes, executivos e pessoal tcnico. a e Uma vez desenvolvida, a norma de segurana deve ser explicada a todos pela c gerncia superior. Muitas empresas exigem que o pessoal assine uma declarao e ca indicando que leu, compreendeu e concorda em cumprir as normas. A norma de segurana um documento vivo. Pelo fato de as organizaes mudarem c e co continuamente, as normas de segurana devem ser atualizadas com regularic dade a m de reetirem novas orientaes comerciais e mudanas tecnolgicas co c o (Oppenheimer, 1999).
44.4.1
ISO/IEC 17799
A ISO/IEC 17799 a verso internacional da BS7799, homologada pela Intere a national Standartization Organization em dezembro de 2000. A NBR ISO/IEC 373
17799 a verso brasileira da norma ISO, homologada pela ABNT em setembro e a de 2001. A norma ISO rigorosamente idntica a norma BS7799. A norma e e brasileira a traduo literal da norma ISO. e ca BS7799 - Brithish Standart 7799 - uma norma de segurana da informao e c ca 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 a primeira parte da norma que contm uma introduo, denio de extenso e e ca ca a e condies principais de uso da norma. Disponibiliza 148 controles divididos co em dez partes distintas. E planejada como um documento de referncia para e implementar boas prticasde segurana na empresa. a c A BS7799-2 a segunda parte da norma e tem por objetivo proporcionar e uma base para gerenciar a segurana da informao dos sistemas das empresas. c ca Uma empresa que implante a norma BS/ISO acaba por constituir um ISMS. A forma de como implementar um ISMS descrita na norma BS7799-2. e As normas publicadas pela Organizao Internacional de Normalizao, a ca ca ISO, tm uma grande aceitao no mercado. Um exemplo disso a norma e ca e ISO 9001:2000, que trata da Gesto da Qualidade, considerada como a mais a difundida norma da ISO que existe no mundo. No caso da NBR ISO IEC 17799, que um Cdigo de Boas Prticas para a Segurana da Informao, a e o a c ca sua aplicao um pouco mais restrita que a ISO 9001:2000, pois ela no uma ca e a e norma voltada para ns de certicao. ca Entretanto, a NBR ISO IEC 17799 pode ser usada pela maioria dos setores da economia, pois todas as Organizaes, independentemente do seu porte ou co do ramo de atuao, do setor pblico ou privado, precisam proteger suas inca u formaes sens co veis e cr ticas. As principais recomendaes da NBR ISO IEC 17799 so organizadas em 11 co a sees: co Pol tica de Segurana de Informao; c ca Organizando a Segurana da Informao; c ca Gesto de Ativos; a Segurana em Recursos Humanos; c Segurana F c sica e do Ambiente; Gerenciamento das Operaes e Comunicaes; co co
Controle de Acesso; Aquisio, Desenvolvimento e Manuteno de Sistemas de Informao; ca ca ca Gesto de Incidentes de Segurana da Informao; a c ca Gesto da Continuidade de Negcios; a o Conformidade. Ela permite que uma empresa construa de forma muito rpida uma pol a tica de segurana baseada em controles de segurana ecientes. Os outros caminhos c c para se fazer o mesmo, sem a norma, so constituir uma equipe para pesquisar a
374
o assunto ou contratar uma consultoria para realizar essas tarefas. Ambas as opes so caras e demoradas. co a A ISO/IEC 17799:2000 tem como objetivo permitir que companhias que cumprem a norma demonstrem publicamente que podem resguardar a condencialidade, integridade a disponibilidade das informaes de seus clientes. co A ISO/IEC 17799:2000 fornece mais de 127 orientaes de segurana estruco c turadas em 10 t tulos principais para possibilitar aos leitores identicarem os controles de segurana apropriados para sua organizao ou reas de responsc ca a abilidade. Alm de fornecer controles detalhados de segurana para computae c dores e redes, a ISO/IEC 17799:2000 d orientaes sobre pol a co ticas de segurana, c conscientizao sobre segurana para os funcionrios, plano de continuidade dos ca c a negcios e requisitos legais. o
44.4.2
Fam ISO 27000 lia
A srie de normas ISO 27000, encabeadas pela ISO 27001 esto sendo elaboe c a radas para substituir e completar os padres denidos pela BS7799. o Como forma de dar suporte ` implantao da ISO IEC 27001:2005, o Comit a ca e da ISO que trata da segurana de informa decidiu pela criao de uma fam c ca lia de normas sobre Gesto da Segurana da Informao. Esta fam foi batizada a c ca lia pela srie ISO IEC 27000, a exemplo da srie ISO 9000 das normas de qualidade e e e da srie ISO 14000 das normas sobre meio ambiente. e Esta nova fam est relacionada com os requisitos mandatrios da ISO IEC lia a o 27001:2005, como, por exemplo, a denio do escopo do Sistema de Gesto de ca a Segurana da Informao, a avaliao de riscos, a identicao de ativos e a c ca ca ca eccia dos controles implementados. a As normas da fam ISO IEC 27000 so: lia a 27000 O seu objetivo apresentar os principais conceitos e modelos de SI. e Ainda est em processo de desenvolvimento (previso 2008-2009). a a 27001 Dene requisitos para estabelecer, implementar, operar, monitorar, revisar, manter e melhorar um Sistema de Gesto de Segurana de Ina c formao. E a norma usada para ns de certicao e substitui a norma ca ca britncia BS7799-2:2002. E a base para as Organizaes que desejam ima co plementar um SGSI. 27002 Guia prtico de diretrizes e princ a pios gerais para iniciar, implementar, manter e melhorar a gesto de SI em uma Organizao. Os objetivos de a ca controle e os controles atendem aos requisitos identicados na anlise de a riscos. 27003 Guia prtico para a implementao de um SGSI, baseado na ISO IEC a ca 27001. Ainda est em processo de desenvolvimento (previso 2008-2009). a a 27004 Fornece diretrizes com relao a tcnicas e procedimentos de medio ca e ca para avaliar a eccia dos controles de SI implementados, dos processos a de SI e do SGSI. Ainda est em processo de desenvolvimento (previso a a 2008-2009). 27005 Fornece diretrizes para o gerenciamanto de riscos de SI. Esta norma ser a constitu por indicaes para implementao, monitoramento e melhoria da co ca 375
cont nua do sistema de controles. O seu contedo dever ser idntico ao u a e da norma BS 7799-3:2005 - Information Security Management Systems - Guidelines for Information Security Risk Management, a publicar em nais de 2005. A publicao da norma como ISO est prevista para meados ca a de 2007. 27006 Esta norma ser referente ` recuperao e continuidade de negcio. a a ca o Este documento tem o t tulo provisrio de Guidelines for information and o communications technology disaster recovery services, no estando calena darizado a sua edio. ca
44.4.3
Diferenas entre a ISO/IEC 17799 e a ISO 27001 c
A norma ISO/IEC 27001 (Information Technology - Information Security Management Systems - Requirements) trata da implantao de um processo de ca gesto de segurana da informao (ISMS - Information Security Management a c ca Systems). Esta norma em conjunto com a ISO/IEC 17799 (Cdigo de Boas o Prticas da Gesto de Segurana da Informao) so as principais referncias, a a c ca a e atualmente, para a quem procura tratar a questo da segurana da informao a c ca de maneira eciente e com eccia. a A ISO 27001 uma norma que gere segurana na corporao, ou seja, cria e c ca um sistema de segurana (SGSI) dentro de uma Organizao. Isso em nenhum c ca momento garante segurana, s torna o ambiente mais controlvel. Nesta norma c o a ela contm controles de segurana, apenas cita, por exemplo, o controle A.9.1.1 e c e Per metro de Segurana F c sica, uma denio muito abragente,e pode ter vrias ca a interpretaes. co J a ISO/IEC 17799 possui todos os controles que tem na ISO 27001, s a o que com explicaes e exemplos de implementao. Isso ajuda muito na impleco ca mentao numa corporao. Um fato importante que s h certicao ISO ca ca e o a ca 27001, e no a NBR 17799. Alm disso, a certicao ISO 27001, contm um a e ca e descritivo do escopo, ou seja, quando uma empresa declara que certicada ISO e 27001, ela pode ser certicada apenas no CPD, por exemplo. Como uma norma de sistema de segurana, a ISO 27001 tambm contm e c e e controles de outras ISO, por exemplo a ISO 15408 (segurana no desenvolvic mento), mas no quer dizer que ao atender completamente a ISO 27001, ser a a atendida a ISO 15408 ou o ITIL, que tambm possui alguns de seus controles e nessa norma.
44.5
Procedimentos de Segurana c
Os procedimentos de segurana implementam normas de segurana, denem c c processos de congurao, login, auditoria e congurao. ca ca Podem-se denir procedimentos de segurana como sendo um estatuto no c qual esto transcritas regras de n a vel operacional, ou seja, em n vel de descrio de execuo de aes, cujo cumprimento visa garantir a segurana das ca ca co c informaes de uma instituio, dentro de um segmento particular do ambiente co ca da corporao. ca Devem ser escritos procedimentos de segurana para usurios nais, adminc a istradores de redes e administradores de segurana. A divulgao deve ser rec ca strita aos funcionrios diretamente envolvidos. Os procedimentos de segurana a c 376
devem especicar como controlar incidentes (quer dizer, o que fazer e quem contatar se uma intromisso for detectada), fazer auditoria e desenvolver o plano a de contingncia com objetivo de manter o negcio sempre ativo. e o Os procedimentos de segurana podem ser comunicados aos usurios e adc a ministradores em turmas de treinamento lideradas por instrutores qualicados.
44.6
Arquitetura de Segurana c
Com base na norma de segurana, criado um documento denominado pol c e tica de segurana para ser divulgado em toda empresa. Para implementar a pol c tica de segurana deve ser criada uma arquitetura de segurana que consiste na c c aplicao de todos os mecanismos de controles f ca sicos, lgicos, tcnicos e admino e istrativos necessrios para a garantia da segurana da informao (ROBERTI, a c ca 2001). Com base nessa arquitetura, so criados o plano de contingncia e o a e processo de auditoria. Uma arquitetura de segurana representa um elenco de recomendaes que c co dene os princ pios e fundamentos que devem ser observados na implementao ca de um ambiente considerado seguro em relao aos riscos, impactos e custos ao ca qual ele est submetido. a A arquitetura de segurana recomendada deve fornecer as bases para os c aspectos de segurana dos seguintes elementos: aplicaes, dados, comunicao c co ca de dados e gerncia de sistemas e rede. e Uma arquitetura de segurana deve levar em considerao trs elementos c ca e bsicos: pessoas, o modelo de segurana e a juno de padres e tecnologias. a c ca o E importante salientar que a arquitetura de segurana proposta deve conc duzir a implementaes que sejam nanceiramente poss co veis para a organizao. ca Para tanto, a arquitetura deve possuir as seguintes qualidades: Ser independente de plataforma operacional, aplicao de rede; ca Ser alavancada por tecnologias de segurana amadurecidas, por exemplo: c criptograas e carto inteligente; a Estar em conformidade com padres infacto, como por exemplo a norma o ISO/IEC 17799:2000 e CobiT; Denir relacionamentos entre os componentes de segurana: autenticao c ca e permisso de acesso, por exemplo; a
Ter performance e disponibilidade dos mecanismos de segurana; c Possuir um modo consistente de gerenciamento; Obter a conscientizao de usurios nais. ca a
44.7
Classicao de Informaes ca co
Segundo Claudia Dias (Dias, 2000), diferentes tipos de informao devem ser ca protegidos de diferentes maneiras. Por isso a classicao das informaes ca co e um dos primeiros passos para o estabelecimento de uma pol tica de segurana c de informaes. Um vez classicada a informao, a pol co ca tica pode denir como 377
trat-la de acordo com sua classe, escolhendo mecanismos de segurana mais a c adequados. A classicao mais comum de informaes aquela que as divide em 04 ca co e n veis: P blicas ou de uso irrestrito As informaes e os sistemas assim classicau co dos podem ser divulgados a qualquer pessoa sem que haja implicaes co para a instituio. Exemplo: servios de informao ao pblico em geral, ca c ca u informaes divulgadas a imprensa ou pela internet. co ` Internas ou de uso interno Podem ser chamadas tambm de corporativas. e As informaes e os sistemas assim classicados no devem sair do mbito co a a da instituio. Porm, se isto ocorrer, as conseqncias no sero cr ca e ue a a ticas. Exemplo: Servios de informao interna ou documentos de trabalho corc ca riqueiros que s interessam aos funcionrios. o a Condenciais Informaes e sistemas tratados como condenciais dentro da co instituio e protegidos contra o acesso externo. O acesso a estes sisca temas e informaes feito de acordo com sua estrita necessidade, isto co e , os usurios s podem acess-los se estes forem fundamentais para o e a o a desempenho satisfatrio de suas funes na instituio. O acesso no o co ca a autorizado a esses dados e sistemas pode comprometer o funcionamento da instituio, causar danos nanceiros ou perdas de fatias do mercado ca para o concorrente. Exemplo: Dados pessoais de clientes e funcionrios, a senhas, informaes sobre vulnerabilidades de segurana dos sistemas inco c stitucionais, contratos, balanos entre outros. c Secretas O acesso interno ou externo de pessoas no autorizadas a este tipo a de informao extremamente cr ca e tico para a instituio. E imprescind ca vel que o nmero de pessoas autorizadas seja muito restrito e o controle sou bre o uso dessas informaes seja total. Exemplo: Informaes dos conco co tribuintes, declaraes de imposto de renda. co
378
Cap tulo 45
Segurana F c sica e Lgica o

45.1 Segurana F c sica
A segurana f c sica consiste em proteger informaes atravs do uso de controles co e de acesso no permitindo que elas sejam prejudicadas atravs da presena ina e c devida de pessoas e de catstrofes naturais. Os controles de acesso podem ser a divididos em controles f sicos, tcnicos e administrativos. e Controle f sico Envolve os controles de acessos convencionais como guardas, iluminao, detectores de movimento etc. ca Controle tcnico Envolve crachs de acesso e dispositivos biomtricos. e a e Controle administrativo Envolve procedimentos de emergncia, controle de e pessoal (tanto na contratao quanto na demisso), planejamento e imca a plementao de pol ca ticas. Em relao ao ambiente, devem ser considerados os aspectos relacionados ao ca fornecimento de energia eltrica, umidade e supresso de incndio. Nesse caso, e a e todos os tipos de controles de acesso acima so poss a veis.
45.2
Segurana Lgica c o
Envolve os mecanismos de controle de acesso. Os controles de acessos so proa jetos para mitigar vulnerabilidades associadas ao acesso. Dene-se sujeito (subject) como sendo a representao do usurio dentro do ca a sistema. O objeto (object) representa o recurso computacional cujo acesso e controlado. Operaes so realizadas pelos sujeitos do sistema sob seus objetos. co a Uma permisso a manifestao de que uma determinada operao permitida a e ca ca e para um determinado objeto; por exemplo: permisso de leitura do arquivo da a la de impresso. a
45.2.1
Matrizes de acesso, listas de controle de acesso e capabilities
A matriz de acesso organizada com colunas representando os objetos, e e os usurios em linhas. Em cada clula da tabela representam-se as permisses a e o 379
que o respectivo usurio possui sobre o objeto. Um exemplo a conveno do a e ca UNIX, em que a letra R representa permisso de leitura, a letra W representa a permisso de escrita e a letra X representa permisso de execuo. a a ca Matrizes de acesso podem ser utilizadas para modelar mecanismos de autorizao simples. Mas no so recomendados para implementao, j que no ca a a ca a a escalam bem: um sistema com 50.000 usurios e 300 arquivos precisaria de a uma matriz com 15 milhes de clulas, gerando problemas de espao e maior o e c possibilidade de erros na administrao. ca Lista de controle de acesso uma maneira de simplicar o gerenciae mento das permisses de acesso, pois indexam a matriz de controle de acesso o pela coluna, indicando que usurios possuem que permisso para cada objeto. a a Esta lista de controle de acesso armazenada junto com cada objeto e relae ciona quais permisses cada usurio possui naquele objeto. Listas de controle o a de acesso (ACLs) so extensamente utilizadas em praticamente todos os sisa temas operacionais modernos (UNIX, Windows), alm de estarem presentes em e dispositivos de rede como roteadores e rewalls. A outra maneira de gerenciar a matriz de acesso indexando-a pelos usurios, e a apontando para cada um suas permisses no sistema, sendo conhecida como cao pabilities. ACLs so simples de implementar, mas dif a ceis de manter em ambientes de alta rotatividade de usurios ou arquivos, j que necessrio congur-los para a a e a a cada objeto. O agrupamento de usurios ajuda, mas no resolve a questo. a a a Como as ACLs so indexadas pelo objeto a ser protegido, mais custoso saber a e exatamente que usurios tem acesso a que arquivos do sistema. As vantagens a e desvantagens do uso de capabilities so basicamente o contrrio das mesmas a a de listas de controle de acesso. A implementao de capabilities tende a ser um ca pouco mais eciente em sistemas operacionais, enquanto mais dif saber que e cil usurios tem acesso a um arquivo, j que a informao est espalhada. a a ca a 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) o mais popular nos e sistemas operacionais modernos, e ACLs adequam-se bem a este modelo, por facilitar que cada usurio gerencie as permisses de seus objetos no sistema. a o
45.2.2
Modelos de Controle de Acesso
Modelos de controle de acesso (ou, rigorosamente, modelos de autorizao de ca acesso) denem caracter sticas primitivas de um determinado conjunto de regras de autorizao a serem utilizadas. Essas caracter ca sticas inuenciam os limites da semntica de autorizao que pode ser expressa no modelo e conseqentemente a a ca u sua implementao. Os principais modelos de controle de acesso hoje so DAC ca a (Discretionary Access Control), MAC (Mandatory Access Control) e RBAC (Role-Based Access Control). DAC: Discretionary Access Control Controle de acesso discrecionrio tem sua origem no contexto de pesquisa acadmica a e em sistemas de tempo compartilhado que surgiram no comeo dos anos setenta. c DAC baseado na noo de que usurios individuais so donos de objetos e e ca a a
380
portanto tem controle (discreo) total em quem deve ter permisses para acesca o sar o objeto. Um usurio transforma-se em dono do objeto ao cri-lo. No a a modelo discrecionrio, se Joo dono de um objeto (um arquivo, por exema a e plo), ela pode conceder a Jos a permisso de acess-lo em um modo qualquer e a a de operao. Posteriormente, ele pode revogar essa permisso a qualquer moca a mento. O princ pio bsico de DAC possesso do objeto pelo usurio que o a e a a criou. Atualmente, o DAC o modelo mais popular de controle de acesso, pela e sua utilizao em grande escala em sistemas operacionais comerciais. Todas ca as variantes do UNIX, o Netware e a srie Windows NT, 2000 e XP utilizam e o modelo DAC como seu modelo bsico de controle de acesso. Estes sistemas a operacionais utilizam extensamente a tcnica de listas de controle de acesso para e conceber a implementar as suas checagens de autorizao, dispondo tambm do ca e conceito de grupos de usurios para facilitar na administrao e concesso de a ca a permisses. o MAC: Mandatory Access Control Enquanto o ponto-chave do DAC o fato de que os usurios so considerados e a a donos do objeto e portanto responsveis pelas suas permisses de acesso, o a o modelo mandatrio prev que usurios individuais no tem escolha em relao o e a a ca a que permisses de acesso eles possuem ou a que objetos podem acessar. o Neste modelo, os usurios individuais no so considerados donos dos objea a a tos, e no podem denir suas permisses, isso realizado pelos administradores a o e do sistema. O modelo MAC conhecido, a tal ponto de ser as vezes confundido, pela sua e utilizao em pol ca ticas de acesso multin vel, em que se deseja controlar o uxo de informaes em um sistema. Em geral, se quer garantir que a informao co ca s ua em um determinado sentido: por exemplo, de n o veis mais baixos de condencialidade para n veis maiores de condencialidade, nunca de n veis mais altos para n veis mais baixos. DAC e MAC na atualidade Tanto os modelos DAC e MAC so utilizados atualmente, o DAC em maior a escala, estando presente em diversos sistemas operacionais comerciais como o UNIX, Windows e Netware. Implementaes de sistemas MAC so comuns em co a ambientes militares e de mainframe. Apesar da sua popularidade, eles apresentam problemas prprios que esto o a possibilitando o crescimento de outro modelo de acesso, o RBAC a crescer, visando resolver estas questes. o O MAC, apesar de ser reconhecido genericamente como mais controlvel e a potencialmente mais seguro que DAC no tem obtido grande uso fora dos cira cuitos militares. Isso se deve principalmente pela diculdade em adaptar uxos de negcio e hierarquia comerciais ao modelo formal. E imprtico implant-lo o a a em sistemas que no sejam militares, pelo custo de administrao e de overhead a ca que seria gerado. O DAC, por sua vez, goza de grande popularidade no mundo comercial, mas tem em seu maior problema a questo da diculdade no gerenciamento a das permisses. Sistemas operacionais modernos de rede possuem milhares de o
381
usurios e potencialmente milhes de arquivos espalhados pelos seus sistemas. a o O gerenciamento das permisses de cada um destes objetos em uma escala como o esta no um problema simples de se resolver, j que cada objeto possui sua a e a prpria informao de acesso individual. o ca Por exemplo, quando um usurio removido do sistema, costuma ser necessrio a e a remover suas informaes de acesso a todos os objetos em que possu o acesso. co a Da mesma forma, quando um objeto novo criado, necessrio denir as suas e e a permisses. Em grandes sistemas computacionais multi-usurio, essas questes o a o pesam bastante. Uma outra desvantagem tanto do MAC quanto do DAC que complicado e e estender suas regras de acesso para incluir mecanismos de proteo e excees ca co 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 dif e cil: Na maior parte do tempo, cada mdico s tem acesso e o aos dados dos seus pacientes. Quando estiver no seu turno na UTI, ele ter a tambm acesso aos pacientes que esto internados na UTI. Ao acabar seu turno, e a perde este acesso adicional. A complexidade de se expressar esse tipo de comportamento faz com que acabe-se congurando os sistemas com protees mais co relaxadas do que o estritamente necessrio. a RBAC: Role-Based Access Control RBAC foi projetado para gerenciar centralmente privilgios ao prover uma cae mada de abstrao, conhecida como role (papel), mais alinhado ` estrutura ca a da organizao. A noo central de RBAC que permisses so associadas ` ca ca e o a a papis, e usurios so associados aos seus papis corretos na organizao. Isso e a a e ca simplica bastante a administrao e gerenciamento de permisses de acesso ca o em grandes organizaes. Papis so criados para as vrias funes de negcio co e a a co o da organizao, e os usurios so associados a esses papis de acordo com suas ca a a e responsabilidades e qualicaes. Usurios podem ser facilmente reassociados co a de um papel para outro. Papis podem receber novas permisses de acesso ` e o a medida que novas aplicaes ou funcionalidades so adicionadas ao sistema, e co a permisses podem ser revogadas sempre que necessrio. o a Um papel apropriadamente entendido como uma construo semntica ` e ca a a volta do qual a pol tica de controle de acesso formulada. A coleo particular e ca de usurios e permisses associadas a um papel transitria. O papel mais a o e o e estvel porque as atividades e funes da organizao em geral mudam menos a co ca do que o conjunto de usurios ou de permisses. a o Isso torna a administrao de um sistema RBAC muito mais fcil e escalvel ca a a do que a de um sistema DAC, por exemplo, que precisa associar usurios a a objetos diretamente, sem a construo do papel entre os dois, atuando como ca componente estabilizador. Alm do forte motivo de facilitar o gerenciamento das permisses de acesso, e o um outro ponto motivador de RBAC a sua exibilidade de adaptao a regras e ca de acesso particulares de cada sistema, atravs do recurso de constraints. Cone straints so predicados que, aplicados a relaes e funes do modelo, retornam a co co um valor aceito ou no aceito. Isso permite expressar, na pol a tica de acesso do sistema, restries como a separao de deveres, em que um mesmo usurio co ca a no pode subverter a segurana do sistema ao exercer dois papis conitantes a c e ao mesmo tempo. Por exemplo, um mesmo usurio no poderia ser ao mesmo a a 382
tempo o gerente de compras (que toma a deciso de realizar uma compra), e a o gerente nanceiro (que passa o cheque da compra), j que isso poderia abrir a espao para fraudes em que ele indicaria uma compra fraudulenta e autorizaria c a sua fatura por conta prpria. A separao de deveres um princ o ca e pio clssico a de segurana, utilizado extensamente no mundo dos negcios, e poss de ser c o e vel expressado como regra de acesso em sistemas RBAC.
383
Cap tulo 46
Backup de Dados
Existem vrias formas de se garantir a disponibilidade da informao, a mais a ca importante a cpia destes dados em local seguro, ou seja, o backup de dados. e o Os backups podem ser classicados em trs tipos: e Backup total Realiza uma cpia de todos os dados para a m o dia, no impora tando o contedo do ultimo backup. seja, o atributo de arquivamento u desmarcado ou redenido. Uma ta atualizada de backup total pode e ser usada para restaurar um servidor completamente em um determinado momento. Backup incremental Salva os arquivos que foram alterados desde o ultimo backup. Neste processo o novo arquivo armazenado na m e o arquivo e dia original no removido da m a e dia. No processo de restaurao devemos ca ter o ultimo backup completo e dos os backups incrementais desde ento. a Backup diferencial Copia todos os arquivos que foram alterados desde o ultimo backup completo, por este motivo ocupa mais espao nas m c dias de backup e mais lento de ser gerado, contudo mais fcil de recuper-lo. e e a a Para restaurar os dados a partir deste tipo de backup deve-se ter em mos a apenas o ultimo backup completo e o ultimo backup diferencial. Backup delta S faz a cpia dos dados reais que foram modicados nos aro o quivos, um processo de backup mais rpido e que ocupa menos espao e a c nas m dias de backup, contudo o processo de restaurao mais lento e ca e complexo.
46.1
Meios de Armazenamento
Denida as necessidades bsicas a serem atendidas devemos selecionar um do a tipos de armazenamento, que podem ser: on-line, Prximos e o-line. o As m dias de armazenamento on-line consistem em discos r gidos ou arrays de discos. Estas m dias fornecem uma disponibilidade em tempo real e so a normalmente utilizados para fornecer uma forma altrnativa de armazenamento. Estas m dias no substituem os backups oine. a O armazenamento prximo formado por Jukeboxes ticos e cpias loo e o o cais, que esto rapidamente acess a veis, normalmente fazem uso de robs para o 384
gerenciarem as m dias fornecendo um acesso rpido aos dados quando o servio a c on-line no est dispon a a vel. J o armazenamento o-line consiste no arquivamento de m a dias fora da rede de dados em um local seguro e protegido contra roubo, catstrofes naturais a e outros ameas. Sempre que poss as m c vel dias devem ser armazenadas em local geogrcamente diferente e fora das instalaes comerciais da empresa. a co Para a realizao deste tipos de backup podem ser utilizadas trs tipos de ca e m dias diferentes: tas/discos magnticos, armazenamento tico e arrays de e o disco. As tas magnticas so as m e a dias mais comuns, mais baratas utilizadas nos backups o-line, mas por outro lado so as mais lentas e que ocupam um a grande espao. Seus principais tipos so: 8mm, Travan, DLT, DAT e Magstar. c a O armazenamento tico muito popular em ambientes onde a velocidade o e e a conabilidade so as maiores preocupaes, estes ambientes fazem uso de a co servidores com jukeboxes ticos de alta disponibilidade que so solues caras o a co porem muito ecientes. Os arrays de discos ou simplesmente RAIDs (Redundant Array of Independet Disks) so um subsistema de discos r a gidos que melhoram o desempenho e a tolerncia a falhas, uma vez que os dados so gravados em mais de um a a disco ao mesmo tempo. Estas solues podem ser tanto implementadas em co 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 soluo de RAID fornece um melhor desempenho e tolerncia a falhas, ca a mas de forma alguma substitui o processo de backup o-line. Vale lembrar que dois ou mais discos podem falhar ao mesmo tempo, perdendo o acesso total aos dados armazenados no array. Outra soluo de proteo aos dados o HSM (Hierarchical Storage Manageca ca e ment), que um sistema automatizado para o gerenciamento de dados e espao e c em disco, muito utilizado em mainframes. Esta soluo monitora a capacidade ca das unidades e move os dados para as m dias de armazenamento prximo ou o oine, mais lentas. O HSM pode mover os dados segundo sua idade, freqncia de uso ou ue baseado em outros critrios, permitindo deste modo uma migrao de dados e ca automtica. Esta soluo relativamente cara e dif de ser implementada. a ca e cil
385
Cap tulo 47
V rus e Ataques
Conceito bsicos: a Cracker Termo usado para designar quem quebra um sistema de segurana, c de forma ilegal ou sem tica. Este termo foi criado em 1985 pelos hackers e em defesa contra o uso jornal stico do termo hacker. Hacker Habitualmente (e erradamente) confundido com cracker, um hacker e um expert ou Problem Solver, aquele que apresenta solues para probleco mas tcnicos relativos ` Internet. e a White Hat (aka hacker tico) Hacker em segurana, utiliza os seus conhecie c mentos na explorao e deteco de erros de concepo, dentro da lei. ca ca ca Black Hat (aka cracker ou dark-side hacker) criminoso ou malicioso hacker, um cracker. Gray hat Tem as habilidades e intenes de um hacker de chapu branco na co e maioria dos casos, mas por vezes utiliza seu conhecimento para propsitos o menos nobres. Script Kiddie Antigamente chamado de Lammer, um indiv e duo que no a tem dom nio dos conhecimentos de programao. E pouco experiente, ca com poucas noes de informtica, porm tenta fazer-se passar por um co a e cracker a m de obter fama, o que acaba gerando antipatia por parte dos hackers verdadeiros.
Newbie Newbie, Noob ou a sigla NB, aquele jovem aprendiz de hacker que e possui uma sede de conhecimento incrivel, pergunta muito e ignorado e e ridicularizado na maioria das vezes, ao contrario dos lammers no tenta a se pr acima dos outros. o Phreaker Hacker especialista em telefonia mvel ou xa. o V rus E um programa capaz de infectar outros programas e arquivos de um computador. Para realizar a infeco, o v ca rus embute uma cpia de si o mesmo em um programa ou arquivo, que quando executado tambm exe ecuta o v rus, dando continuidade ao processo de infeco. Para que um ca computador seja infectado por um v rus, preciso que de alguma maneira e um programa previamente infectado seja executado. 386
Worms E um programa completo capaz de se propagar automaticamente atravs e de redes, enviando cpias de si mesmo de computador para computador. o Sua propagao se d atravs da explorao de vulnerabilidades existentes ca a e ca ou falhas na congurao de softwares instalados em computadores. O ca worm pode trazer embutido programas que geram algum tipo de problema ou que tornam o computador infectado vulnervel a outros ataques. a Um worm pode provocar danos apenas com o trfego de rede gerado pela a sua reproduo. ca Cavalos de Tria (Trojan) E um programa que alm de executar funes o e co para as quais foi aparentemente projetado, executa tambm outras funes e co normalmente maliciosas e sem o conhecimento do usurio como: alterao a ca ou destruio de arquivos; furto de senhas e nmeros de cartes de crdito; ca u o e incluso de backdoors. No se rplica, no infecta outros arquivos, ou a a e a propaga cpias de si mesmo automaticamente. Necessita ser explicitao mente executado. Exemplos comuns de cavalos de tria so programas o a que voc recebe ou obtm de um site e que dizem ser jogos ou protetores e e de tela. Traps So como backdoors. Garantir uma forma de retornar a um computador a comprometido, sem precisar recorrer aos mtodos utilizados na realizao e ca da invaso. A forma usual de incluso de um backdoor consiste na adio a a ca de um novo servio ou substituio de um determinado servio por uma c ca c verso alterada, normalmente incluindo recursos que permitam acesso rea moto (atravs da Internet). e Spyware/Adware Spyware (Software Espio) e Adware (Publicidade no dea a sejada). Spyware so arquivos ou aplicativos que so instalados em seu a a computador, algumas vezes sem seu consentimento ou autorizao, ou ca mesmo depois que voc aceita as Condies de Uso. Os Spyware monie co toram e capturam informaes das atividades dos usurios, as enviando co a para servidores onde so armazenadas para ns em geral comerciais. Tais a informaes sero posteriormente vendidas a provedores de produtos e co a servios como maillings. Estes provedores utilizam-se destas informaes c co para difundir informaoes na forma de spam. Podem ser maliciosos, inc cluindo programas que capturam as informaes de tudo o que digitado co e no teclado. Adware, semelhante aos spyware, so aplicativos instalados da a mesma forma que no caso anterior, fazendo com que banners publicitrios a de servios e produtos aparecem na sua telinha. c
DoS/DDoS O objetivo de tais ataques indisponibilizar o uso de um ou mais e computadores, e no invadi-los. Nos ataques de negao de servio (DoS a ca c Denial of Service) o atacante utiliza um computador para tirar de operao ca um servio ou computador conectado ` Internet. No DDoS (Distributed c a Denial of Service) constitui um ataque de negao de servio distribu ca c do, ou seja, um conjunto de computadores utilizado para tirar de operao e ca um ou mais servios ou computadores conectados ` Internet. Normalc a mente estes ataques procuram ocupar toda a banda dispon vel para o acesso a um computador ou rede, causando grande lentido ou at mesmo a e indisponibilizando qualquer comunicao com este computador ou rede. ca
387
IP Spoong O IP spoong consiste na troca do IP original por um outro, podendo assim se passar por um outro host. A pessoa que ir realizar o a spoong tem ento dois problemas na verdade: o de alterar o ip origem, a mais simples de resolver, e o de manter a seqncia de nmeros, que ue u por serem geradas arbitrariamente, complica em muito esta tarefa. As seqncias de nmeros so geradas no TCP para a comunicao entre os ue u a ca hosts. Flooding O TCP Flood SYN attack tira vantagem do comportamento do 3 way handshake efetuado pelo protocolo TCP no processo de uma conexo. O a attacker faz um pedido de conexo para o servidor da vitima com pacotes a que carregam o endereo falsicado de IP da fonte (mtodo IP spoong). c e Como resultado o servidor da vitima perde tempo e recursos de mquina e 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 uma tcnica de attack e e que tenta saturar uma conexo de Internet atravs do envio continuo de a e uma serie de pings originados tipicamente em redes de alta velocidade para redes de baixa velocidade. Alm dos mecanismo mais tradicionais de infeco tais como setor de boot, e ca macros e memria, trs vetores tambm se destacam: correio eletrnico, comparo e e o tilhamento de arquivos e falhas no sistema operacional. Curiosamente enquanto os v rus antigos faziam uso de mecanismos extremamente complexos para se infectar, hoje em dia vrios dos vermes e v a rus fazem uso dos prprios recursos o do sistema operacional.
47.1
Estratgias de combate ` pragas eletrnicas e a o
A estratgia de mais longo prazo a preveno. Usurios, suporte e admine e ca a istradores devem ser alertados para os riscos de v rus de computador e mecanismos ecazes, em acordo com a pol tica de segurana, que deve ser colocada em c prtica. a As tarefas mais comuns que devem ser realizadas so a anlise e remoo de a a ca compartilhamento de redes Microsoft, anlise e atualizao do sistema operaa ca cional e anlise e atualizao do sistema de antiv a ca rus do usurio. a Campanhas de conscientizao tambm so importantes, os usurios devem ca e a a ser alertados sobre os perigos existentes em determinadas aes, como baixar co arquivos executveis por e-mail. a No caso em que uma reao necessria, no basta somente remover a praga ca e a a eletrnica. E importante registrar o incidente e analisar qual fato levou ` ino a feco e tomar as medidas cab ca veis para a remoo da vulnerabilidade. Tambm ca e importante que esquipes de resposta ` emergncia sejam criadas dentro da ese a e trutura do rgo. o a
47.1.1
Antiv rus
Todos os antiv rus agem de forma semelhante. Existem dois mtodos bsicos e a usados para combater v rus. O primeiro consiste em manter nos antiv rus um grande banco de dados onde cam registradas todas as assinaturas (parte do 388
v rus que o caracteriza) de v rus conhecidos. Da a importncia de manter seu a antiv rus atualizado, pois a cada dia surgem centenas de novos v rus. Assim, quando procuramos v rus no sistema, na verdade, o que estamos fazendo e comparar cada arquivo nosso com a assinatura dos v rus registrados. A segunda forma de proteo conhecida como inoculao, que nada mais ca e ca que a criao de um banco de dados contendo as principais informaes e ca co (tamanho, data de criao e data da ultima alterao) sobre os arquivos inca ca oculados. Assim, cada vez que procuramos por v rus no sistema, o programa antiv rus compara as informaes do banco de dados criado com as que esto co a no disco. Se houver alguma diferena emitido um alerta. Mas note que no c e a e qualquer arquivo que deve ser inoculado, uma vez que arquivos de dados sempre so alterados. Os arquivos executveis, DLLs e arquivos de sistema so exempa a a los de arquivos que devem ser inoculados, pois so as principais v a timas de v rus e no mudam seu contedo com freqncia. a u ue
389
Cap tulo 48
Princ pios de Criptograa

Em um processo de comunicao, uma mensagem pode ser denida como um ca conjunto de informaes que um remetente deseja enviar para um ou mais desco tinatrios. O processo de modicar uma mensagem de forma esconder seu a contedo chamado encriptao. A cincia que estuda a encriptao e deu e ca e ca criptao de mensagens chamada Criptograa. No in ca e cio, a criptograa era utilizada com o unico intuito de garantir condencialidade. Somente as pessoas que conhecessem o processo de criptograa utilizada poderiam ler a mensagem. Atualmente, a criptograa utilizada para prover tambm as seguintes garane e tias: Autenticao: Provar a identidade dos participantes em um processo de ca comunicao; ca Integridade: Permitir que o receptor verique se a mensagem no foi ala terada ou corrompida ao longo do caminho; Incontestabilidade: Impedir que um remetente negue o envio de uma mensagem. A incontestabilidade tambm chamada no-repdio. Em outras e e a u palavras, poss provar para um terceiro que uma mensagem s pode e vel o ter sido gerada por um remetente espec co. Um algoritmo de criptograa uma funo matemtica utilizada para ene ca a criptar e decriptar uma mensagem. Inicialmente, o segredo da comunicao era ca baseado no segredo do algoritmo de criptograa, de forma que para que duas se comunicassem de forma segura, ambas precisavam conhecer o algoritmo. Nos sistemas criptogrcos atuais o segredo de comunicao baseado no segredo de a ca e uma chave de criptograa. A chave de criptograa passada como parmetro e a para o algoritmo pra que esse possa criptografar ou descriptografar uma mensagem. Neste modelo, o algoritmo de criptograa pblico, e somente aqueles e u que conhecem a chave de criptograa utilizada para encriptar uma mensagem so capazes de decript-la. a a O conjunto de valores que uma chave pode assumir chamado espao de e c chaves (keyspace). Na Internet, por exemplo, atualmente so utilizadas chaves a com comprimento de at 4096 bits, o que permite escolher uma chave em um e conjunto de 24096 elementos. Portanto, utilizando uma chave com esse comprimento seria poss criptografar uma mensagem de 24096 formas diferentes vel 390
utilizando o mesmo algoritmo.
48.1
Tipos de Criptograa
As tcnicas de criptograa so divididas em trs tipos principais que so: (i) e a e a Funes Hash; (ii) Criptograa Simtrica e (iii) Criptograa Assimtrica. O co e e tipo de garantia (autenticao, integridade, no-repdio e conabilidade) que se ca a u deseja no processo de comunicao o que determina qual o tipo de criptograa ca e que se deve utilizar. Os tipos de criptograa so descritos a seguir: a Funes Hash: Funes matemticas que transformam um texto em uma co co a sequncia de caracteres de tamanho xo (128, 160, 512 bits, por exemplo) e independente do tamanho do texto. A sequncia de caracteres geradas e e conhecida como resumo da mensagem (message digest). A segurana das c funes hash se baseiam no fato delas serem funes s de ida. A sa co co o da do processo de uma funo hash no dependente da entrada de uma ca a e forma clara, o que na prtica torna imposs alterar uma mensagem de a vel modo que o mesmo hash seja gerado e mensagem continue fazendo sentido. Boas funes hash tambm devem garantir que seja computacionalmente co e imposs gerar a mensagem original a partir de seu hash; vel Criptograa Simtrica: E composto por uma chave e um algoritmo que e pode ser executado no modo de encriptao, para cifrar uma mensagem, ca ou decriptao, para decifr-la. A chave utilizada nos processos de enca a criptao e decriptao a mesma e deve ser mantida em segredo entre as ca ca e partes comunicantes. Os algoritmos de criptograa simtrica geralmente e so baseados em operaes de shift e XOR, o que permite que sejam exa co tremamente ecientes e de fcil implementao em hardware; a ca Criptograa Assimtrica: E composto por um algoritmo e um par de e chaves pblica e privada geralmente denotadas por K + e K respectiu vamente. Uma mensagem cifrada com a chave K + s pode ser decifrada o com a chave K e vice-versa. Dessa forma, se Bob deseja garantir que sua mensagem s poder ser lida por Alice, ento ele deve cifrar a mensagem o a a com a chave pblica de dela. Como Alice , em tese, a unica detentora de u e sua chave privada, ela ser a unica capaz de decifrar a mensagem enviada a por Bob. Dessa maneira pode-se garantir a condencialidade da mensagem. Repare que nem mesmo Bob ser capaz de decifrar a mensagem. a Bob pode ainda cifrar uma mensagem com sua prpria chave privada e o enviar para Alice. Nesse caso, para decifrar a mensagem Alice dever utia lizar a chave pblica de Bob. Dessa forma, Alice poderia garantir que foi u realmente Bob quem enviou a mensagem e no um impostor. Algoritmos a de criptograa assimtrica geralmente so baseados em operaes de fae a co torao, exponenciao e logaritmos de grandes nmeros, o que os torna ca ca u muito mais lentos do que os algoritmos simtricos. A criptograa de chave e assimtrica a base do sistema de criptograa de chave pblica, que ser e e u a discutido mais adiante;
391
48.2
Algoritmos de Criptograa Simtricos e
Trs exemplos de cifras (mtodo de criptograa) do tipo chave simtrica so: e e e a Cifra de Csar cada letra do texto cifrado recebe a letra do texto aberto mais e uma constante, com rotao no alfabeto. ca Cifra Monoalfabtica Cada letra do texto aberto substitu por uma outra e e da unica letra. Cifra Polialfabtica Usa-se vrias cifras de Csar para se levar em conside a e erao a posio da letra no texto. Ou seja, a constante de Csar se ca ca e modica em funo da posio da letra no texto aberto. ca ca Os algoritmos simtricos utilizados na prtica so: e a a 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 usado na e Internet em conexes Web segura, pois o SSL se utiliza do DES. Ele um o e algoritmo seguro para a maioria das aplicaes, entretanto, em aplicaes co co altamente secretas, ele no deve ser usado, pois existe o perigo de violao. a ca 3DES So usados 3 estgios e duas chaves. No primeiro estgio, o texto sima a a ples criptografado com chave K1 da maneira usual do DES. No segundo e estgio, o DES executado no modo de descriptograa, com o uso de a e uma chave K2. Por m, outra criptograa feita com a chave K1. So e a utilizadas 2 chaves porque os criptgrafos concordam que 112 bits sero suo a cientes para aplicaes comerciais durante um tempo. O uso de 168 bits co s criaria overhead desnecessrio de gerenciar e transportar outra chave, o a com pouco ganho real. Ao utilizar dessa maneira (criptograa, descriptograa, criptograa), um computador que utiliza a criptograa tripla pode se comunicar com outro que utiliza a criptograa simples apenas denindo k1=k2. RC2 e RC4 Mais rpidos do que o DES, esses cdigos podem se tornar mais a o seguros com o simples aumento do tamanho das chaves, O RC2 pode substituir perfeitamente o DES com a vantagem de ser 2 vezes mais rpido, a j o RC4 ca 10 vezes mais rpido. Algumas chaves so fracas. Suas chaves a a a so de 1 a 2048 bits. a
IDEA (International Data Encryption Algorithm) Criado em 1991. Ele foi projetado para ser facilmente programado, forte e resistente a muitas e formas de criptoanlise. Possui chave de 128 bits, porm patenteado. a e e AES (Advanced Encryption Standard) Foi promovido em um concurso um novo padro cujas propostas eram: 1 - O algoritmo teria de ser uma a cifra de bloco simtrica; 2 - Todo o projeto teria de ser pblico; 3 - Deve u eriam ser admitidos tamanhos de chaves iguais a 128, 192 e 256 bits; 4 Teriam de ser poss veis implementaes de software e de hardware; 5 - O alco goritmo teria de ser pblico ou licenciado em termos no-discriminatrios. u a o Os nalistas: 1 - Rijndael; 2 - Serpent; 3 - Twosh; 4 - RC6; 5 - MARS.
392
Cifra Blowsh DES IDEA RC4 RC5 Rijndael Serpent 3DES Twosh
Autor Bruce Schneier IBM Massey e Xuejia Ronald Rivest Ronald Rivest Daemen e Rijmen Anderson, Biham, Knudsen IBM Bruce Schneier
Comprimento da chave 1 a 448 bits 56 bits 128 bits 1 a 2048 bits 128 a 256 bits 128 a 256 bits 128 a 256 bits 168 bits 128 a 256 bits
Comentrios a Velho e lento Muito fraco para usar agora Bom, mas patenteado Algumas chaves so fracas a Bom, mas patenteado Melhor escolha Muito forte Segunda melhor escolha Muito forte; amplamente utilizado
Tabela 48.1: Alguns algoritmos criptogrcos de chave simtrica a e
48.3
Algoritmos de Criptograa Assimtricos e
A criptograa de chave pblica ou criptograa assimtrica, foi criada em 1970. u e Esse mtodo funciona com uma chave para criptografar, e outra para descripe tografar a mesma mensagem.No sistema de chave pblica, cada pessoa tem que u ter duas chaves, uma que ca publicamente dispon vel, e outra, que deve ser mantida em segredo. O algoritmo que se mantm at hoje o RSA, que patene e e e 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 pblica da u pessoa (B), note que, a partir desse momento somente ela, poder ler as a mensagens; As mensagens so enviadas a pessoa (B) atravs da Internet; a e A pessoa (B), recebe as mensagens de (A) e (C), na qual ela usa a chave privada para descriptografar; A pessoa (B), l as mensagens, e se, tiver que responde-las, dever usar e a as chaves pblicas de criptograa de (A) e ou (C). u Nesse momento, importante enfatizar que o sigilo da chave privada muito e e importante, pois, a criptograa assimtrica, se baseia no fato de que a chave e privada, realmente privada, por isso, somente seu detentor deve ter acesso. A e descrio do algoritmo mais utilizado segue abaixo: ca RSA (Rivest, Shamir, Adleman) O mtodo se baseia em alguns princ e pios da teoria dos nmeros. De forma resumida: u Escolha dois nmeros primos extensos, p e q (geralmente, de 1024 u bits) Calcule n = p x q e z = (p-1) x (q-1) Escolha um nmero d tal que z e d sejam primos entre si u Encontre e de forma que e x d = 1 mod z
393
Com esses parmetros calculados com antecedncia, estamos prontos para a e comear a criptograa. Divida o texto simples (considerado um string de bits) c em blocos, de modo que cada mensagem de texto simples P que no intervalo 0 <= P < n. Isso pode ser feito agrupando-se o texto simples em blocos de k bits, onde k o maior inteiro para o qual a desigualdade 2k < n verdadeira. e e Para criptografar a mensagem P, calcule C = P e(modn). Para descrip tografar C, calcule P = Cd(modn). E poss provar que, para todo P na faixa vel especicada, as funes de criptograa e descriptograa so inversas entre si. co a Portanto, a chave pblica consiste no par (e,n) e a chave privada consiste em u (d,n). Lento demais para codicar grande volume de dados, mas amplamente utilizado para a distribuio de chaves. A segurana do sistema est baseado na ca c a diculdade de fatorar nmeros grandes. u
48.4
Tcnicas de Quebra de Criptograa e
Basicamente, os trs tipos de ataque destinado ` quebra de criptograa so: e a a Ataque Exclusivo a Texto Cifrado No se conhece o texto aberto. Anlise a a estat stica geralmente utilizada para se extrair algo do texto cifrado. e Ataque com Texto Aberto Conhecido Se conhece o texto cifrado e pelo menos parte do texto aberto. A descoberta da chave ca menos complexa em relao ao caso anterior. ca Ataque com Texto Aberto Escolhido E poss escolher o texto aberto a vel ser encriptografado. Desta forma, a descoberta da chave ca mais facilitada.
394
Cap tulo 49
Autenticao ca
49.1 Autenticao de Mensagens ca
Autenticao de mensagens um mecanismo ou servio utilizado para vericar ca e c a integridade de uma mensagem. Os mtodos mais comuns so MAC (message e a autentication code) e funes hashes seguras. O MAC requer o uso de chave co secreta e produzido atravs do uso dessa chave em uma mensagem de tamanho e e varivel. Uma funo hash mapeia uma mensagem de tamanho varivel em um a ca a hash de tamanho xo e para garantir o no-repdio utilizado em conjunto com a u e uma chave privada. Quando o mtodo de autenticao garante o no repdio, ento trata-se de e ca a u a uma assinatura digital. O MAC no prov assinatura digital, uma vez que o a e remetente e o receptor compartilham a mesma chave. As funes hash so utilizadas para a gerao de sumrios de mensagens co a ca a message digests. Com os sumrios de mensagens poss fornecer autenticao a e vel ca sem que haja sigilo e tem quatro propriedades: 1. Se a mensagem fornecida, o clculo de seu sumrio fcil. e a a e a 2. Se o sumrio fornecido, ser imposs encontrar a mensagem original. a e a vel 3. Dada uma mensagem, ningum pode encontrar uma mensagem diferente e com o mesmo sumrio que ela. a 4. Uma mudana de um bit na mensagem produz drsticas mudanas no c a c sumrio. a As funes de hash mais utilizadas so o MD5 e o SHA-1. O sumrio gerado co a a pelo MD5 possui 128 bits e um melhoramento do MD4. J o SHA-1 trabalha e a com hash de 160 bits. O SHA-1 foi considerado o sucessor do MD5. Ambos tm vulnerabilidades comprovadas. Em algumas correntes, sugerido que o e e SHA-256 ou superior seja usado para tecnologia cr tica. O MAC mais utilizado o HMAC, que utilizado no IPSec. O HMAC se e e baseia em algoritmos de hash como o SHA-1 e o MD5.
395
49.2
Protocolos de Autenticao ca
A autenticao a tcnica atravs de qual um processo conrma que seu parceiro ca e e e na comunicao quem deve ser e no um impostor. ca e a
49.2.1
Mtodos de Autenticao e ca
A autenticao pode ser feita com a combinao de um ou mais dos itens abaixo: ca ca Algo que voc saiba, um nmero de identicao pessoal ou uma senha e u ca (autenticao tipo 1). ca Algo que voc tenha, um carto de banco ou um carto com chip (aute a a enticao tipo 2). Em alguns casos, esses dispositivos geram senhas autoca maticamente e so conhecidos como tokens. a Algo que voc , impresso digital ou escaneamento de retina (autenticao ee a ca tipo 3). Os parmetros de desempenho mais importantes em um sistema a de biometria so: FRR (False Rejection Rate), FAR(False Acceptance a Rate), tempo de registro, tempo de atendimento e aceitabilidade (no a invasivo).
49.2.2
Autenticao baseada em uma chave secreta comca partilhada
Para efetuar uma autenticao baseada em uma chave secreta compartilhada, ca e necessrio que Alice e Bob estabeleam essa chave (Kab ). a c Os protocolos de autenticao baseada em uma chave secreta baseada ca e no princ pio do desao-resposta (challenge-response), onde o emissor envia um nmero aleatrio para o receptor (nonce); quando este recebe a mensagem, u o transforma o nmero recebido em uma forma especial e o retorna ao emissor. u Uma brecha que no deve existir no protocolo a possibilidade de ataque a e por reexo, em que uma pessoa no meio da comunicao recebe um desao. A a ca pessoa indesejada cria outra conexo para obter a resposta para aquele desao, a assim, utiliza a resposta para o sucesso da autenticao anterior. ca Outras propriedades importantes para os protocolos dessa classe so: a O transmissor deve provar sua identidade antes que o receptor responda;
As pessoas envolvidas no processo devem utilizar chaves espec cas 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 desaos de conjuntos distintos. Na atualidade h protocolos baseados no uso de HMACs e na codicao de a ca itens atravs do encadeamento de blocos de cifras. e
396
49.3
Certicado Digital
Um certicado digital, ou identidade digital, pode ser visto como uma carteira de identidade para uso na internet. Tecnicamente, um certicado digital um e conjunto de dados (um arquivo), assinado digitalmente pela autoridade certicadora e contento tipicamente informaes como: Chave pblica do certicado; co u Nome e endereo de e-mail do dono do certicado; Nome e assinatura digital da c autoridade certicadora; Privilgios de acesso a sites seguros; Outras. e Uma Autoridade Certicadora uma entidade de conana que administra e c a gesto de certicados digitais atravs da emisso, revogao e renovao dos a e a ca ca mesmos por aprovao individual. Uma Autoridade Certicadora pode emitir ca diferentes tipos de certicados, atribuindo diferentes n veis de conana a cada c tipo. Para cada tipo de certicado utilizado um processo diferente para realizar e a vericao da identidade do solicitante. ca O padro para descrever certicados o X.509 (pela ITU). Um modo difera e ente de certicar chaves pblicas o PKI (Public Key Infrastructure). Uma u e PKI tem vrios componentes, incluindo usurios, CAs, entidades de registro, a a certicados e diretrios. A funo fornecer um modo de estruturar esses como ca e ponentes e denir padres para os vrios documentos e protocolos. Uma forma o a particularmente simples de PKI uma hierarquia de CAs. e Um certicado digital um arquivo de computador que contm um conjunto e e de informaes referentes a entidade para o qual o certicado foi emitido (seja co uma empresa, pessoa f sica ou computador) mais a chave pblica referente a u chave privada que acredita-se ser de posse unicamente da entidade especicada no certicado. Um certicado padro X.509 contm os seguintes campos: a e Verso Contm a verso do certicado X.509, atualmente verso 3 a e a a N mero serial Todo certicado possui um, no globalmente unico, mas u a e unico no mbito de uma AC, ac LCRs usam o serial para apontar quais a certicados se encontram revogados Tipo de algoritmo Contem um identicador do algoritmo criptogrco usado a pela AC para assinar o certicado juntamente com o tipo de funo de ca hash criptogrca usada no certicado a Nome do titular Nome da entidade para o qual o certicado foi emitido Nome do emitente Autoridade Certicadora que emitiu/assinou o certicado
Per odo de validade Mostra o per odo de validade do certicado no formato No antes e No depois (Ex. No antes de 05/03/2006 - 14:35:02, No a a a a depois de 05/03/2007 - 14:03:2006 ) Informas de chave p blica da entidade Algoritmo de chave pblica e co u u Chave pblica. u Assinatura da AC A garantia que a AC prov sobre a veracidade das ine formaes contidas neste certicado de acordo com as pol co ticas da AC Identicador da chave do titular E uma extenso do X.509 que possui um a identicador numrico para a chave pblica contida neste certicado, ese u pecialmente util para que programas de computador possam se referir a ela 397
Identicador da chave do emitente A mesma idia mencionada anteriore mente, s que se referindo a chave pblica da AC que emitiu o certicado o u Atributos ou extenses A vasta maioria dos certicados X.509 possui camo pos chamados extenses (OID) que provem algumas informaes exo e co tras, como cadastros adicionais do titular e do emitente, especicaes co de propsito do certicado e etc. o
398
Cap tulo 50
Segurana em diversas c camadas

50.1 Secure Sockets Layer
Em 1995, a ento dominante do mercado de browsers, Netscape, resolveu ina troduzir um pacote de segurana chamado Secure Sockets Layer (SSL), para c atender demandas por conexes mais seguras na internet. O SSL se tornou um o padro e at hoje utilizado para prover conexes seguras. O SSL est posia e e o a cionado entre a camada de transporte e a camada de aplicao da pilha TCP/IP ca e funciona provendo servios de autenticao do servidor, comunicao secreta c ca ca e integridade dos dados. O SSL pode ser utilizado para prover segurana na comunicao de qualquer c ca aplicao baseada em TCP. O uso do SSL com HTTP, geralmente referenciado ca e como HTTPS (Secure HTTP ). O HTTPS geralmente utiliza a porta TCP 443, ao invs da porta 80. e Antes que o cliente e o servidor iniciem a troca de mensagens de forma segura necessrio que se estabelea uma conexo SSL seguindo as seguintes epatas: e a c a 1. O cliente e o servidor negociam parmetros de conexo como verso do a a a protocolo, nmero da sesso, algoritmos de cifragem, algoritmo de comu a pactao. Eles trocam ainda valores randmicos (nonce) que sero utica o a lizados no processo de gerao da chave de sesso; ca a 2. O cliente solicita o certicado do servidor. Caso o certicado do servidor esteja assinado por uma CA convel, o cliente extrai a chave pblica a u do servidor e a utiliza para criptografar uma chave pr-mestra antes de e envi-la ao servidor. A chave pr-mestra utilizada em combinao com a e e ca os valores randmicos trocados na etapa 1 pra gerar a chave simtrica de o e sesso que ser utilizada na comunicao; a a ca 3. O cliente e o servidor trocam mensagens de controle para sinalizar que todas as prximas mensagens sero cifradas utilizando a chave de sesso o a a gerada. 399
A partir da etapa 3, todos os dados gerados pela camada de aplicao sero ca a cifrados pelo SSL antes de serem repassados para a camada de transporte. E importante ressaltar que o SSL no cifra as informaes do cabealho TCP, mas a co c somente os dados gerados pela camada de aplicao. ca
50.2
IPSec
A IETF sabia h muitos anos da carncia de segurana na Internet. Para aua e c ment-la, havia uma disputa para denir onde coloc-la. Para especialistas, a a a segurana deveria ser colocada no n c vel de aplicao. A diculdade com essa ca abordagem que ela exigiria que todas as aplicaes fossem modicadas am e co de torn-las seguras. Outra abordagem seria colocar a segurana em um n a c vel intermedirio entre aplicao e transporte, como feito no SSL. Dessa forma, a ca e as aplicaes no precisariam ser alteradas completamente. co a Uma outra viso que os usurios no conhecem segurana, e portanto a e a a c no seriam capazes de implement-la corretamente nos n a a veis de transporte ou aplicao. A partir desse princ ca pio, IETF introduziu o IPSec. O IPSec uma su de protocolos que foi desenvolvida para proporcionar e te autenticao, condencialidade e integridade dos dados no n de rede. Todos ca vel os servios oferecidos pelo IPSec so baseados em criptograa de chave simtrica c a e porque o alto desempenho importante. E importante ressaltar que o projeto e do IPSec independente do algoritmo de criptograa utilizado, de modo que a e quebra de um algoritmo no represente o m da utilidade do projeto. a Embora trabalhe na camada IP, o IPSec orientado a conexes. Isso se deve e o a ` necessidade do estabelecimento de uma chave de criptograa que ser utilizada a por um determinado per odo. No contexto do IPSec, uma conexo chamada a e SA (Security Association). Uma SA uma conexo unidirecional, de forma e a que caso se deseje conexo segura em ambos os sentidos, sero necessrias duas a a a SAs. Para o estabelecimento de chaves, o IPSec utiliza um procolo chamado IKE (Internet Key Exchange). O IPSec baseado na adio de cabealhos adicionais que podem ser de dois e ca c tipos. O primeiro delese o AH (Authentication Header ), enquanto o segundo e o ESP (Encapsulation Security Payload ). e
O cabealho AH capaz de prover autenticao e checagem de integridade c e ca dos dados por meio do campo HMAC (Hashed Message Authentication Code). Esse campo contm um hash da mensagem criptografado com a chave estabelee cida na criao da conexo. Nesse modo de operao, o IPSec no capaz de ca a ca a e oferecer condencialidade, j que os dados em si no so criptografados. a a a No modo ESP os dados so cifrados garantindo-se tambm a condenciala e idade na comunicao. A integridade e a autenticao dos dados so obtidos ca ca a com o campo HMAC, que tambm est presente no cabealho ESP. Com o ESP e a c poss e vel operar de duas formas que so conhecidas como modo transporte a e modo tunel. No modo transporte, o cabealho original do pacote IP no c a e
400
criptografado, e utilizado para rote-lo ao longo do caminho. J no modo e a a tunel, o pacote IP inteiro criptografado e inserido dentro de um novo pacote e IP juntamente com o cabealho ESP. O modo tnel utilizado, por exemplo, c u e para implementar VPNs seguras usando IPSec. Os modos de operao do IPSec de acordo com o protocolo de extenso ca a utilizado podem ser vistos na gura 50.1.
Figura 50.1: Modos de operao do IPSec ca
50.3
Virtual Private Network (VPN)
A idia de utilizar uma rede pblica como a Internet em vez de linhas prie u vativas para implementar redes corporativas denominada de Virtual Private e Network (VPN) ou Rede Privada Virtual. As VPNs so tneis de criptograa a u entre pontos autorizados, criados atravs da Internet ou outras redes pblicas e u e/ou privadas para transferncia de informaes, de modo seguro, entre redes e co corporativas ou usurios remotos. a A segurana a primeira e mais importante funo da VPN. Uma vez que c e ca dados privados sero transmitidos pela Internet, que um meio de transmisso a e a inseguro, eles devem ser protegidos de forma a no permitir que sejam modia cados ou interceptados. Outro servio oferecido pelas VPNs a conexo entre corporaes (Exc e a co tranets) atravs da Internet, alm de possibilitar conexes dial-up criptografadas e e o que podem ser muito uteis para usurios mveis ou remotos, bem como liais a o distantes de uma empresa. Uma das grandes vantagens decorrentes do uso das VPNs a reduo de e ca custos com comunicaes corporativas, pois elimina a necessidade de links dedco icados de longa distncia que podem ser substitu a dos pela Internet. As LANs podem, atravs de links dedicados ou discados, conectar-se a algum provedor e de acesso local e interligar-se a outras LANs, possibilitando o uxo de dados atravs da Internet. Esta soluo pode ser bastante interessante sob o ponto de e ca vista econmico, sobretudo nos casos em que enlaces internacionais ou nacionais o de longa distncia esto envolvidos. Outro fator que simplica a operacionala a izao da WAN que a conexo LAN-Internet-LAN ca parcialmente a cargo ca e a dos provedores de acesso.
401
Abaixo, so apresentadas as trs aplicaes ditas mais importantes para as a e co VPNs. ACESSO REMOTO VIA INTERNET CONEXAO DE LANS VIA INTERNET CONEXAO DE COMPUTADORES NUMA INTRANET No desenvolvimento de solues de rede, bastante desejvel que sejam co e a implementadas facilidades de controle de acesso a informaes e a recursos corco porativos. A VPN deve dispor de recursos para permitir o acesso de clientes remotos autorizados aos recursos da LAN corporativa, viabilizar a interconexo a de LANs de forma a possibilitar o acesso de liais, compartilhando recursos e informaes e, nalmente, assegurar privacidade e integridade de dados ao atravco essar a Internet bem como a prpria rede corporativa. A seguir so enumeradas o a caracter sticas m nimas desejveis numa VPN: a Autenticao de Usurios: Vericao da identidade do usurio, restringindo ca a ca a o acesso `s pessoas autorizadas. Deve dispor de mecanismos de auditoria, a provendo informaes referentes aos acessos efetuados - quem acessou, o qu co e e quando foi acessado. Gerenciamento de Endereo: O endereo do cliente na sua rede privada no c c a deve ser divulgado, devendo-se adotar endereos ct c cios para o trfego externo. a Criptograa de Dados: Os dados devem trafegar na rede pblica ou privada u num formato cifrado e, caso sejam interceptados por usurios no autorizaa a dos, no devero ser decodicados, garantindo a privacidade da informao. a a ca O reconhecimento do contedo das mensagens deve ser exclusivo dos usurios u a autorizados. Gerenciamento de Chaves: O uso de chaves que garantem a segurana das c mensagens criptografadas deve funcionar como um segredo compartilhado exclusivamente entre as partes envolvidas. O gerenciamento de chaves deve garantir a troca peridica das mesmas, visando manter a comunicao de forma segura. o ca Suporte a Mltiplos Protocolos: Com a diversidade de protocolos existentes, u torna-se bastante desejvel que uma VPN suporte protocolos padro de fato a a usadas nas redes pblicas, tais como IP (Internet Protocol), IPX (Internetwork u Packet Exchange), etc. As redes virtuais privadas baseiam-se na tecnologia de tunelamento cuja existncia anterior `s VPNs. Ele pode ser denido como processo de encapsular e e a um protocolo dentro de outro. O uso do tunelamento nas VPNs incorpora um novo componente a esta tcnica: antes de encapsular o pacote que ser e a transportado, este criptografado de forma a car ileg caso seja interceptado e vel durante o seu transporte. O pacote criptografado e encapsulado viaja atravs e da Internet at alcanar seu destino onde desencapsulado e decriptografado, e c e retornando ao seu formato original. Uma caracter stica importante que pacotes e 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 cabealho adicional c que contm informaes de roteamento que permitem a travessia dos pacotes e co ao longo da rede intermediria. Os pacotes encapsulados so roteados entre as a a extremidades do tnel na rede intermediria. Tnel a denominao do camu a u e ca inho lgico percorrido pelo pacote ao longo da rede intermediria Aps alcanar o a o c 402
o seu destino na rede intermediria, o pacote desencapsulado e encaminhado a e ao seu destino nal. A rede intermediria por onde o pacote trafegar pode ser a a qualquer rede pblica ou privada. u Note que o processo de tunelamento envolve encapsulamento, transmisso a ao longo da rede intermediria e desencapsulamento do pacote. a Para se estabelecer um tnel necessrio que as suas extremidades utilizem u e a o mesmo protocolo de tunelamento. O tunelamento pode ocorrer na camada 2 ou 3 (respectivamente enlace e rede) do modelo de referncia OSI (Open Systems Interconnection). e Tunelamento em N 2 - Enlace - (PPP sobre IP): O objetivo transportar vel e protocolos de n 3, tais como o IP e IPX na Internet. Os protocolos utilizam vel 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 trfego IP, IPX e NetBEUI sejam criptografados e encapsulados para a serem enviados atravs de redes IP privadas ou pblicas como a Intere u net. L2TP (Layer 2 Tunneling Protocol) da IETF (Internet Engineering Task Force) permite que o trfego IP, IPX e NetBEUI sejam criptografados e a enviados atravs de canais de comunicao de datagrama ponto a ponto e ca tais como IP, X25, Frame Relay ou ATM. L2F (Layer 2 Forwarding) da Cisco utilizada para VPNs discadas. e Tunelamento em N 3 - Rede - (IP sobre IP): Encapsulam pacotes IP com vel um cabealho adicional deste mesmo protocolo antes de envi-los atravs da c a e rede. O IP Security Tunnel Mode (IPSec) da IETF permite que pacotes IP sejam criptografados e encapsulados com cabealho adicional deste mesmo protocolo c para serem transportados numa rede IP pblica ou privada. O IPSec um u e protocolo desenvolvido para IPv6, devendo, no futuro, se constituir como padro a para todas as formas de VPN caso o IPv6 venha de fato substituir o IPv4. O IPSec sofreu adaptaes possibilitando, tambm, a sua utilizao com o IPv4. co e ca
50.4
Filtragem de Pacotes e Firewalls
Filtragem de pacotes o bloqueio ou liberao da passagem de pacotes de dados e ca de maneira seletiva, conforme eles atravessam a interface de rede. Em sistemas Linux, por exemplo, a ltragem de pacotes implementada diretamente no kere nel. Esses ltros inspecionam os pacotes com base nos cabealhos de transporte, c rede ou at mesmo enlace. Os critrios mais utilizados so os endereos IP e e e a c portas TCP/UDP de origem e destino. Alguns ltros de pacotes tambm so capazes de transformar o contedo dos e a u pacotes, como o caso do netlter do Linux. Normalmente `s pessoas se referem e a ao ltro de pacotes do Linux pelo nome de iptables. Na verdade, o iptables e uma utilitrio de linha de comando a partir do qual podem ser conguradas as a
403
regras de ltragem do netlter. O netlter formado por um conjunto de cadeias. Cada cadeia um ponto e e no caminho que um pacote IP percorre ao entrar ou sair de uma mquina. A a gura 50.2 mostra as cadeias do netlter.
Figura 50.2: Estrutura do netlter A cadeia PREROUTING est ligada ` entrada de pacotes na mquina. a a a Aps a deciso de roteamento, os pacotes que no so destinados ` mquina o a a a a a local atravessam a cadeia FORWARD e nalmente saem da mquina passando a pela cadeia POSTROUTING. A cadeia INPUT atravessada pelos pacotes que e chegam com destino ` mquina local, enquanto que a cadeia OUTPUT utia a e lizada pelos pacotes originados localmente. Para ltrar ou transformar pacotes IP, o netlter possui estruturas chamadas tabelas. Cada tabela possui regras, que por sua vez se fazem referncia a uma e cadeia. As tabelas padro do netlter mais utilizadas so a lter, para implea a mentao de um rewall, e a tabela nat, utilizada para fazer NAT. ca As regras podem ser criadas pelo administrador de acordo com o que deseja implementar, por exemplo, um rewall ou NAT. Cada regra especica um padro ou critrio a ser comparado com os pacotes e um alvo. Um alvo uma a e e ao pr-denida a ser tomada quando um pacote casa com a regra. Os alvos ca e mais comuns so: a 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 mquina local. Utilizado para implementao de NAT. a ca Um rewall pode ser congurado seguindo uma postura permissiva ou restritiva. Uma congurao permissiva permite tudo o que no for exeplicitamente ca a negado, enquanto uma congurao restritiva nega tudo o que no for exmplicica a tamente permitido. A postura padro de um rewall conhecida como policy. A a e seguir so mostrados alguns exemplos de regras de rewall utilizando a sintaxe a 404
do iptables.
50.4.1
Regras iptables - Exemplo 1
1. Pela interface ppp0, permitido o trfego de entrada com origem 172.16.100.200 e a 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, permitido o trfego de sa com origem 192.168.130.0/24 e a da 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, trfego de entrada, negada toda e qualquer outra a e origem e outro destino. Loga este bloqueio. iptables -i ppp0 -A FORWARD -j DROP --log
4. Pela interface ppp0, trfego de sa a da, negada toda e qualquer outra e origem e outro destino. Loga este bloqueio. iptables -o ppp0 -A FORWARD -j DROP --log
50.4.2
Regras iptables - Exemplo 2
1. Pela interface ppp0, permite a sa de pacotes com destino a porta da 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 regra anterior, desde que os pacotes no tenham o ag SYN setado. a Isso signica dizer que no poss a e vel iniciar que um host externo inicie o processos de abertura de conexo TCP com hosts da rede a 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
3. Pela interface ppp0, trfego de entrada, negada toda e qualquer a e outra origem e outro destino. Loga este bloqueio. iptables -i ppp0 -A FORWARD -j DROP --log 4. Pela interface ppp0, trfego de sa negada toda e qualquer outra a da, e origem e outro destino. Loga este bloqueio. iptables -o ppp0 -A FORWARD -j DROP --log
50.4.3
Firewall Stateful
Um rewall de ltro de pacotes dito um rewall sem estado. Isso porque ele e trata cada um dos pacotes que atravessam a interface de forma independente. Na segunda sequncia de regras, por exemplo, foram necessrias duas regras e a 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 conexo TCP, sempre existe uxo de dados a em ambos os sentidos entre origem e destino. As conexes TCP so caracterizadas por uma srie de atributos como IPs o a e de origem e destino, portas de origem de destino, nmeros de sequncia etc. Em u e conjunto, esses atributos determinam o estado de uma conexo TCP. a Ao contrrio dos rewalls de ltro de pacotes, um rewal stateful no ltra a a pacotes de forma isolada, mas sim com base em informaes sobre o estado co de conexes pr-estabelecidas. Para um rewall stateful, a comunicao bidio e ca recional impl e cita, de forma que no h necessidade de se escrever regras de a a ltragem para cada um dos sentidos. A seguir so mostrados alguns exemplos a de ragras para um rewall stateful utilizando a sintaxe do iptables. 1. Permite abertura de conexes TCP com origem na rede 10.0.0.0/24 e porta o acima de 1023 para qualquer outro host na porta TCP 80. O detalhe e que, alm de controlar quem tem o direito de abertura da conexo, a regra e a tambm cuida de todos os pacotes trocados em ambos os sentidos at o e e m conexo. a
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 necessrio uma outra regra para permitir o controle do a uxo de pacotes em ambos os sentidos. A regra a seguinte: e iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT Essa regra aceita os pacotes que atravessam a cadeia FORWARD desde que eles pertenam a alguma conexo TCP que esteja no estado ESTABc a LISHED ou RELATED. No entanto, essa regra vlida para todos os e a 406
pacotes que atravessam a cadeia FORWARD, e no somente para os paa cotes denidos na regra 1. Alguns rewalls so capazes de implementar o conceito de estados para coa municaes baseadas em UDP. Geralmente, isso alcanado utilizando-se co e c um temporizador. Dessa forma, os pacotes UDP trasmitidos em ambos os sentidos entre uma origem e um destino so tratados como uma conexo a a pelo per odo de tempo denido pelo timeout.
50.4.4
Application Gateway
Embora os rewalls de ltro de pacotes e statefull apresentem uma diferenas c em como pacotes de uma determinada conexo so tratados, ambos se baseiam a a fundamentalmente nas informaes do cabealho dos protocolos da camada de co c transporte. Um application gateway um rewall stateful capaz de inspecionar os dados e da camada de aplicao para tomar decises mais inteligentes sobre a conexo. ca o a Exemplos de controles realizados por um application gateway so autenticao, a ca ltros de URL e ltros de contedo. u Um application gateway pode ser utilizado para bloquear, por exemplo, aplicaes peer to peer (eMule, Kaaza etc.), ou mensageiros instantneos (IRC, co a MSN etc.) que tentam se esconder debaixo do protocolo HTTP. No entanto, os application gateway no so capazes de inspecionar dados criptografados via a a SSL, por exemplo.
50.4.5
Arquitetura de rewall e DMZ
A arquitetura de implementao do rewall tambm um fator de anlise imca e e a portante. Por arquitetura de implementao entende-se a posio relativa que ca ca o rewall possui em relao as redes protegidas, aos recursos de conexo e `s ca ` a a redes externas. A anlise da arquitetura de implementao de rewalls traz os conceito de a ca Bastion Host e DMZ, que precisam ser explicados: Bastion Hosts so servidores a cuidadosamente implementados e de alta segurana que mantm contato com a c e rede externa, conseqentemente estando expostos aos riscos de ataques. DMZs u so reas intermedirias entre a rede interna e externa onde os servidores que a a a recebem trfego externo esto hospedados de maneira separada da rede interna a a de uma corporao. ca a) Dual Homed Host - so Bastion hosts nos quais o rewall implementado, a e expondo sua interface externa e desativando o roteamento entre as interfaces externas e as interfaces internas. Assim, conexes externas chegariam at o o e Bastion host apenas, e conexes internas teriam que obrigatoriamente passar o pelo Bastion Host. Como mostra a gura abaixo, entre a internet e um Dual Homed host, poderia ser implementado um conjunto de ltros de pacotes, no roteador mais prximo, por exemplo, para diminuir as possibilidades de ataques, o
407
diminuindo a necessidade de ltros de pacotes no prprio bastion host. Esta aro quitetura gera um ponto focal na rede, com vantagens e desvantagens: O trfego a centralizado permite uma administrao focalizada em um unico host, porm o ca e excesso de trfego em um unico host pode causar condies de concorrncia e a co e caso o bastion host seja tomado por um invasor, toda a rede estar vulnervel a a a ` ataques.
Figura 50.3: Arquitetura Dual Homed Host b) Screened Host - conforme a gura abaixo, essa arquitetura apresenta uma conexo externa com ligao apenas a um host interno, que um bastion host. a ca e Este host estaria conectado ` rede interna, e no entre as redes, e o rewall teria a a que ser implementado no roteador, pormhaveria pacotes externos entrando na e rede local. Apesar de ser aparentemente menos segurodo que os dual homed hosts, este tipo de arquitetura permite o acesso aos servios do bastion host c sem causar condies de concorrncia na rede, uma vez que todo o trabalho de co e ltragem e anlise de trfego ocorre no roteador. a a
Figura 50.4: Arquitetura Screened Host c) Screened Subnet - adicionam mais uma camada ` segurana de redes a c atravs da utilizao de DMZ para hospedagem dos bastion hosts e de um e ca rewall adicional que separa a rede interna da DMZ. Em uma screened subnet 408
um rewall separa a rede externa da DMZ que hospeda os servios que podem c ser acessados pela rede externa, como por exemplo, um servidor de correio corporativo. Dentro da DMZ est tambm o bastion host que contm o rewall a e e que d acesso da rede interna ` DMZ e roteia as requisies da rede interna a a co para o roteador da DMZ. Esta arquitetura de screened subnets permite maior segurana a uma rede, uma vez que as tentativas de invaso sero efetuadas c a a contra bastion hosts que no possuem acesso ` rede interna, e que o bastion a a host de sa da rede protegido por ltros de entrada no roteador externo. da e
50.5
Sistemas de Deteco de Intruso (IDS) ca a
Deteco de intruso uma tentativa de monitorar estaes ou uxos de rede ca a e co com o intuito de descobrir aes de intrusos. Mais especicamente, um SDI co tenta detectar ataques ou usos imprprios e alerta o responsvel pela rede do o a acontecimento. O funcionamento anlogo ao de um sistema de deteco de e a ca ladres, usado em casas para se proteger de eventuais incidentes. O sistema o domiciliar inicialmente precisa ser congurado e ter especicado o que monitorar (janelas, portas, movimento) e para quem alertar ou chamar em caso de uma invaso (pol a cia, donos da casa). No sistema computacional, tambm precisamos e determinar se queremos monitorar uxos de rede, processos internos de uma estao ou servidor, ou ainda um sistema de arquivos, por exemplo. E devemos ca deixar claro para quem enviar os alarmes ou relatrios e como estes devem ser o 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 estao de trabalho e alertando os responsveis. ca a Porm, alguns sistemas possuem a habilidade de reagir `s invases, deixando e a o de ser um sistema exclusivamente de deteco e pode ser denido como um ca Sistema de Preveno de Intruso (IPS). Exemplos de reaes podem ser um ca a co fechamento de conexo, um bloqueio no rewall, execuo de algum arquivo, ou a ca ainda a desabilitao de uma conta. ca Os sistemas de deteco de intruso servem, como j foi dito, para indicar ca a a que alguma tentativa de intruso foi feita no sistema. Para isso, existem dois a tipos diferentes de deteco que podem ser empregados, os baseados na rede ca e os baseados na estao. Cada um tem uma maneira distinta de abordar ca o problema e o modo como isso feito traz vantagens e desvantagens para e cada tipo. Resumidamente, podemos dizer que os sistemas baseados na estao ca monitoram dados em uma determinada mquina, sejam eles processos, sistemas a de arquivos e o uso de CPU, por exemplo; enquanto que os sistemas baseados na rede observam todos os dados trocados entre estaes. co
50.6
50.6.1
Segurana em Redes Wireless 802.11 c

WEP
Desde sua primeira verso, o padro IEEE 802.11 tentou oferecer um mecanismo a a de segurana Esse mecanismo chamado WEP (Wired Equivalent Privacy) e c e se baseia em criptograa de chave simtrica. O proceso de autenticao entre e ca um host sem o e um ponto de acesso (AP) funciona da seguinte maneira. O host solicita autenticao ao AP, que por sua vez envia um nonce de 128 bits ao ca 409
host. O host cifra o nonce com uma chave simtrica pr-compartilhada e envia e e de volta ao AP, que decifra o nonce e autentica o host. A partir da o host , pode iniciar a transmisso dos dados de fato. a No entanto, o WEP no prev nenhum mecanismo de distribuio de chaves a e ca e no possui autenticao individual. Isso signica dizer que todos os hosts sem a ca o utilizam a mesma chave simtrica para se autenticar no AP. Alm disso, o e e processo de cifragem WEP 802.11 ainda apresenta outras falhas graves. No WEP, cada um dos frames tansmitidos criptografado com o algor e timo RC4, que utiliza uma chave de 64 bits para gerar um uxo de chaves de tamanho IV 1 byte (Ki ). Cada chave do uxo gerado utilizada para cifrar um byte de um e frame enviado fazendo um XOR. A gerao do uxo de chaves determin ca e stica, ou seja, uma chave de 64 bits sempre gera a mesma sequncia de chaves de um e byte. Como foi dito, os hosts sem o e o AP possuem uma chave pr-compartilhada. e Essa chave possui comprimento de 40 bits. Os outros 24 bits necessrios para a formar a chave de 64 bits do RC4 so gerados dinamicamente a cada frame a trasmitido. Esses 24 bits so chamados vetor de inicializao (IV). O IV a ca e transmitido em texto aberto no mesmo frame que carrega os dados cifrados. Alm disse, os IVs eventualmente precisam ser reutilizados, j que seu range e a e de apenas 224 . Dessa forma, ao detectar a reutilizao um IV, o atacante pode ca fazer com que um transmissor cifre os dados conhecidos. Ao receber os dados IV cifrados, o atacante poder calcular a sequncia Ki . Da prxima vez que IV a e o for reutilizado, o atacante poder decifrar os dados utilizando a sequncia. a e
50.7
802.11i
O padro 802.11i, tambm conhecido como WAP, prope mecanismos de segua e o rana para redes 802.11 mais avanados que o WEP. O WAP prev formas de c c e cifragem mais fortes, autenticao individual, e a utilizao de um servidor de ca ca autenticao (AS) separado do AP. O processo de asociao entre uma estao ca ca ca cliente (STA) e um AP no padro 802.11i segue as seguintes etapas: a 1. Descoberta das capacitaes de segurana entre o STA e AP; co c
2. STA e AS se autenticam mutuamente. Juntos geram chave mestra (MK). O AP serve como passagem, permitindo a passagem de pacotes espec cos; 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 conhecem a mesma , a chave PMK; 4. STA e AP derivam uma nova chave temporria TK (Temporal Key) a a partir de PMK. A chave TK ser utilizada para cifragem e integridade a das mensagens. Por ser formado por 4 etapas principais, o processo de autenticao denido ca no padro 802.11i conhecido como four-way handshake. a e
410
Parte IX
Alta Disponibilidade
411
Cap tulo 51
Solues de co Armazenamento RAID, SAN e NAS

51.1 RAID
Tal como em diversas outras reas, quando no poss aumentar o desema a e vel penho de um componente, uma soluo poss ca vel passa pelo uso de mltiplos u componentes em paralelo. No caso do armazenamento, isto leva ao desenvolvimento de conjuntos de discos que operam independentemente e em paralelo. Com vrios discos, pedidos de I/O podem ser tratados em paralelo, desde que a os dados residam em discos separados. Do mesmo modo, um unico pedido de I/O pode ser tratado de igual modo em paralelo caso os dados se encontrem distribu dos ao longo de diversos discos. Com o uso de vrios discos, torna-se claro que existem muitos modos de a organizar os dados e nos quais a redundncia pode ser adicionada para aumentar a a conabilidade. O esquema RAID (Redundant Array of Independent Disks) puro consiste em 7 n veis (de zero a seis). No h qualquer relao hierrquica a a ca a entre eles, mas cada um deles designa arquiteturas distintas que partilham 3 caracter sticas diferentes. O conjunto dos discos f sicos em RAID visto pelo sistema operacional e como sendo um unico drive lgica o Os dados so distribu a dos pelos drives f sicos de um array. Redundncia de capacidade usada para armazenar informao de paria e ca dade, que garante a recuperao dos dados no caso de uma falha num ca disco.
51.1.1
RAID 0
Este n RAID refere-se a um array de discos onde os dados esto divididos em vel a faixas, mas no existe nenhuma redundncia para tolerncia a falhas. Sempre a a a que a performance e a capacidade forem a preocupao principal e o baixo ca 412
custo for mais importante que a conabilidade adicional, esta uma opo a e ca considerar. A gura 51.1 exemplica o tipo de estrutura existente num sistema deste tipo.
Figura 51.1: RAID 0 Os dados so subdivididos em segmentos consecutivos (stripes) que so esa a critos seqencialmente atravs de cada um dos discos de um array. Cada segu e mento tem um tamanho denido 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 aplicao que utilizar o array. ca a Em um ambiente com uso intensivo de E/S ou em um ambiente de banco de dados onde mltiplas requisies concorrentes so feitas para pequenos u co a registros de dados, um segmento de tamanho grande preferencial. Se o e tamanho de segmento para um disco grande o suciente para conter um e registro inteiro, os discos do arranjo podem responder independentemente para as requisies simultneas de dados. co a Em um ambiente onde grandes registros de dados so armazenados, sega mentos de pequeno tamanho so mais apropriados. Se um determinado a registro de dados extende-se atravs de vrios discos do arranjo, o contedo e a u do registro pode ser lido em paralelo, aumentando o desempenho total do sistema. Na verdade, a distribuio dos dados nos drives no completamente unica a e forme. Os arquivos so divididos em fragmentos de tamanho congurvel (chunk a a size, ou stripe size). Assim, se est sendo usado 3 HDs em RAID 0, utilizando a fragmentos de 32 KB, por exemplo, ao gravar um arquivo de 80 KB ter amos fragmentos de 32 KB gravados nos dois primeiros HDs e os 16 KB nais seriam gravados no terceiro, sendo que os 16 KB que sobraramno terceiro HD cariam como espao desperdiado. c c Arranjos RAID-0 podem oferecer alta performance de escrita se comparados a verdadeiros n veis de RAID por no apresentarem sobrecarga associada com a clculos de paridade ou com tcnicas de recuperao de dados. Esta mesma a e ca falta de previso para reconstruo de dados perdidos indica que esse tipo de a ca arranjo deve ser restrito ao armazenamento de dados no cr a ticos e combinado com ecientes programas de backup. Entretanto, cabe ressaltar alguns pontos negativos desta implementao no ca que tange conabilidade e desempenho. RAID 0 no ter o desempenho desejado a a com sistemas operacionais que no oferecem suporte de busca combinada de a setores. Os resultados sero corretos, porm no haver paralelismo e nenhum a e a a ganho de desempenho. Outra desvantagem desta organizao que a conana ca e c se torna potencialmente pior. Um disco SLED com um tempo mdio de vida de e 20.000 horas ser 4 vezes mais seguro do que 4 discos funcionando em paralelo a 413
com RAID 0 (Admitindo-se que a capacidade de armazenamento somada dos quatro discos for igual ao do disco SLED). Como no existe redundncia, no a a a h muita conabilidade neste tipo de organizao. Por m, RAID 0 um nome a ca e at certo ponto equivocado, pois no h redundncia, ele no se encontra na e a a a a taxonomia original de n veis de RAID, e a aplicao de faixas anterior ao ca e RAID.
51.1.2
RAID 1
Esse esquema tradicional para tolerncia a falhas de disco, chamado espela hamento (mirroring) ou sombreamento, utiliza o dobro da quantidade de discos do RAID 0. Formalmente, para esta implementao so necessrios no m ca a a nimo dois discos. O funcionamento deste n simples: todos os dados so gravados vel e a em dois discos diferentes; se um disco falhar ou for removido, os dados preservados no outro disco permitem a no descontinuidade da operao do sistema. a ca A gura 51.2 apresenta este esquema.
Figura 51.2: RAID 1 Apesar de muitas implementaes de RAID 1 envolverem dois grupos de co dados (da o termo espelho ou mirror), trs ou mais grupos podem ser criados e se a alta conabilidade for desejada. O RAID 1 o que oferece maior segurana, e c pois toda informao guardada simultaneamente em dois ou mais discos. Se ca e ocorrer uma falha num dos discos do array, o sistema pode continuar a trabalhar sem interrupes, utilizando o disco que cou operacional. Os dados ento so co a a reconstru dos num disco de reposio (spare disk) usando dados do(s) disco(s) ca sobrevivente(s). O processo de reconstruo do espelho tem algum impacto ca sobre o desempenho de I/O do array, pois todos os dados tero de ser lidos e a copiados do(s) disco(s) intacto(s) para o disco de reposio. ca Alguns pontos em relao ao desempenho deste tipo de esquema so descritos ca a abaixo: Um pedido de leitura pode ser satisfeito por qualquer um dos dois discos que contenha os dados em questo, podendo ser escolhido o que implicar a um tempo menor de procura e latncia de rotao. e ca Um pedido de escrita requer uma atualizao em ambos os discos, mas isto ca pode ser feito em paralelo. Deste modo, a performance de escrita ditada e pela mais lenta das duas faixas f sicas. Em outros n veis RAID em que so utilizados outros esquemas de redundncia, quando uma unica faixa a a atualizada necessrio calcular e atualizar bits de paridade provocando e e a um aumento no tempo necessrio para fazer uma escrita no disco. Em a RAID 1, este write penalty inexistente. e A recuperao de uma falha simples. Quando ocorre uma falha num dos ca e discos, sempre poss aceder aos dados utilizando o outro disco. e vel
414
Conectando os discos primrios e os discos espelhados em controladoras a separadas, pode-se aumentar a tolerncia a falhas pela eliminao da cona ca troladora como ponto unico de falha. Num ambiente de transaes, RAID 1 consegue satisfazer altas taxas de co 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 frao substancial dos pedidos forem escritas, pode no haver superioridade de ca a desempenho relativamente a RAID 0. Entre os no-h a bridos, este n tem o maior custo de armazenamento, pois vel sero utilizados dois discos para a mesma informao. Este n adapta-se mela ca vel hor em pequenas bases de dados ou sistemas de pequena escala que necessitem conabilidade.
51.1.3
RAID 2
Raramente so usados, e em algum momento caram obsoletos pelas novas a tecnologias de disco. RAID-2 similar ao RAID-4, mas armazena informao e ca ECC (error correcting code), que a informao de controle de erros, no lugar da e ca paridade. Isto ofereceu pequena proteo adicional, visto que todas as unidades ca de disco mais novas incorporaram ECC internamente. RAID 2 pode oferecer maior consistncia dos dados se houver queda de energia durante a escrita. e Baterias de segurana e um desligamento correto, porm, podem oferecer os c e mesmos benef cios. As guras 51.3 e 51.4 ilustram o esquema RAID 2 bem como a forma em que as operaes de leitura e escrita so realizadas. co a
Figura 51.3: RAID 2
Figura 51.4: Operaes de leitura e escrita em RAID 2 co Em RAID 2 o ECC calculado sobre os bits em posies anlogas em cada e co a disco. Os bits do cdigo so armazenados nas posies correspondentes em o a co mltiplos discos de paridade. Normalmente utilizado o cdigo de Hamming u e o 415
que torna poss a correo de erros de um bit e a deteco de erros de dois vel ca ca bits. Apesar de requerer menos discos que RAID 1 ainda bastante caro. O e nmero de discos redundantes proporcional ao logaritmo do nmero de discos u e u de dados. Numa leitura unica, todos os discos so acessados simultaneamente. Os a dados e o cdigo corretor associado so entregues ao controlador do array. Se o a existir um erro de um s bit, o controlador consegue reconhecer e corrigi-lo o instantaneamente. Do mesmo modo, numa escrita, todos os discos de dados e paridade devem ser acessados. Esta pode ser uma opo em ambientes em que existe uma alta probabilidade ca de ocorrncia de erros. No entanto, dada a alta conabilidade dos discos atuais, e normalmente no se implementa este esquema RAID. a
51.1.4
RAID 3
Assim como RAID 2, raramente so usados, e semelhante ao RAID 4, exceto a e por usar o menor tamanho poss vel para a stripe. Como resultado, qualquer pedido de leitura invocar todos os discos, tornando a execuo de requisies a ca co diferentes em paralelo dif ceis ou imposs veis. A m de evitar o atraso devido a latncia rotacional, o RAID-3 exige que todos os eixos das unidades de disco e estejam sincronizados. A maioria das unidades de disco mais recentes no posa suem a habilidade de sincronizao do eixo, ou se so capazes disto, faltam os ca a conectores necessrios, cabos e documentao do fabricante. a ca
Figura 51.5: RAID 3
Figura 51.6: Operaes de leitura e escrita em RAID 3 co Outra diferena em relao ao RAID 2 que RAID 3 requer apenas um disco c ca e redundante, qualquer que seja o tamanho do array de discos. RAID 3 aplica acesso paralelo, com os dados distribu dos em pequenas faixas. Em vez de um cdigo corretor de erros, um simples bit de paridade calculado o e 416
para o conjunto de bits na mesma posio em todos os discos e armazenado ca no disco redundante referido. De uma forma simplicada, 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 informao restante ter inevitavelmente ca a de ser a informao que falta. Por exemplo, o clculo desta para o n-simo bit ca a e 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 equao obtemos: ca X0 = X3(n) xor X2(n) xor X1(n) (51.2)
Este princ verdadeiro para cada os sistemas RAID de n 3 a 6. Dado pio e vel que os dados se encontram em faixas de tamanho bastante reduzido, em RAID 3 poss atingir altas taxas de transferncia de dados. Qualquer pedido I/O e vel e implicar a transferncia paralela de dados de todos os discos. Este aumento de a e desempenho mais vis e vel em grandes transferncias. Por outro lado, apenas e um pedido de I/O pode ser executado de cada vez, portanto no constituir a a a melhor opo para um ambiente de transaes. ca co
51.1.5
RAID 4
Tal como nos outros sistemas RAID, so usadas faixas, mas no caso das implea mentaes RAID de 4 a 6, estas faixas so relativamente grandes. Em RAID 4, co a uma faixa de paridade calculada bit a bit para faixas correspondentes em cada e disco de dados. Os bits de paridade so armazenados no disco redundante. Ao a contrrio do sistema de RAID 3 que armazena a paridade bit-a-bit, em RAID a 4 a paridade armazenada sob a forma de blocos e associada a um conjunto de e blocos de dados.
Figura 51.7: RAID 4
No RAID 3, todo o acesso era realizado em todos os discos. Entretanto, poss que algumas aplicaes prefeririam acessos menores, permitindo que e vel co ocorressem acessos independentes em paralelo. Essa a nalidade dos n e veis de RAID 4-6. Tendo em vista que as informaes de deteco de erros em cada co ca setor so examinadas nas leituras para vericar se os dados esto corretos, essas a a pequenas leiturasem cada disco podem ocorrer independentemente, desde que o acesso m nimo seja a um unico setor. As gravaes so outra questo. Aparentemente, cada pequena gravao co a a ca exigiria que todos os outros discos fossem acessados para ler o restante das informaes necessrias para recalcular a nova paridade. Uma pequena gravaoexigiria co a ca
417
a leitura dos dados antigos e da paridade antiga, adicionando as novas informaes, e depois a gravaao da nova paridade no disco de paridade e dos co c novos dados no disco de dados. A idia-chave para reduzir essa sobrecarga que a paridade simplesmente e e e um somatrio de informaes; observando quais bits se alteram quando gravao co mos as novas informaes, s precisamos mudar os bits correspondentes no disco co o de paridade. Dessa forma, temos de ler os dados antigos do disco que est sendo a gravado, comparar os dados antigos com os novos para vericar quais bits mudaram, ler a paridade antiga, modicar os bits correspondentes, depois gravar os novos dados e a nova paridade. Desse modo, uma pequena gravao enca volve quatro acessos a dois discos, em vez do acesso a todos os discos. Uma desvantagem do sistema que o disco de paridade deve ser atualizado em cada e gravao; assim ele o gargalo de gravaes (write bottleneck). ca e co Os sistemas RAID dos n veis 4 a 6 fazem uso de uma tcnica de acesso ine dependente. Neste tipo de acesso, cada disco opera independentemente sendo assim poss satisfazer pedidos I/O em paralelo. Por esta razo, arrays deste vel a tipo um arranjo perfeitamente ajustado para ambientes transacionais que ree querem muitas leituras pequenas e simultneas e menos para aplicaes que a co necessitem de altas taxas de transferncia. e
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 informaes co sobre paridade para os dados do array so distribu a das ao longo de todos os discos do array , ao invs de serem armazenadas num disco dedicado, oferecendo e assim mais desempenho que o RAID 4, e, simultaneamente, tolerncia a falhas. a A idia de paridade distribu reduz o gargalo de escrita, pois agora as e da escritas concorrentes nem sempre exigem acesso `s informaes de paridade a co a um mesmo disco dedicado. Contudo, o desempenho de escrita geral ainda sofre por causa do processamento adicional causado pela leitura, reclculo e a atualizao da informao sobre paridade. ca ca
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 so divididos pode ser otimizado para o a array que estiver a ser utilizado. O desempenho geral de um array RAID 5 equivalente ao de um RAID 4, exceto no caso de leituras seqenciais, que e u reduzem a ecincia dos algoritmos de leitura por causa da distribuio das e ca informaes sobre paridade. A informao sobre paridade ao ser distribu ao co ca da longo de todos os discos, havendo a perda de um, reduz a disponibilidade de
418
ambos os dados e da informao sobre paridade, at ` recuperao do disco que ca ea ca falhou. Isto pode causar degradao do desempenho de leitura e de escrita. ca Como em outros arranjos baseados em paridade, a recuperao de dados em ca um arranjo RAID-5 feita calculando a funo XOR das informaes dos discos e ca co restantes do arranjo. Pelo fato de que a informao sobre paridade distribu ca e da ao longo de todos os discos, a perda de qualquer disco reduz a disponibilidade de ambos os dados e informao sobre paridade, at a recuperao do disco ca e ca que falhou. Isto pode causar degradao da performance de leitura e de esca crita. Alm disso, esta estrutura vista como contendo uma limitao cr e e ca tica, o throughput das aplicaes sofre normalmente uma penalizao at cerca de 4x, co ca e comparativamente a arrays no redundantes para pequenas escritas. a
51.1.7
RAID 6 (Redundncia de P+Q) a
Os esquemas baseados em paridade protegem contra uma unica falha auto identicada. Quando uma unica correo de falha no suciente, a paridade ca a e pode ser generalizada para ter um segundo clculo sobre os dados e outro disco a de vericao de informaes. Esse segundo bloco de vericao permite a recuca co ca perao de uma segunda falha. Desse modo, a sobrecarga de armazenamento ca e o dobro do overhead do RAID 5. o atalho de pequena gravao apresentado anca teriormente funciona bem exceto pelo fato de haver agora seis acessos ao disco, em vez de quatro, para atualizar as informaes P e Q. A gura ?? ilustra essa co congurao. ca
Figura 51.9: RAID 6 - Redundncia P+Q a Em RAID 6 so efetuados dois clculos diferentes para a paridade e ara a 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 so dois algoritmos diferentes de vericao de dados. Um dos dois o a ca e clculo por xor j referido e usado em RAID 4 e 5, sendo o outro um algoritmo a a independente. Isto torna poss vel a regenerao de dados mesmo que ocorra ca uma falha em dois dos discos. A grande vantagem desta organizao o fato de providenciar alta disponica e bilidade de dados. Teria de ocorrer um erro em trs dos discos durante o tempo e mdio para reparao para que isso tornasse os dados indispon e ca veis. Por outro lado, subjacente a este sistema est um write penalty substancial, pois cada a escrita afeta obrigatoriamente dois blocos de paridade.
51.1.8
Tipos H bridos
Dadas as limitaes de cada n RAID, diversos criadores de dispositivos de co vel armazenamento tentaram criar novas formas RAID combinando caracter sticas de cada um dos n veis originais.
419
RAID 10: Nesta variedade combina-se o espelhamento existente em RAID 1 com a diviso em faixas do RAID 0. Numa implementao 0+1 os dados a ca so divididos por conjuntos de drives duplicadas. Numa implementao a ca 1+0, os dados so divididos por diversas drives e este array completo a de discos duplicado por um ou mais array de drives. O desempenho na e reposio de dados melhor neste tipo de arrays que em sistemas baseados ca e em paridade, pois os dados no precisam ser regenerados com base nesta, a mas sim simplesmente copiados para a nova drive. RAID 30 e 50: Esta forma consiste em manter a informao dividida ca em faixas ao longo de uma matriz RAID 3 ou 5. Estes h bridos providenciam os mesmos benef cios de arrays acesso paralelo (altas taxas de transferncia) ou as vantagens de arrays de acesso independente baseados e em paridade (alto throughput).
51.1.9
Comparativo de Desempenho entre as diversas conguraes RAID co
51.2
SAN - Storage Area Network
A SAN poderia ser denida como uma rede de alta velocidade, comparada ` a LAN (Local Area Network), que permite o estabelecimento de conexes diretas o entre os dispositivos de armazenamento e processadores (servidores) centralizados ` extenso suportada pela distncia das bras ticas. A SAN pode ser vista a a a o como uma extenso do conceito que permite que os dispositivos de armazenaa 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 denio diz que SAN so dois ou mais dispositivos se comunicando ca a via protocolo serial SCSI, tal como Fibre Channel ou iSCSI. Segundo essa denio, uma LAN que trafega nada mais do que trfego de storage no pode ca a a ser considerada uma SAN. O que diferencia uma LAN de uma SAN (ou de uma NAS) o protocolo que usado. Assim, se o trfego de storage trafega em uma e e a LAN atravs do protocolo iSCSI, ento essa LAN pode ser considerada uma e a SAN. Entretanto, simplesmente enviar dados de backup atravs de uma LAN e dedicada isso no a torna uma SAN. Enm, uma SAN uma rede que usa um a e protocolo serial SCSI para transferir dados. A gura 51.10 abaixo mostra uma viso geral de uma SAN conectando vrios a a servidores a vrios sistemas de armazenamento: a SANs criam novos mtodos de conexo de armazenamento aos servidores. e a Estes novos mtodos prometem uma notvel melhora em performance e disponie a bilidade. SANs so usadas para conectar conjuntos de armazenamento coma partilhados a vrios servidores, e so usadas por servidores em ambiente de a a cluster para fail over. Elas podem interconectar discos ou tas de mainframe a servidores ou clientes de rede e podem criar caminhos paralelos de dados para ambientes de computao e de alta largura de banda. A SAN uma outra rede ca e que difere das redes tradicionais, porque foi concebida a partir de interfaces de armazenamento. Alm disso, a SAN pode ser usada para contornar os conhecidos gargalos de e rede, pois suporta diretamente altas velocidades de transferncia de dados entre e 420
Figura 51.10: Exemplo de SAN os servidores e dispositivos de armazenamento nas seguintes formas: Servidor para storage: o modelo tradicional de interao com os dise ca positivos de armazenamento e cuja vantagem que um mesmo disposie tivo de armazenamento pode ser acessado serial ou concorrentemente por mltiplos servidores; u Servidor para servidor: no qual a SAN pode ser usada para alta velocidade e comunicaes de alto volume entre servidores; co Storage para storage: permite a movimentao dos dados sem interveno ca ca do servidor, liberando o processador para outras atividades. Por exemplo: um disco pode realizar o backup de dados para uma ta sem a interveno ca do servidor ou um espelhamento de dispositivo remoto atravs da SAN. e O uso de SANs gera uma melhora de performance das aplicaes, por exco emplo, permitindo que o dado enviado diretamente do dispositivo de origem ao dispositivo de destino no requeira interveno do servidor. As SANs tambm a ca e habilitam novas arquiteturas de rede nas quais vrios computadores (hosts) acesa sam vrios dispositivos de armazenamento conectados na mesma rede. Conhea a c outros benef cios que o uso da SAN pode oferecer `s empresas: a Mais disponibilidade: armazenamento independente de aplicaes acess co veis atravs de caminhos alternativos de dados; e Alta performance: os dados so descarregados do servidor e movidos para a uma rede independente;
Armazenamento centralizado e consolidado: gerenciamento mais simples, escalabilidade, exibilidade e disponibilidade; Transferncia e armazenamento: cpia remota de dados habilitada para e o proteo contra falhas e desastres; ca Gerenciamento centralizado mais simplicado: a imagem simples do meio de armazenamento simplica o gerenciamento.
51.2.1
Hardware para SAN
Talvez a parte mais importante para a implantao de uma SAN seja referente ca ao hardware. Os principais componentes so: a 421
Servidor de Disco: Servidores de discos, tambm chamados de storages so e a dispositivos que armazenam discos compartilhados pelos hosts da rede. Eles possuem, em geral, diversas reas diferentes, com esquemas de RAID a diferentes ou discos espec cos para a realizao de espelhamentos para ca backup, os chamados BCV (business continuance volumes). Os BCVs facilitam muito tanto o backup quanto a restaurao dos dados. O seu ca contedo sincronizado com o contedo do disco principal, at que se u e u e faa uma quebra do sincronismo, o chamado split. Neste momento, o BCV c guarda uma imagem do disco antes do split, e pode ser usado para backup, enquanto o servidor continua trabalhando, sem impactos na produo. ca Este procedimento pode ser feito com a freqncia mais conveniente para ue o usurio e, em muitos casos, o BCV utilizado tambm para restaurao a e e ca de dados perdidos, que muito mais rpido do que acessar tas de backup. e a Switches bre channel: Switches bre channel so bem mais complexos a que os hubs, tanto em seu projeto quanto em funcionalidade. Enquanto os hubs so apenas um concentrador de cabos para um segmento coma partilhado, um switch um dispositivo de rpido roteamento dos dados e e a possui uma taxa de transferncia de dados exclusiva para cada porta. As e taxas de transferncia variam bastante dependendo do switch, que vm e e evoluindo rapidamente. Atualmente, a velocidade mxima est em 400 a a MB/s para cada porta. Enquanto os hubs no participam de atividades a no n do protocolo Fibre Channel, os switches participam ativamente, vel tanto para fornecer servios quanto para supervisionar o uxo de frames c entre a origem e o destino. HBA (Host Bus Adapter): Uma HBA um dispositivo capaz de conectar e dispositivos externos a um servidor. Por exemplo: para conectarmos um disco SCSI a um micro (barramento interno PCI), ser necessrio utilizar a a uma HBA SCSI-PCI. No caso da SAN, necessrio instalar em todos os e a servidores participantes dela uma HBA Fibre Channel, que se encarregar a de fazer as converses dos diferentes meios internos e externos ao servidor. o As HBAs FC possuem, ainda, uma espcie de processador (um chip) capaz e de fazer a converso de protocolos para poupar a CPU do servidor deste a trabalho.
51.2.2
Topologias de SAN
As SANs atuais so todas constru a das em uma topologia f sica de estrela. Um switch conectado ao storage e neles conectamos todos os outros servidores da e rede. A exceo ca com a ligao ponto-a-ponto, como veremos a seguir. ca ca Ligao ponto-a-ponto (point-to-point) ca Para alguns no considerada uma topologia de SAN, uma vez que no possui a e a escalabilidade alguma. Neste tipo de ligao, os servidores so ligados direca a tamente ao storage, sem nenhum equipamento intermedirio, como switch. O a nmero mximo de servidores envolvidos igual ao nmero de portas que o u a e u storage possui. Comparado com a ligao SCSI, no entanto, esta topologia, ca que utiliza Fibre Channel, apresenta uma performance muito melhor e atinge distncias maiores. a 422
Figura 51.11: SAN ponto a ponto Loops ou anis: Fibre Channel Arbitrated Loop (FC-AL) e Nesta topologia utiliza-se hub, cuja largura de banda de no mximo de 100 MB/s a compartilhada por todos os seus membros. Teoricamente suporta loops com e at 126 dispositivos, mas na prtica este nmero bem menor. Esta topologia e a u e est sendo muito pouco utilizada nas SANs modernas. Algumas pessoas coma param esta topologia como uma rede Token Ring, em que a largura de banda e dividida por todos os dispositivos do loop. Entretanto h equipamentos antigos a que no suportam o modo fabric e, assim, utilizado o modo em loop. a e
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 nmero e dispositivos interconectados. Dedica largura de banda integral a cada u uma das portas e ermite transferncias de dados simultaneamente para um unico e n. E a topologia que permite ais escalabilidade e crescimento. Teoricamente, o pode conter mais de 7,7 milhes de ns. o o
51.3
NAS - Network Attached Stotage
O compartilhamento de arquivos na rede j era poss mesmo antes da chegada a vel do sistema NAS. Isso era poss vel graas aos protocolos NFS (Network File c System) do Unix e CIFS (Common Internet File System) do Windows. Entretanto, ambos possu am limitaes de desempenho e gerenciamento. Alm co e disso, servidores deviam ser dedicados a usar ou NFS ou CIFS. O sucesso do NAS, portanto, foi corrigir algumas limitaes de cada protocolo e permitir que co ambos pudessem operar em um mesmo servidor. Assim, pode-se dizer que NAS 423
Figura 51.13: SAN Switched Fabric (Network attached storage) um computador dedicado a compartilhamento de e arquivos atravs de NFS, CIFS ou DAFS(Direct Access Files). Cabe ressaltar e que um dispositivo dedicado exclusivamente ao compartilhamento de arquivos, e 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 inteligncia de uma pequena unidade de processamento. Nesse sentido, poss e e vel adicionar armazenamento na rede sem ser necessrio desligar o servidor. E coa mum a familiaridade com o conceito de impressora de rede, ou seja, aquela onde o usurio pode imprimir. Do mesmo modo o NAS uma unidade partila e hada atravs da LAN e todos os usurios com os direitos e permisses de acessos e a o adequados podem montar sistemas de arquivos diretamente sem ter que veicular os dados atravs do servidor. Tipicamente, cada interao entre aplicaes e o e ca co NAS envolve a transferncia de um volume de dados relativamente pequeno e e de curta durao. Alm disso o NAS pode estar ligado em qualquer parte da ca e LAN.
51.4
Comparativo entre SAN e NAS
Vistas como concorrentes, as SANs e as so tecnologias complementares. Ena quanto as primeiras so otimizadas para transferncias de altos volumes de daa e dos orientadas em bloco, as NAS oferecem acesso a dados em n de arquivo. vel Baseadas em protocolos abertos, como Fibre Channel e TCP/IP, oferecem varias vantagens em relao ao sistema de armazenamento ligado ao servidor. A seguir ca um resumo das principais diferenas entre cada tecnologia. c Protocolo: SAN: Serial SCSI-3 NAS: TCP/IP, NFS/CIFS Compartilhamento: SAN: Drives de discos e tas NAS: Sistemas de arquivos 424
Permite: SAN: Diferentes servidores acessarem o mesmo drive de disco ou ta de forma transparente para o usurio nal. a NAS: Diferentes usurios acessarem o mesmo sistema de arquivos ou a at um mesmo arquivo. e Substitui: SAN: Os drivers de discos e tas locais, ou seja, drivers conectados diretamente ao servidor. Com SAN, centenas de sistemas podem compartilhar o mesmo drive de disco ou ta. NAS: Servidores Unix NFS e servidores NT CIFS que possibilitavam sistemas de arquivos compartilhados em rede. Aplicaes: co SAN:Processamento de aplicaes de banco de dados de misso critco a ica; Backup de dados centralizado; Operaes de recuperao de deco ca sastres; Consolidaao de armazenamento. c NAS: Compartilhamento de arquivo em NFS e CIFS; Transferncia e de pequenos blocos de dados a longas distncias; Acesso ao banco de a dados limitado somente a leitura. Vantagens: SAN: Alta disponibilidade; Conabilidade na transferncia de dados; e Trafego reduzido na rede primaria; Flexibilidade de congurao; ca Alto desempenho; Alta escalabilidade; Gerenciamento centralizado; Oferta de mltiplos fornecedores. u NAS: Poucas limitaes de distancia; Adio simplicada da capacico ca dade de compartilhamento de arquivo; Fcil instalao e manuteno. a ca ca Muitos poderiam argumentar que SAN mais poderoso que NAS ou que e 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 questes o poderiam dar a entender que sistemas SAN resultam em maior throughput para o cliente que os sistemas NAS. Essa observao verdadeira se consideramos ca e como clientes os grandes servidores, entretanto grande parte das aplicaes so co a menos exigentes sob esse ponto de vista sendo o desempenho oferecido pelo NAS bastante suciente. Enquanto SAN oferece acessos concorrentes em n vel de dispositivos, NAS oferece em n de arquivos e essa uma exigncia de muitas aplicaes. Outra vel e e co vantagem do NAS que ele mais simples de se entender e aprender. Em geral, e e os protocolos e tecnologias que envolvem os sistemas SAN so relativamente a complexos. Alm disso, SAN composto de diversas partes de hardware, que e e so especializados para tal sistema, de diferentes fabricantes. Se o ambiente onde a ser implantado a SAN nunca recebeu um sistema assim, todos os equipamentos a devem ser adquiridos. No caso do NAS isso no acontece, pois o NAS permite a usar a infra-estrutura de rede j presente no ambiente. Enm, o sistema NAS a e mais fcil de se manter que o sistema SAN. Outra conseqncia imediata que a ue e 425
sistemas SAN so mais caros que os NAS. Outro destaque que o NAS permite a e que arquivos sejam replicados automaticamente para outros pontos, tornando mais fcil proteg-los contra falhas. a e Entretanto, NAS tem limitaes tambm. Embora os esquemas de replicao co e ca oferecidos por alguns NAS propiciem excelentes formas de recuperao, caracca ter stica mais dif de ser suportada em SANs, backups tero de serem feitos cil a em tas em algum momento e fazer backup de um arquivo para uma ta pode ser um desao. Uma das razes que fazer um backup completo para ta ir o e a exigir muito mais tarefas de I/O que qualquer outra aplicao. Isso signica que ca fazer backup de um arquivo relativamente grande ir sobrecarregar bastante o a sistema. Nesse sentido, sistemas SANs ainda so mais ecientes. Em complea mento, realizar backup de um determinado arquivo signica que o sistema de arquivo ter que ser atravessado da mesma forma como se um usurio estivesse a a usando-o e isso outro motivo de sobrecarga no sistema. Por m, embora seja e plaus que a maioria das aplicaes no seja limitada pelo throughput de um vel co a sistema de arquivos importante ressaltar que teoricamente um sistema NAS e capaz de transferir mais dados que o NAS. Assim se a aplicao necessitar e ca de grandes transferncias de dados preciso fazer uma avaliao de qual opo e e ca ca melhor se adapta ao perl da aplicao. ca Assim como o NAS possuem vantagens e desvantagens o mesmo ocorre com SAN. A primeira vantagem do SAN em relao ao NAS que o ultimo s capaz ca e oe de atender a requisies em n de arquivos via NFS e CIFS enquanto o SAN co vel capaz de atender requisies de acesso a dispositivos. Alm disso, enquanto e co e alguns vem complexidade no SAN outros vem como exibilidade, ou seja, os e e recursos de sistema de arquivos e gerenciamento de volumes dispon veis no SAN no podem ser oferecidos pelo NAS. Outro ponto diz respeito ao fato que SAN a pode ser mais rpido que NAS, conforma discutido anteriormente. A capacidade a em throughput da SAN possibilita backups em maior escala e recuperao mais ca fcil. Vrias desvantagens da SAN j foram citadas, mas a principais so seu a a a a custo e complexidade.
426
Cap tulo 52
Clusters de servidores
Um cluster um conjunto de mquinas independentes, chamadas ns, que coe a o 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 m de coordenar e organizar todas as aes a serem co tomadas. Deste modo, para um usurio externo, o cluster visto como sendo a e um unico sistema.
Figura 52.1: Cluster de 4 ns o O objetivo desejado em um cluster resume-se em: Alta Disponibilidade, quando se deseja que o cluster fornea determinados c servios, sendo que estes devem estar sempre (ou quase sempre) dispon c veis para receber solicitaes. Esta probabilidade do servio estar apto a receco c ber solicitaes um fator dependente do cluster. co e
Alto Processamento, quando se deseja que o cluster execute determinadas tarefas, sendo que elas so divididas (na sua a ntegra ou em fraes de uma co mesma tarefa) e processadas separadamente em vrios ns, a m de a a o velocidade de processamento seja incrementada. E poss ainda ter uma situao onde o cluster deve atingir os dois objetivos vel ca juntos; `s vezes, por razes de simplicidade, tal objetivo atingido eliminando-se a o e alguns rigores das denies acima. co
52.0.1
Princ pios de um Cluster
Para ser util, um cluster precisa seguir alguns princ pios bsicos: a 427
Comodidade: Os ns em um cluster devem ser mquinas normais intero a conectadas por uma rede genrica. O sistema operacional tambm deve e e ser padro, sendo que o software de gerenciamento deve ir acima dele como a uma aplicao qualquer. ca Escalabilidade: Adicionar aplicaes, ns, perifricos e interconexes de co o e o rede deve ser poss sem interromper a disponibilidade dos servios do vel c cluster. Transparncia: O cluster, que constru com um grupo de ns indepene e do o dentes fracamente agrupados, deve apresentar-se como um unico sistema a clientes externos ao cluster. Aplicaes clientes interagem com o cluster co como se fosse um unico servidor com alta performance e/ou alta disponi bilidade. Conabilidade: o cluster deve ter capacidade de detectar falhas internas ao grupo, assim como de tomar atitudes para que estas no comprometam a os servios oferecidos. c Gerenciamento e Manuteno: Um dos problemas dos clusters sua manuteno ca e ca e congurao, que muitas vezes so tarefas complexas e propensas a gerar ca a erros. Um mecanismo fcil de congurao e manuteno do ambiente a ca ca deve existir a m de que o cluster no seja um grande sistema complexo a com um rduo trabalho de administrao. a ca
52.0.2
Abstraes em um Cluster co
Um cluster possui vrios elementos que, juntos com sua arquitetura, fornecem a a funcionalidade desejada. Uma abstrao dos elementos necessria para se ca e a poder compreender qual o comportamento de cada um deles. N: Como visto anteriormente, o n a unidade bsica do cluster; gruo oe a pos de ns formam um cluster. Em um cluster, um n comunica-se com o o os outros atravs de mensagens sobre conexes de rede, e falhas em ns e o o podem ser detectadas atravs de timeouts de comunicao. Um n um e ca oe sistema computacional unicamente identicado conectado a um ou mais computadores em uma rede. Assim, um n tem quatro componentes prino cipais: CPU;
Memria; o Repositrio de Armazenamento; o Interconexo. a Recurso: Um recurso representa certa funcionalidade oferecida em um n. o Ele pode ser f sico, como por exemplo uma impressora, ou lgico, como por o exemplo um endereo IP. Recursos so a unidade bsica de gerenciamento, c a a e podem migrar de um n a outro. Independentemente se for resultado de o uma falha ou intervenao humana, o processo de migrao de um recurso c ca de um n para outro chamado de failover. Como um recurso representa o e uma funcionalidade, ele pode falhar. Por isso, monitores devem observar 428
o status dos recursos, a m de tomar atitudes desejadas em caso de falha (por exemplo, iniciar o servio em outro n). Um recurso tem associado c o a si um tipo, que descreve seus atributos genricos e seu comportamento. e Cada tipo deve ter associado a si mecanismos de iniciao/parada, a m ca de que possam ser manipulados corretamente pelo gerenciador do cluster. Dizemos que um n p hospeda um recurso r se em determinado momento o o servio associado a r est sendo fornecido a partir de p. c a Dependncias de Recursos: Freqentemente, recursos dependem da disponie u bilidade de outros recursos. Por exemplo, um servidor HTTP depende da presena de uma interface de rede online e de um sistema de arquivos c operacional para fornecer os arquivos. Por outro lado, um sistema de arquivos pode depender de um volume manager. Estas dependncias so e a descritas em um grafo de dependncias de recursos. Este grafo de dee pendncias descreve a seqncia na qual os recursos devem ser iniciados. e ue Ainda, durante uma migrao de recursos ele descreve quais recursos deca vem ser migrados juntos. Grupos de Recursos: Um grupo de recursos a unidade de migrao. e ca Apesar de um grafo de dependncias descrever os recursos que devem ser e migrados juntos, pode haver consideraes adicionais para agrupar recurco sos. O administrador de sistemas pode associar uma coleo de recursos ca independentes em um unico grupo de recursos, a m de garantir que todo o grupo seja migrado junto. Pol ticas de migrao so denidas baseadas ca a em grupos. As dependncias de recursos vistas acima no podem ultrae a passar as barreiras de um grupo, ou seja, recursos de um grupo devem depender somente de recursos contidos em seu prprio grupo. o
52.0.3
Arquitetura de um Cluster
Isoladamente, os elementos descritos acima no provem a funcionalidade dea e sejada do cluster. E necessrio que haja uma arquitetura que una todos os a elementos e fornea o funcionamento que cada um espera do outro. Devido ` c a natureza fracamente agrupada do cluster, uma abstrao ideal de arquitetura ca deve ser baseada em componentes. Tal estrutura seria formada pelas seguintes camadas bsicas: a Camada de Comunicao: trata das comunicaes ponto-a-ponto entre os ca co ns. o
Camada de Ligao: agrupa canais de comunicao em uma unica ligao ca ca ca entre dois ns. o Camada de Integrao: forma a topologia do cluster. ca Camada de Recuperao: executa a recuperao (failover) e a inicialca ca izao/parada controlada de servios depois de uma transio do cluster. ca c ca Existem ainda quatro servios chaves para um cluster: c JDB: armazena estados persistentes internos ao cluster (e usados para o banco de dados do quorum). Nada mais do que um repositrio de e o informaes local a cada n do cluster. co o 429
Camada de Qurum: determina qual partio do cluster possui autoro ca izao para prosseguir com sua execuo. ca ca Servio de Barreiras: prov um servio de sincronizao global ao cluster. c e c ca Servio de Nomes: prov um servio de nomes global ao cluster. c e c
52.0.4
Cluster X Sistemas Distribu dos
Um sistema distribu consiste em um conjunto de processos concorrentes que do cooperam uns com os outros para executar determinada tarefa. Ele formado e por vrios ns, que se utilizam da rede de comunicao para trocarem mena o ca sagens. As mquinas so autnomas, formando um sistema fracamente agrua a o pado, onde no existe memria compartilhada entre diferentes ns. Entre as a o o aplicaes t co picas de um sistema distribu esto servios de arquivos de/para do a c mquinas distribu a das e distribuio de carga de processamento entre diversas ca mquinas. A gura 52.2 ilustra essa organizao. a ca
Figura 52.2: Sistema Distribu do Clusters so uma subclasse de sistemas distribu a dos. Geralmente eles so a grupos de computadores homogneos em menos escala, dedicado a um nmero e u pequeno e bem denido de tarefas, nas quais o cluster atua como uma unica mquina. Entre os usos t a picos de um cluster esto adicionar alta disponibilidade a a servios e aumentar a capacidade de processamento do grupo (fazenda de c servidores). A tabela abaixo enumera as principais diferenas entre cluster e sistemas c distribu dos. Analisando a tabela pode-se concluir que um cluster nada mais e do que um sistema distribu especializado para uma determinada tarefa. do Estrutura: Cluster:homognea - adquirido para realizar determinada tarefa e
Sist. Distribu do: heterognea - montado a partir do hardware dispon e vel. Tarefa: Cluster: especializada - feita para executar um pequeno conjunto de tarefas bem denido. Sist. Distribu do: generalizada - usalmente precisam ser um ambientes de computao genricos ca e Preo: c Cluster: relativamente baixo. 430
Sist. Distribu do: barato / caro. Conabilidade: Cluster: to convel quanto precisa ser. a a Sist. Distribu do: pouco / muito convel. a Segurana: c Cluster: os ns conam uns nos outros. o Sist. Distribu do: os ns no conam uns nos outros. o a
52.0.5
Cluster de Alta Disponibilidade
Pelo fato do termo cluster abranger uma grande quantidade de implementaes, co convencionou-se o uso de termos espec cos para cada tipo de implementao. ca Clusters Beowulf so usados para oferecer escalabilidade e processamento para alelo para execuo de funes computacionais. Solues de clusters de alta ca co co disponibilidade, por sua vez, so usados para fornecer alta disponibilidade para a servios ou aplicaes. Clusters de alta disponibilidade so comumente conhecic co a dos como Failover Cluster. Failover o processo no qual uma mquina assume os servios de outra, e a c quando esta apresenta alguma falha. O failover pode ser automtico ou manual, a sendo o automtico normalmente esperado em uma soluo de alta disponibilia ca dade. Para se executar o failover de um servio, necessrio que as duas mquinas c e a a envolvidas possuam recursos equivalentes. Um recurso pode ser uma placa de rede, um disco r gido, os dados neste disco ou qualquer elemento necessrio a a ` prestao de um determinado servio. E importante que a soluo de alta ca c ca disponibilidade mantenha recursos redundantes com o mesmo estado, de forma que o servio possa ser retomado sem perdas. Para isto, pode-se usar tcnicas c e de espelhamento de disco, replicao de dados ou sistemas de armazenamento ca compartilhados. Ao ser resolvida a falha, o servidor ser recolocado em servio, e ento tem-se a c a a opo de realizar o processo inverso do failover, chamado failback. O failback ca o processo de retorno de um determinado servio de uma outra mquina para e c a sua mquina de origem. Este processo tambm pode ser automtico, manual ou a e a at mesmo indesejado. Em alguns casos, em funo da poss nova interrupo e ca vel ca na prestao de servios, o failback pode no ser atraente. ca c a
Tipos de Clusters de Alta Disponibilidade Existem dois tipos bsicos de clusters de alta disponibilidade, os simtricos e os a e assimtricos. Clusters de alta disponibilidade assimtricos so os mais simples de e e a se implementar. Eles se baseiam no conceito de servidores primrio e secundrio. a a Servidores que esto provendo algum tipo de servio so considerados como a c a primrios. Servidores que aguardam a ocorrncia de alguma falha no servidor a e primrio so denominados servidores secundrios. A deteco da falha ocorre a a a ca atravs do monitoramento dos servidores primrios por parte dos secundrios. e a a A principal diferena entre clusters assimtricos e simtricos que em um c e e e cluster simtrico no h a gura de um servidor inativo aguardando uma falha de e a a 431
Figura 52.3: Cluster de Alta Disponibilidade Assimtrico e outro, primrio, para ento servir a aplicao. Neste modelo, ambos servidores a a ca servem alguma aplicao. Assim, os termos primrio e secundrio deixam de ca a a ser usados para designar o servidor, passando a ser usado para a aplicao. ca De forma semelhante ao que ocorre em clusters assimtricos, na ocorrncia de e e uma falha em um dos servidores, d-se in ao processo de failover. Neste caso, a cio o servidor ainda ativo assume o controle da aplicao do servidor problemtico. ca a Ao contrrio do modelo anterior, neste o monitoramento dever ocorrer entre a a todos os ns. o
Figura 52.4: Cluster de Alta Disponibilidade Simtrico e
Tipos de Armazenamento Dependendo da escala, performance, funcionalidade e exibilidade do cluster, so necessrias diferentes implementaes de armazenamento. Os principais a a co mtodos de armazenamento so o compartilhamento total, sem compartilhamento e a e espelhamento de disco. No compartilhamento total, todos os servidores acessam o mesmo meio de armazenamento. Este modelo apresenta potenciais problemas de corrupo de ca dados quando mais de um servidor est ativo. Para soluo deste problema, a ca caracter sticas de locking so desejadas. Esta implementao bastante comum a ca e em clusters assimtricos. e
Figura 52.5: Cluster com compartilhamento total de armazenamento 432
No armazenamento sem compartilhamento, dois ou mais servidores possuem seu prprio meio de armazenamento. No evento de uma falha em um dos servio dores, o servidor responsvel pela substituio passa a ter acesso total ao meio a ca de armazenamento original do n defeituoso. Esta implementao comum em o ca e clusters simtricos. e
Figura 52.6: Cluster sem compartilhamento de armazenamento Em um ambiente de espelhamento de discos, no h nenhum tipo de coma a partilhamento entre os ns servidores. Atravs do uso de software, os dados o e so espelhados ou replicados de um servidor para o outro atravs da rede. O a e princ pio deste modelo que todos servidores potenciais substitutos devem pose suir seu prprio meio de armazenamento e, ao mesmo tempo, uma rplica do o e armazenamento do servidor a ser substitu do.
Figura 52.7: Cluster sem compartilhamento de armazenamento Em um ambiente de espelhamento de discos, no h nenhum tipo de coma a partilhamento entre os ns servidores. Atravs do uso de software, os dados o e so espelhados ou replicados de um servidor para o outro atravs da rede. O a e princ pio deste modelo que todos servidores potenciais substitutos devem pose suir seu prprio meio de armazenamento e, ao mesmo tempo, uma rplica do o e armazenamento do servidor a ser substitu do.
52.0.6
Cluster de Alto Desempenho
Sistemas de processamento paralelo vm se tornando cada vez mais populares e em funo da demanda por processamento de alto desempenho, exigido pelas ca diversas reas da cincia (ex.: qu a e mica, biologia, meteorologia). Infelizmente, os sistemas que oferecem a capacidade de processamento para satisfazer a essa demanda, representados pelas mquinas de arquiteturas maciamente paralelas a c ou tem um custo elevado, ou so dif a ceis de programar, ou ambos. Em funo ca 433
Figura 52.8: Cluster com espelhamento de dados disso, nos ultimos anos, tm-se investido na pesquisa de mquinas paralelas e a baseadas em clusters de multiprocessadores simtricos por possu e rem um custo relativamente mais baixo que as mquinas de arquitetura maciamente paralelas a c alm de serem mais ex e veis que essas. Atualmente, existem diferentes tipos de arquiteturas dedicadas ` execuo a ca de aplicaes paralelas, sendo que essas podem ser classicadas em trs tipos: co e Arquiteturas maciamente paralelas (MPP): so arquiteturas que possuem c a processadores altamente poderosos e links de comunicao dedicados. Este ca tipo de arquitetura, chamada de supercomputadores ou arquiteturas dedicadas, apresentam um alto custo, devido aos recursos que oferecem. Como exemplo, pode-se citar o Intel Paragon e o IBM SP2. Multiprocessadores simtricos (SMP): so arquiteturas compostas por um e a conjunto de processadores iguais, que se comunicam, geralmente, atravs e de uma mesma memria. termo simtrico signica que todos os proceso e sadores so idnticos em termos de arquitetura interna e poder de procesa e samento. Exemplos dessa arquitetura so os processadores Dual Pentium. a Redes de estaes (NOW): so arquiteturas que correspondem a um conco a junto de estaes de trabalho interligadas atravs de uma rede local (LAN) co e e que servem como plataforma de execuo de aplicaes distribu ca co das. Nesse tipo de arquitetura, a comunicao feita por troca de mensagens ca e entre as diversas aplicaes que executam na rede. Esse tipo de arquiteco tura largamente utilizado, tanto comercialmente como academicamente. e Como exemplo, podemos citar Estaes Sun interligadas por rede Etherco net.
Nesse contexto, um cluster pode ser caracterizado como uma plataforma alternativa, aliando o poder e a velocidade de processamento das arquiteturas dedicadas (MPPs) com a disponibilidade de recursos (hardware e software baratos) das redes de estaes. co Quando comparados com arquiteturas dedicadas, os clusters de multiprocessadores simtricos apresentam um grande nmero de vantagens. Eles so e u a relativamente baratos (seus custos so menores que o custo de um supercoma putador paralelo), eles oferecem uma boa relao custo/desempenho (porque ca todo o hardware e o software necessrios esto ` disposio), e, da mesma forma, a a a ca suas volumosas vendas atraem investimentos diretos para o seu rpido melhoraa mento. Eles tambm permitem um desenvolvimento progressivo de aplicaes, e co 434
comeando com apenas um processador, passando para multiprocessadores e, c nalmente, usando um conjunto de estaes de trabalho multiprocessadoras inco terconectadas por alguma rede de comunicao de dados local. ca Em complemento, podem-se caracterizar basicamente, duas classes de arquiteturas baseadas em clusters: Arquiteturas homogneas: onde os nodos que compem o cluster possuem e o a mesma arquitetura e sistema operacional, logo entendem as mesmas instrues sem a necessidade de converso de dados a m de possibilitar o co a processamento dos mesmos, em diferentes processadores. As arquiteturas homogneas esto se tornando um padro na rea de clusters de alto dee a a a sempenho, por serem mais simples de operar e por no apresentarem proba lemas ligados ` converso de dados entre diferentes sistemas operacionais a a e ou arquiteturas; Arquiteturas heterogneas: onde os nodos que formam o cluster possuem e processadores diferentes e, possivelmente, diferentes sistemas operacionais. Exigem a converso de dados para que uma instruo possa processar em a ca diferentes processadores. Apresentam problemas ligados ` converso de a a dados entre diferentes sistemas operacionais e ou arquiteturas. Alm dessas classes de arquiteturas cluster, pode-se distinguir dois tipos de e classicao quanto aos nodos que fazem parte do cluster: ca Arquitetura simtrica: possuem todos os nodos homogneos, sendo que toe e dos os nodos possuem a mesma velocidade e capacidade de processamento, alm de possu e rem a mesma quantidade de recursos computacionais (ex.: memria). Somente clusters com esse tipo de arquitetura possibilitam o uma verdadeira anlise de desempenho. a Arquiteturas assimtricas: possuem nodos diferentes. Podem possuir noe dos homogneos, mas com diferentes velocidades e capacidades de proe cessamento ou nodos homogneos com diferentes recursos de computao e ca (ex.: memria). Arquiteturas dessa classe dicultam poss o veis anlises de a desempenho.
435
Cap tulo 53
Balanceamento de Carga
Todo hardware tem o seu limite, e muitas vezes o mesmo servio tem que ser c repartido por vrias mquinas, sob pena de se tornar congestionado. Estas a a solues podem-se especializar em pequenos grupos sobre os quais se faz um co balanceamento de carga: utilizao do CPU, de armazenamento ou de rede. ca Qualquer uma delas introduz o conceito de clustering, ou server farm, j que o a balanceamento ser, provavelmente, feito para vrios servidores. a a
53.1
Balanceamento de armazenamento (storage)
O balanceamento do suporte de armazenamento permite distribuir o acesso a sistemas de arquivos por vrios discos, pelo que derivam ganhos bvios em tempos a o acesso. Estas solues podem ser dedicadas ou existir em cada um dos servico dores do cluster. As solues existentes hoje so implementadas em hardware, co a dentre elas podemos citar as tcnicas RAID (Redundant Arrays of Independent e Disks) , SAN (Storage Area Network) e NAS (Network-Attached Storage).
53.2
Balanceamento de rede
O balanceamento da utilizaao da rede passa sobretudo por reencaminhar o c trfego por caminhos alternativos a m de descongestionar os acessos aos servia dores.O mecanismo/dispositivo responsvel pelo balanceamento chamado de a e director. Na verdade, ele pode existir sob vrias formas, dependendo do(s) a servio(s) que se pretende balancear. Este director serve tambm de interface c e entre o cluster de servidores e os clientes do(s) servio(s) - tudo o que os clientes c conhecem o endereo semi-pblico deste servidor. Esta abordagem (clssica) e c u a algo limitada, em termos de escalabilidade e nmero de tramas que o direce u tor consegue redireccionar, principalmente devido ` velocidade dos barramentos a das placas de rede. Existem, no entanto, outras solues mais complexas que co tiram melhor partido das caracter sticas do protocolo TCP/IP em conjunto com um roteamento de pacotes especializado, tais como NAT, IP Tunneling e Direct
436
Routing. Outras solues operam exclusivamente em apenas algumas camadas co (n veis) do modelo OSI no n 4, 5, 6 e 7. vel
53.2.1
NAT
Em redes de computadores, NAT, Network Address Translation, tambm cone hecido como masquerading uma tcnica que consiste em reescrever os endereos e e c IP de origem de um pacote que passam sobre um router ou rewall de maneira que um computador de uma rede interna tenha acesso ao exterior (rede pblica). u Utilizamoe s seguinte situao como exemplo. A estao com IP 192.168.1.13 ca ca faz uma requisio, por exemplo, para um endereo externo. O pacote sai ca c com o IP da estao e corre em direo ao intermediador entre o ambiente inca ca terno e externo, o gateway. O gateway, atravs do protocolo NAT mascara o e IP da estao com seu IP (200.158.112.126 - que vlido na internet) assim ca e a fazendo com que o pacote seja entregue no destino solicitado pela estao. No ca retorno do pacote, ele parte do endereo externo, chega a nossa rede no servidor c NAT (200.158.112.126) e l volta at o IP da estao assim chegando ` estao a e ca a ca (192.168.1.13).
Figura 53.1: Balanceamento de carga NAT
53.2.2
IP Tunneling
Um IP Tunnel um termo tcnico para designar o encapsulamento de um pae e cote IP dentro de outro, com o propsito de simular uma conexo f o a sica entre duas redes remotas atravs de uma outra rede. e Este processo frequentemente usado com o protocolo IPsec para criar um e meio de conectar duas redes usando uma VPN. O meio para que essas duas redes se vejam , tipicamente, a Internet. Dessa forma o fator limitador que e a distncia praticamente eliminado, permitindo a utilizadores de uma rede e a e dispr dos recursos de outra rede remota como se fossem locais. o
437
53.2.3
Direct Routing
A gura 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 requisio seqncialmente entre servidores ca ue reais. Usando este algoritmo, todos os servidores so tratados igualmente a sem considerar sua capacidade ou carga; Weighted Round-Robin Scheduling: Distribui cada requisio seqncialmente ca ue entre servidores reais, mas d mais requisies para servidores com mais a co capacidade; Least-Connection: Distribui mais requisies para servidores com menos co conexes ativas. Por ele manter um histrico de conexes ativas atravs o o o e da tabela IPVS, least-connection um tipo de algoritmo de escalonamento e dinmico, sendo a melhor escolha se h um alto grau de variao na carga a a ca do pedido. Se h um grupo de servidores com diferentes capacidades, a weighed least-connection a melhor escolha; e
Weighted Least-Connections (default): Distribui mais requisies para co servidores com poucas conexes ativas em relao ` sua capacidade. Este o ca a algoritmo ideal quando os servidores contm hardware de capacidade e e variedade; Destination Hash Scheduling: Distribui requisies para os servidores co procurando o endereo IP de destino numa tabela hash esttica. Este c a algoritmo projetado para us-lo em um servidor de proxy-cache; e a Source Hash Scheduling: Distribui requisies para os servidores procuco rando o endereo IP de origem numa tabela hash esttica. Este algoritmo c a projetado para roteadores LVS (Linux Virtual Server) com mltiplos e u
438
rewalls. O LVS uma soluo de balanceamento de carga para sise ca temas Linux. Basicamente, conta com um software para balancemaneto IP (IPVS) e um para balanceamento na camada de aplicao (KTCPVS). ca
53.4
Balanceamento de CPU
Este tipo de balanceamento efectuado pelos sistemas de processamento dise tribu e consiste, basicamente, em dividir a carga total de processamento pelos do vrios processadores no sistema (sejam eles locais ou remotos). a
53.4.1
Sistema de processamento distribu do
Um sistema de processamento distribu ou paralelo um sistema que interliga do e vrios ns de processamento (computadores individuais, no necessariamente a o a homogneos) de maneira que um processo de grande consumo seja executado e no n mais dispon o vel, ou mesmo subdividido por vrios ns. Adivinham-se, a o portanto, ganhos bvios nestas solues: uma tarefa qualquer, se divis o co vel em vrias subtarefas pode ser realizada em paralelo. a A nomenclatura geralmente utilizada neste contexto HPC (High Pere formance Computing) e/ou DPC (Distributed/Parallel Computing).// Com os desenvolvimentos nesta rea, surgiram solues por software que fazem, a co geralmente (mas no necessariamente), alteraes no ncleo do sistema operaa co u cional e que, na maioria dos casos, no so compat a a veis entre elas, e dicilmente entre verses diferentes da mesma soluo. Assentam, no entanto, em arquiteco ca turas de comunicao standard, como o caso da Parallel Virtual Machine e ca e Message Passing Interface. Resumidamente, estas arquiteturas conseguem transportar um processo (tarefa) e o seu contexto (arquivos abertos, etc.) pela rede at outro n. O n que originou o processo passa, assim, a ser apenas um e o o receptor dos resultados desse processo. Atualmente, a principal barreira destes sistemas implementar mecanismos e de Inter-Process Communication (IPC), os Distributed IPC, dada a sua extrema complexidade. A gura 53.3 ilustra as vrias camadas de interoperabilidade de um sistema a distribu do. Atravs do gateway a rede pblica tem acesso a um supercomputae u dor, sem ter conhecimento disso, dado que s conhece o gateway. Qualquer o aplicao executada no gateway (preparada para ser paralelizada) pode ser disca tribu por vrios ns, entregando os resultados mais rpido do que se fosse da a o a processada por apenas um n. o
Parallel Virtual Machine PVM a abreviao de Parallel Virtual Machine. Este um pacote de softe ca e ware que permite que uma rede heterognea de computadores de todos os tipos e seja programada como se fosse apenas uma unica Mquina Paralela Virtual. a A programao baseada no paradigma de troca de mensagens. O PVM ca e e
439
Figura 53.3: Sistema de processamento distribu do. composto, basicamente, de trs partes: uma biblioteca de funes (em C e em e co FORTRAN77) que implementam para o usurio as diretivas de programao a ca da Mquina Virtual (MV); um processo daemon que rodar em cada host para a ticipante da MV e um console de onde podem ser executadas algumas funes co bsicas de controle (congurao da MV, gerenciamento de tarefas, etc.). a ca A implementao do PVM baseada em processos do Unix. Na verdade, ca e cada tarefa PVM um processo Unix. Isto explica parcialmente a alta portae bilidade do sistema para computadores de arquiteturas to diferentes. Tarefas a so as unidades bsicas de execuo do PVM. E verdade que, em algumas ima a ca plementaes, as tarefas podem no ser processos. Nestes casos, caber ao co a a implementador garantir a compatibilidade (tais excees so mais comuns em co a sistemas de natureza mais complexa como computadores paralelos). Os programas em PVM podem rodar espalhados por uma rede de natureza heterognea. Mais particularmente, poss disparar tarefas em computadores e e vel em qualquer parte da Internet (desde que o usurio tenha acesso a esta mquina, a a obviamente). Esta independncia em relao ` rede de comunicaes que liga e ca a co os hosts que participam da MV garantida pelo uso do protocolo TCP/IP para e comunicao entre as tarefas atravs da rede. ca e O pacote PVM relativamente pequeno (cerca de 4.5 MB de cdigo fonte em e o C), e necessita ser instalado apenas uma vez em cada mquina para ser acess a vel a ` todos os usurios. Alm disso, a instalao no requer privilgios especiais e a e ca a e pode ser efetuada por qualquer usurio. a Message Passing Interface Message Passing Interface (MPI) um padro para comunicao de dados em e a ca computao paralela. Existem vrias modalidades de computao paralela, e ca a ca dependendo do problema que se est tentando resolver, pode ser necessrio pasa a sar informaes entre os vrios processadores ou nodos de um cluster, e o MPI co a oferece uma infraestrutura para essa tarefa.
440
No padro MPI, uma aplicao constitu por um ou mais processos a ca e da que se comunicam, acionando-se funes para o envio e recebimento de menco sagens entre os processos. Inicialmente, na maioria das implementaes, um co conjunto xo de processos criado. Porm, esses processos podem executar e e diferentes programas. Por isso, o padro MPI algumas vezes referido como a e MPMD (multiple program multiple data). Elementos importantes em implementaes paralelas so a comunicao de dados entre processos paralelos e o co a ca balanceamento da carga. Dado o fato do nmero de processos no MPI ser noru malmente xo, neste texto enfocado o mecanismo usado para comunicao de e ca dados entre processos. Os processos podem usar mecanismos de comunicao ca ponto a ponto (operaes para enviar mensagens de um determinado processo co a outro). Um grupo de processos pode invocar operaes coletivas (collective) co de comunicao para executar operaes globais. O MPI capaz de suportar ca co e comunicao ass ca ncrona e programao modular, atravs de mecanismos de coca e municadores (communicator) que permitem ao usurio MPI denir mdulos que a o encapsulem estruturas de comunicao interna. ca
441
Parte X
442
Cap tulo 54
Ambiente Microsoft Windows 2000/2003

54.1 DHCP - Dynamic Host Conguration Protocol
A implementao do DHCP no Windows 2000/2003 Server baseada em padres ca e o denidos pelo IETF - Internet Engineering Task Force. Por padro, este servio a c e NAO instalado durante a instalao t ca pica do Windows 2000/2003 Server. E importante ressaltar que este servio no pode ser instalado nos Windows 98, c a Me, 2000 Professional, XP Professional, XP Home, Vista, etc. J os clientes a DHCP podem ser quaisquer hosts baseados no Microsoft Windows. A maioria das tarefas de administrao do DHCP pode ser executada no ca console DHCP, que acessado atravs de: Iniciar >> Programas >> Ferramene e tas Administrativas >> DHCP. Inclusive, poss utilizar um unico console e vel DHCP para se conectar, remotamente atravs da rede, com diferentes servie dores DHCP. Por padro, a maior parte das informaes (log e banco de dados) a co deste servidor armazenada na pasta \%windir%\System32\dhcp, onde windir e se refere ` pasta onde o Windows foi instalado. a
54.1.1
Processo de Instalao/Congurao ca ca
O processo de instalao se d seguindo os passos: Iniciar >> Conguraes ca a co >> Painel de Controle; Adicionar ou Remover Programas; Adicionar ou Remover Componentes do Windows. O DHCP classicado como um SERVICO e DE REDE (Networking Services). Aps a instalao, no preciso reinicializar o ca a e o servidor para que o servio possa ser disponibilizado, basta seguir alguns proc cedimentos obrigatrios que sero mencionados abaixo. Lembrando que este o a servio congurado para executar no contexto da conta LOCAL SYSTEM. c e Aps ter instalado o servidor DHCP, o PROXIMO PASSO autorizar o o e servidor DHCP no Active Directory. Somente membros do grupo Enterprise Admins (Administradores de empresa) tm permisso para autorizar um servie a dor DHCP no Active Directory. A autorizao obrigatria no Active Directory ca o 443
uma medida de segurana para evitar que servidores DHCP secundrios see c a jam introduzidos na rede sem o conhecimento do administrador. O caminho a ser seguido o: Iniciar >> Programas >> Ferramentas Administrativas >> e DHCP; clique no nome do servidor DHCP; Selecione o comando Ao >> Auca torizar. Agora que o servidor DHCP est devidamente instalado e autorizado no a Active Directory ser necessrio a criao de um ou mais ESCOPOS. Para a a ca criar e congurar um escopo utilizado o console de administrao do DHCP: e ca Iniciar >> Programas >> Ferramentas Administrativas >> DHCP. Algumas propriedades importantes que devem ser conguradas neste passo so: a Escopo DHCP: uma faixa espec ca de endereos IP que deve estar dentro c da faixa de endereos da rede onde o servidor DHCP ser utilizado. Mais c a de um escopo pode ser denido 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 denir uma sub-rede. Para a cada escopo, necessrio congurar uma srie de parmetros: mscara de e a e a a sub-rede, default gateway, endereo IP de um ou mais servidores DNS, c endereo IP do servidor WINS e assim por diante; c Intervalos de Excluso: uma faixa espec a ca de endereos IP para retirar c de um escopo, ou seja, endereos que voc no quer que sejam concedic e a dos aos clientes da rede. Lembrando que endereos IPs exclu c dos podem estar ativos na sua rede, como por exemplo, em computadores ou outros dispositivos de rede congurados manualmente (IP xo); Pool de Endereos: conjunto de endereos especicados no escopo DHCP c c descontando os eventuais intervalos de excluso. Enm, os endereos que a c sero cedidos automaticamente aos clientes do servio; a c Intervalo de Durao da Concesso: especica por quanto tempo um ca a cliente DHCP pode usar um endereo IP atribu antes que seja necessrio c do a renovar a congurao com o servidor DHCP; ca Endereos Reservados: concesso permanente a hosts especicados na sua c a rede. Cada reserva de IP associada ao MAC Address da interface de rede e do host em questo. Vale ressaltar que os endereos reservados devem estar a c fora do intervalo de excluso. a
Aps denir e congurar um escopo, ele deve SER ATIVADO antes que o o servidor DHCP comece a fazer concesses aos clientes. No entanto, voc no o e a deve ativar um novo escopo at ter especicado as opes DHCP para ele (dee co fault gateway, nmero IP do servidor DNS e assim por diante). u Ento, o processo de instalao como um todo pode ser resumido a ca em: instalar servidor DHCP; ativ-lo no Active Directory; criar e a congurar o Escopo; e por m ativar o Escopo. E importante notar que as opes do DHCP (default gateway, endereo IP co c de um ou mais servidor DNS e assim por diante), podem ser conguradas em trs n e veis: servidor (so vlidas para todos os escopos congurados no servidor a a 444
DHCP); escopo (se aplicam a um escopo especicamente) e opes de uma co reserva (se aplicam a reserva e, por padro, so herdadas do escopo onde a a a reserva foi criada).
54.1.2
Integrao do DHCP com o DNS ca
O servidor DHCP pode ser utilizado para fazer atualizaes dinmicas no DNS, co a em nome dos clientes DHCP. Ou seja, quando um cliente DHCP inicializado e e obtm uma concesso de endereo, o DHCP pode atualizar os registros de e a c recurso de endereo (A) e ponteiro (PTR) do cliente, na base de dados do DNS. c Esse processo exige o uso de uma opo de DHCP adicional, a opo FQDN do ca ca Windows. Essa opo permite ao cliente fornecer seu nome de dom ca nio totalmente qualicado (FQDN) e instrues para o servidor DHCP sobre como deseja co que o servidor processe atualizaes dinmicas de DNS (se houver) em seu nome. co a Clientes baseados em Windows XP ou Windows Server 2000/2003 atualizam automaticamente os registros do tipo A na zona direta do DNS. Ou seja, no a necessria nenhuma integrao entre DNS e DHCP para isso acontecer. J e a ca a para os registros da zona reversa (registros PTR), a histria diferente. Esses o e clientes no conseguem atualizar seus registros PTR diretamente, esta atuala izao tem que ser feita pelo servidor DHCP. ca Clientes mais antigos, baseados em Windows 95, 98, Me ou NT 4.0, no so a a 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 uma funcionalidade que foi introduzida no Windows 98. Ela tambm e e est presente no Windows XP, Vista, Longhorn Server e no Windows Server a 2000/2003. Se os clientes estiverem congurados para usar um servidor DHCP (em vez de serem congurados manualmente com um endereo IP e outros c parmetros), o servio do cliente DHCP entrar em funcionamento a cada vez a c a que o computador for inicializado. O servio do cliente DHCP usa um processo c de trs etapas para congurar o cliente com um endereo IP e outras informaes e c co de congurao: ca
O cliente DHCP tenta localizar um servidor DHCP e obter as conguraes co do protocolo TCP/IP, a partir desse servidor; Se um servidor DHCP no puder ser encontrado, o cliente DHCP cona gura automaticamente seu endereo IP e mscara de sub-rede usando c a um endereo selecionado da rede classe B reservada, 169.254.0.0, com a c mscara de sub-rede, 255.255.0.0 (RECURSO APIPA). O cliente DHCP a ir fazer uma vericao na rede, para ver se o endereo que ele est se a ca c a auto-atribuindo j no est em uso na rede. Se o endereo j estiver em a a a c a uso ser caracterizado um conito de endereos. Se um conito for encona c trado, o cliente selecionar outro endereo IP. A cada conito de endereo, a c c o cliente ir tentar novamente a congurao automtica escolhendo um a ca a
445
novo endereo IP. Aps 10 tentativas o cliente tenta novamente localizar c o um servidor DHCP; Depois de selecionar um endereo no intervalo de rede 169.254.0.0 que no c a est em uso, o cliente DHCP ir congurar a interface com esse endereo. a a c O cliente continua a vericar se um servidor DHCP no est dispon a a vel. Esta vericao feita a cada cinco minutos. Se um servidor DHCP for ca e encontrado, o cliente abandonar as informaes conguradas automatia co camente e usar um endereo oferecido pelo servidor DHCP (e quaisquer a c outras informaes de opes de DHCP fornecidas). co co
54.1.4
Comandos ipcong Relacionados ao DHCP
Os principais comandos relacionados ao DHCP e suas funcionalidades so: (1) a ipcong /release: para liberar a concesso (release) do cliente; (2) ipcong /rea new: para renovar a concesso do cliente; (3) ipcong: para obter informaes a co bsicas sobre as conguraes do protocolo TCP/IP; (4) ipcong /all: exibe a co informaes detalhadas sobre as conguraes do protocolo TCP/IP em todas co co as interfaces do computador. Clientes mais antigos como o Windows 95, 98 ou Me, no disponibilizam o a comando ipcong. Nestes clientes, voc pode utilizar o comando WINIPCFG e para vericar as conguraes do protocolo TCP/IP e para liberar ou renovar co uma concesso do servidor DHCP. a
54.1.5
Regra 80/20
Para equilibrar o uso do servidor DHCP, uma boa prtica usar a REGRA a e 80/20 para dividir os endereos do escopo entre dois servidores DHCP. Se o c Servidor 1 estiver congurado para disponibilizar a maioria (aproximadamente 80%) dos endereos, o Servidor 2 pode ser congurado para disponibilizar os c outros endereos (aproximadamente 20%) para os clientes. c
54.2
DNS - Domain Name System
A implementao do DNS no Windows 2000/2003 Server baseada em padres ca e o denidos pelo IETF - Internet Engineering Task Force. Por padro, este servio a c e NAO instalado durante a instalao t ca pica do Windows 2000/2003 Server. E importante ressaltar que este servio no pode ser instalado nos Windows 98, c a Me, 2000 Professional, XP Professional, XP Home, Vista, etc. J os clientes a DNS podem ser quaisquer hosts baseados no Microsoft Windows. A maioria das tarefas de administrao do DNS pode ser executada no conca sole DNS, que acessado atravs de: Iniciar >> Programas >> Ferramene e tas Administrativas >> DNS. Inclusive, poss e vel utilizar um unico console DNS para se conectar, remotamente atravs da rede, com diferentes servie dores DNS. Por padro, a maior parte das informaes (lista de servidores a co ROOT HINTS e informaes sobre zonas) deste servidor armazenada na pasta co e \%windir%\System32\Dns, onde windir se refere ` pasta onde o Windows foi a instalado. 446
54.2.1
Processo de Instalao/Congurao ca ca
O processo de instalao se d seguindo os passos: Iniciar >> Conguraes ca a co >> Painel de Controle; Adicionar ou remover programas; Adicionar ou Remover Componentes do Windows. O DNS classicado como um SERVICO e DE REDE (Networking Services). Aps a instalao, no preciso reinicializar o ca a e o servidor para que o servio possa ser disponibilizado. Lembrando que este c servio congurado para executar no contexto da conta LOCAL SYSTEM. c e Aps a instalao do servidor DNS, o PROXIMO PASSO criar uma ZONA o ca e PRIMARIA DIRETA. Por exemplo, vamos supor que voc est implementando e a a estrutura de DNS da rede da sua empresa, cujo dom nio root abc.com.br. e A zona chamada primria porque ela ainda no existe e est sendo criada e a a a para conter as informaes do dom co nio. Ela chamada direta, porque conter e a informaes para resoluo de nomes para endereo IP, ou seja, fornecido um co ca c nome no dom nio abc.com.br, esta zona conter informaes para retornar o a co endereo IP associado a este nome. c A maioria das consultas realizadas so as chamadas consultas diretas (Fora ward Lookup). Neste tipo de consulta, o cliente fornece um nome e o servidor DNS retorna um endereo IP associado a esse nome. O DNS tambm d suporte c e a a `s chamadas consultas inversas (Reverse Lookup), na qual o cliente fornece um endereo IP vlido e o servidor DNS retorna o nome associado a esse endereo c a c IP. Originalmente o DNS no foi projetado para dar suporte `s consultas rea a versas. Pela maneira hierrquica como o DNS organizado, a unica maneira a e 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 questo foi criado um dom a nio especial chamado de INADDR.ARPA. Este dom nio faz parte das denies atuais do DNS e foi a co maneira encontrada para fornecer a resoluo reversa de nomes sem que houca vesse a necessidade de pesquisar em todos os servidores DNS. Para criar o espao c de nomes reverso, so criados subdom a nios do dom especial in-addr.arpa. Os nio nomes destes subdom nios so formados pela ordem inversa do nmero IP da a u rede. Por exemplo, considere a rede 100.20.50.0/255.255.255.0. A zona para res oluo reversa desta rede seria 50.20.100.in-addr.arpa. E importante ressaltar ca que o uso de dom nios in-addr.arpa aplicado a todas as redes baseadas no e protocolo IPv4. Ou seja, este uso no uma particularidade dos sistemas Wina e dows. Outro aspecto relevante o fato dos mecanismos de recurso e interao e a ca tambm serem utilizados para a resoluo reversa. e ca Quando voc cria uma zona pela primeira vez, ela uma zona primria. e e a Somente na zona primria permitido fazer alteraes nos registros da zona. a e co Alm da zona primria, o DNS permite que sejam feitas cpias da zona em oute a o ros servidores DNS. Estas cpias so as ZONAS SECUNDARIAS. Por exemplo, o a voc pode ter uma zona primria no servidor DNS da matriz da empresa e criar e a uma zona secundria (cpia da zona primria), nos servidores DNS de cada la o a ial, para reduzir o trfego, devido ` resoluo de nomes DNS, nos links de WAN. a a ca As zonas secundrias tambm so reconhecidas como AUTORIDADES para o a e a
447
dom nio em questo e podem responder `s consultas enviadas pelos clientes. A a a unica diferena, em relao ` zona primria, que nas zonas secundrias no c ca a a e a a podem ser feitas alteraes, adies e excluses de registros de recursos. Semco co o pre que houver alteraes, o servidor DNS onde est a zona primria, notica co a a os servidores DNS onde existem zonas secundrias e, ento, os servidores DNS a a da zona secundrio solicitam que as alteraes sejam envidas a partir da zona a co primria. Com isso o DNS mantm as zonas sincronizadas, ou seja, alteraes a e co feitas nas zonas primrias so repassadas para as zonas secundrias. O DNS a a a usa um mecanismo de REPLICACAO INCREMENTAL, ou seja, somente as alteraes so replicadas e no todo o contedo da zona. co a a u Por padro, quando o servidor DNS instalado, uma lista chamada ROOT a e HINTS criada e gravada em um arquivo chamado Cache.dns localizado na e pasta \%windir%\System32\Dns. Esta lista armazena informaes dos servico dores para o dom nio root (representado pelo ponto .) e para os dom nios de n vel superior (.com, .net, .gov, etc.). Este recurso garante a interao entre ca servidores DNS ao redor do mundo de forma a ser poss a resoluo de qualvel ca quer FQDN (Nome de Dom nio Totalmente Qualicado). Aps a instalao e congurao do servidor DNS necessria a criao de o ca ca e a ca 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-specic data. Alm dos tipos de registros padro IPv4, e a tambm so suportados outros tipos, como por exemplo, o tipo AAAA que e a dene um mapeamento de um nome DNS em um endereo de host no padro c a IPv6. (ipv6 host1.example.microsoft.com. IN AAAA 4321:0:1:2:3:4:567:89ab). Nos CLIENTES Windows 2000/2003 Server, a congurao do DNS envolve as ca seguintes tarefas (ao congurar as propriedades do TCP/IP do cliente): Congurar um nome (de host) DNS para cada computador; Congurar um suxo DNS primrio para o computador, que posicionado a e aps o nome de host para formar o FQDN. Por exemplo, abc.com.br; o Congurar uma lista de servidores DNS que sero usados pelos clientes a para resolver nomes DNS. Vale ressaltar que a lista sempre utilizada de e forma seqencial, ou seja, primeiramente o primeiro servidor da lista u e consultado. Caso este esteja oine ou haja problemas na comunicao, o ca cliente consultar o prximo servidor da lista e assim por diante; a o
Congurar a lista ou mtodo de pesquisa de suxo DNS a ser usado e pelo cliente quando ele executar pesquisas de consultas DNS para nomes de dom nio curtos no qualicados. Alm do suxo DNS primrio, poa e a dem ser adicionados suxos espec cos, por exemplo, vendas.abc.com. Desta forma, ao se fazer uma consulta do tipo xyz (nome no totalmente a qualicado), na verdade, ser consultado xyz.vendas.abc.com (suxo esa pec co) e se no houver xito tambm ser consultado xyz.abc.com (sua e e a xo primrio); a
448
54.2.2
Segurana de Acesso c
Voc pode denir conguraoes de segurana para limitar o acesso `s cone c c a guraes dos servidores DNS. Por padro, os grupos Domain Admins (Adco a ministradores do dom nio), Enterprise Admins (Administradores de empresa), DNS Admins (Administradores do DNS) e o grupo Administrators tm pere misso de controle total nos servidores DNS. Voc pode retirar as permisses a e o de todos os grupos deixando apenas as permisses do grupo DNS Admins (e o talvez tambm a do grupo Administrators). Com isso, voc pode controlar e e quais usurios podem fazer alteraes nos servidores DNS por meio da incluso a co a destes usurios no grupo DNS Admins. E muito IMPORTANTE notar que a e necessrio manter as permisses padro de acesso a servidor DNS atribu a o a das ao grupo Authenticated Users (Usurios Autenticados). Se voc retirar este grupo, a e os usurios da rede no conseguiro ler informaes no servidor DNS, ou seja, a a a co as consultas dos clientes no sero respondidas. Na prtica como se o servidor a a a e DNS estivesse desligado.
54.2.3
Integrao do DNS com o Active Directory ca
Outro controle que muito importante em relao `s quais clientes tero pere e ca a a misso para incluir registros dinamicamente no DNS. Sem um controle de quem a pode fazer atualizaes dinmicas, um usurio mal intencionado poder regisco a a a trar uma srie de registros falsos ou at mesmo registrar milhares de registros e e em um ataque do tipo Denial of Service, apenas com o objetivo de paralisar o servidor DNS e com isso os servios que dependem do DNS. No Windows c 2000/2003 Server voc pode fazer com que o DNS somente aceite atualizaes e co dinmicas enviadas por hosts autenticados no dom a nio, proporcionando assim uma maior segurana no acesso `s informaes das zonas do DNS. Este tipo c a co de atualizao conhecido como Atualizao Dinmica Segura (Security Dyca e ca a namic Update). Porm, este tipo de atualizao somente est dispon e ca a vel em zonas DNS integradas com o Active Directory, onde voc pode denir uma lista e de permisso de acesso (semelhante a uma lista de permisses NTFS em uma a o pasta). Existem dois pontos fundamentais a serem considerados na integrao do ca DNS com o Active Directory: O DNS necessrio, obrigatrio, para localizao dos DCs (Controladores e a o ca de Dom nio) do dom nio;
O servio Netlogon usa o novo suporte ao servidor DNS para fornecer c registro de controladores de dom nio no seu espao de nomes de dom c nio DNS. Enm, sua funo bsica executar registros a cerca do AD no DNS. ca a e A integrao inicia no momento da instalao do Active Directory em um ca ca member server para torn-lo um DC. O assistente de instalao do Active Dia ca rectory solicita que voc informe o nome DNS do dom para o qual est sendo e nio a criado um novo DC. Durante a instalao o assistente deve ser capaz de se conecca tar a um servidor DNS que seja AUTORIDADE para o dom nio informado. Se isso no for poss a vel, o assistente ir se oferecer para instalar e congurar o DNS a no prprio servidor que est sendo promovido a DC. Se isso tambm no for o a e a 449
poss vel, o Active Directory no poder ser instalado. a a Depois que o Active Directory estiver instalado, existem duas opes para o co tipo de armazenamento e duplicao de zonas do DNS: ca Armazenamento de zona padro usando um arquivo baseado em texto: as a zonas armazenadas dessa maneira esto localizadas em arquivos de texto, a com a extenso .dns, os quais so armazenados na pasta \%windir%\System32\Dns a a em cada computador que opera um servidor DNS. Os nomes de arquivo de zona correspondem ao nome que voc escolhe para a zona durante a e sua criao, como Exemplo. abc.com.br.dns o arquivo que armazena ca e informaes para a zona abc.com.br; co Armazenamento de zona integrada ao diretrio usando o banco de dados o do Active Directory: as zonas armazenadas dessa maneira esto locala izadas na rvore do Active Directory. Cada zona integrada ao diretrio a o armazenada em um objeto do tipo dnsZone identicado pelo nome que e voc escolhe para a zona durante a sua criao. e ca Em redes que distribuem o DNS para oferecer suporte ao Active Directory, as zonas primrias integradas ao diretrio so especialmente recomendadas e a o a proporcionam os seguintes benef cios: Atualizaes multi-master e recursos de segurana avanada baseados nos co c c recursos do Active Directory. Para ZONAS NAO INTEGRADAS, o modelo de atualizao do tipo single-master. Neste ultimo, somente a zona ca e primria sofre alteraes e repassa estas alteraes para as zonas secundrias. a co co a Se o servidor onde est a zona primria apresentar problemas, novas ata a ualizaes dinmicas no podero ser processadas enquanto este servidor co a a a no for recuperado. J com ZONAS INTEGRADAS, podem ser feitas a a alteraes em qualquer cpia da zona e existe uma cpia em todos os DCs co o o do dom nio onde o DNS estiver instalado. O mecanismo de replicao do ca Active Directory se encarrega de manter as vrias cpias sincronizadas; a o Com esse modelo, no haver um ponto unico de falha (como no caso do a a modelo baseado em zonas padro), pois qualquer servidor DNS poder a a receber atualizaes dinmicas enviadas pelos clientes; co a Outra vantagem das zonas integradas que todo objeto do Active Direce tory possui uma ACL - Access Control List (idntica ` lista de permisses e a o NTFS para uma pasta ou arquivo). Esta lista pode ser editada para ter um controle mais renado sobre quem tem acesso e qual o n de acesso; vel A replicao do Active Directory mais rpida, mais eciente e mais ca e a segura do que o mecanismo de transferncia de zonas padro do DNS. e a Nota: Apenas as zonas primrias podem ser armazenadas no Active Direca tory. Um servidor DNS no pode armazenar zonas secundrias no diretrio. Ele a a o dever armazen-las em arquivos de texto padro. a a a
450
54.2.4
Servidor DNS somente Cache
Um servidor DNS somente cache um servidor que no tem nenhuma zona e a congurada. A funo deste servidor resolver consultas utilizando os mtodos ca e e de recurso e/ou interao e armazenar os resultados obtidos no cache do servia ca 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 armazenado no cache do servidor DNS somente cache e a resposta retore e nada para o cliente que fez a consulta. Futuras consultas a este mesmo nome, dentro do per odo de expiraao, sero respondidas com base nas informaes c a co do cache do servidor DNS. Este tipo de servidor deve ter quantidade suciente de memria RAM para exercer esta funo, pois toda a informao do cache o ca ca do DNS criada e mantida na memria RAM do servidor. Portanto, o servie o dor DNS somente cache NAO ARMAZENA NENHUMA ZONA E NAO EH AUTORIDADE para nenhum dom nio.
54.2.5
Arquivo Hosts
Se no for encontrada a resposta no cache local do DNS, o programa resolvedor a consulta as entradas do arquivo hosts. Este um arquivo texto que ca na pasta e onde o Windows 2000/2003 Server foi instalado, dentro do seguinte caminho: \system32\drivers\etc. Este arquivo possui entradas do tipo: um nmero IP u 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
Distribuio de Carga ca
Por padro, o servio DNS usa a atribuio de prioridades a sub-redes locais a c ca como o mtodo para dar preferncia a endereos IP da mesma rede quando uma e e c consulta de cliente resolvida para um nome de host que est mapeado a mais e a de um endereo IP. Ou seja, se o cliente enviou uma consulta para um nome e c existem, por exemplo, dois endereos IP associados a este nome, o servidor DNS c dar preferncia ao endereo IP que for da mesma rede do cliente que enviou a e c a consulta. Esse recurso permite que o aplicativo do cliente se conecte ao host que esteja usando seu endereo IP mais prximo (e normalmente o mais rpido). c o a Round Robin o algoritmo de rotao utilizado pelo Windows 2000/2003 e ca Server para a realizao da distribuio de carga entre dois ou mais servidores ca ca DNS da rede. Vale ressaltar que a atribuio de prioridade a sub-rede locais ca substitui o uso da rotao Round Robin para nomes com vrios endereos IP asca a c sociados. Entretanto, quando o recurso Round Robin est ativado, ele continua a sendo utilizado como mtodo de classicao secundria. Ou seja, caso haja um e ca a nome associado a vrios endereos IP no pertencentes ` rede local, o algoritmo a c a a de Round Robin utilizado para determinar qual endereo ser retornado. e c a
54.2.7
Comando ipcong/dnscmd Relacionadas ao DNS
Os principais comandos relacionados ao DNS e suas funcionalidades so: a
451
ipcong /ushdns: limpar o cache local; ipcong /displaydns: exibir o cache local; ipcong /registerdns: fora o registro das informaes do host no servidor; c co dnscmd /clearcache: limpar o cache do servidor DNS (executado no servidor).
54.3
Active Directory
Antes de falar em Active Directory, necessrio discursar sobre o LDAP (Lightweight e a Directory Access Protocol). Este um protocolo padro inicialmente projetado e a para o acesso a servios de diretrio X.500 da International Standards Orgac o nization (ISO). O LDAP a verso reduzida de um protocolo chamado DAP e a (Directory Access Protocol). A principal funo do DAP era a de estabelecer, ca de forma padro, regras de comunicao de acesso com um diretrio baseado a ca o no padro X.500, mas por ser complexo permitiu o surgimento do LDAP que a implementa apenas as operaes bsicas do DAP. A saber: Bind, Read, List, co a Search, Compare, Modify, Add, Delete e ModifyRDN. Em outras palavras, o LDAP simplesmente um protocolo encarregado por e denir a maneira atravs da qual se realizam as pesquisas em uma base de dae 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 decincias que este protocolo tinha e de sua extrema lentido. Mais adiante e a se concluiu que, como a maioria das consultas chegava normalmente atravs da e interface LDAP, seria muito mais vantajoso utilizar o LDAP como um servio c independente de diretrio sem a necessidade de utilizar o X.500. o Um diretrio uma base de dados estruturada hierrquica contendo difero e a entes tipos de informaes e oferece uma versatilidade muito grande na hora de co buscar a informao desejada. Um servio de diretrio contm informaes em ca c o e co forma de entradas. Cada entrada contm uma srie de dados (atributos). Uma e e boa analogia seria uma lista telefnica, que contm entradas: nomes de pessoas, o e nomes de empresas, etc. Cada entrada contm uma srie de atributos: telefone, e e endereo, etc. c
Active Directory uma implementao do protocolo LDAP feita pela Mie ca crosoft. Isto somente poss porque o protocolo LDAP um padro aberto. e vel e a Existem muitas outras implementaes, por exemplo, OpenLDAP (uma verso co a open source). O Active Directory implementa, alm do protocolo LDAP, oute ras funcionalidades como o DNS e o Kerberos. Ele utilizado como base de e dados centralizada de informaes necessrias para a operao de uma rede disco a ca tribu de computadores. Isto porque ele armazena informaes de usurios da co a e suas permisses, grupos, mquinas existentes na rede, recursos comuns, seja o a de disco ou f sicos, como impressoras e outros perifricos. Alm de armazenar e e vrios objetos em seu banco de dados, o AD disponibiliza vrios servios, como: a a c autenticao dos usurios, replicao do seu banco de dados, pesquisa dos obca a ca jetos dispon veis na rede, administrao centralizada da segurana utilizando ca c
452
GPO (Group Policy). Com a utilizao do AD, os usurios podero ter apenas ca a a uma senha para acessar todos os recursos dispon veis na rede. O que representa um grande avano se comparado a um cenrio onde necessrio ter diferentes c a e a 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 no se pode instalar o AD em a um servidor que execute o Windows Server 2003 - Web Edition, mas se pode ingressa-lo em um dom nio do Active Directory como servidor membro.
54.3.1
Tipos de Servidores
Existem dois tipos de servidores: Controlador de Dom nio (DC - Domain Controller): o computador que e possui o AD instalado, ou seja, um servidor que possui uma cpia da e o base de dados do AD. Em um mesmo dom nio podemos ter mais de um Controlador de Dom nio. As alteraes efetuadas em um DC so replico a cadas para todos os outros DCs. So os DCs quem fazem a autenticao a ca dos usurios de um dom a nio; Servidor Membro (Member Server): um servidor que no possui uma e a cpia do AD, porm tem acesso aos objetos do AD. No fazem a auteno e a ticao dos usurios. ca a
54.3.2
Denies de Floresta, Dom co nio, Site e Unidade Organizacional
Um dom nio pode ser denido como um limite administrativo e de segurana. c Ele um limite administrativo, pois as contas de Administrador tm permisses e e o de acesso em todos os recursos do dom nio, mas no em recursos de outros a dom nios. Ele um limite de segurana porque cada dom e c nio tem denies de co pol ticas de segurana que se aplicam `s contas de usurios e demais recursos c a a dentro do dom nio e no a outros dom a nios. Eles tambm podem ser denidos e como unidades de replicao. Todos os controladores de dom podem receber ca nio alteraes e replic-las em todos os outros controladores deste dom co a nio. Cada dom do Active Directory identicado por um sistema de nomes de dom nio e nios (DNS) e requer um ou mais controladores. Se a rede precisar de mais de um dom nio, voc poder criar facilmente vrios dom e a a nios. Um ou mais dom nios que compartilham um esquema e um CATALOGO GLOBAL (controlador de dom nio que armazena uma cpia de todos os objetos do AD) so chamados o a de FLORESTA. O primeiro dom nio em uma oresta chamado de DOM e INIO RAIZ da oresta. Se vrios dom a nios na oresta tiverem nomes de dom DNS nio cont guos, essa estrutura ser chamada de ARVORE DE DOM a INIO. No AD, os SITES mapeiam a estrutura f sica da rede, enquanto os dom nios mapeiam a estrutura lgica ou administrativa da organizao. A estrutura do site e a o ca estrutura do dom nio so separadas e ex a veis. Portanto, poss e vel ter dois cenrios distintos: um unico site com mais de um dom a nio; e um unico dom nio
453
com mais de um site. Com a utilizao de dom ca nios, podemos fazer com que nossa rede reita a estrutura de uma empresa. Desta forma, permite se que usurios de um a dom nio acessem recursos localizados em outros dom nios. Algumas caracter sticas prprias de cada dom o nio: Um dom armazena informaes somente dos objetos do prprio dom nio co o nio. Um dom nio possui suas prprias diretivas de segurana. o c Os dom nios do Windows 2000/2003 podem estar nos seguintes modos: Native (Nativo): utilizado em dom nios que possuem somente Controladores de Dom nio (DC) Windows 2000/2003; Mixed (Misto) (padro de instalao): utilizado em dom a ca nios que possuem Controladores de Dom (DC) Windows 2000/2003 e Windows NT. Este nio modo existe para manter compatibilidade com o Windows NT geralmente durante processos de upgrade. Agora que foram denidos os conceitos de rvore e dom a nio, podemos ento a denir UNIDADE ORGANIZACIONAL (Organization Unit - OU). Uma OU uma subdiviso de um dom e a nio que pode ser utilizada para organizar os objetos deste dom nio em um agrupamento lgico para efeitos de administrao. o ca Com a utilizao de unidades organizacionais, poss ca e vel restringir os direitos administrativos apenas em n da Unidade Organizacional sem que, com isso, vel o administrador tenha poderes sobre todos os demais objetos do Dom nio. Vale ressaltar que a infra-estrutura das OUs no deve ser baseada na estrutura ora ganizacional da companhia, mas sim na infra-estrutura da pol tica da rede.
54.3.3
Recursos do Active Directory
Ao utilizar os dom nios baseados no AD, temos os seguintes recursos: Logon unico: com esse recurso, o usurio necessita fazer apenas um logon a para acessar os recursos em diversos servidores da rede, inclusive e-mail e banco de dados;
Conta de usurio unica: os usurios possuem apenas um nome de usurio a a a para acessar os recursos da rede. As contas de usurios cam armazenadas a no banco de dados do AD; Gerenciamento centralizado: com os dom nios baseados no AD, temos uma administrao centralizada. Todas as informaes sobre contas de ca co usurios, grupos e recursos da rede, podem ser administradas a partir de a um unico local no dom nio; Escalabilidade: os dom nios podem crescer a qualquer momento, sem limite de tamanho. A forma de administrao a mesma para uma rede ca e pequena ou grande.
454
54.3.4
Segurana com o Active Directory c
O Active Directory garante um ambiente de diretrio seguro para a organizao, o ca pois usa os recursos internos de autenticao de logon e autorizao de usurios, ca ca a que so os principais recursos da LSA (Autoridade de Segurana Local). O AD a c oferece suporte a vrios protocolos padro da Internet e mecanismos de aua a tenticao usados para comprovar a identidade no logon, incluindo Kerberos ca V5, certicados X.509 v3, cartes inteligentes, infra-estrutura de KPI (chave o pblica) e protocolo LDAP usando a SSL (Secure Sockets Layer). u A autenticao entre dom ca nios ocorre por meio de relaes de conana. co c Conana uma relao estabelecida entre dois ou mais dom c e ca nios que permite aos usurios em um dom a nio serem autenticados por um controlador de outro dom nio. As relaes de conana podem ser transitivas ou intransitico c vas, mas devem sempre estar presentes para que os usurios de um dom a nio tenham acesso aos recursos compartilhados de outro dom nio. As relaes de co conana no Windows NT so diferentes das relaes de conana em sistemas c a co c operacionais Windows 2000/2003. No Windows NT 4.0 e verses anteriores, o as relaes de conana so limitadas a dois dom co c a nios e a relao de conana ca c unidirecional e intransitiva. Todas as relaes de conana em orestas do e co c Windows 2000/2003 so relaes de conana transitivas bidirecionais. Desta a co c forma, se o dom nio X cona no dom nio Y, e Y cona no dom nio W, ento X a tambm cona em W (propriedade transitiva) e W cona em Y que cona em e X (propriedade bidirecional). De uma forma geral, um PROTOCOLO DE CONFIANCA funciona da seguinte maneira. Um controlador de dom nio autentica usurios e aplicativos a usando um destes dois protocolos: Kerberos V5 ou NTLM. O protocolo Kerberos V5 o protocolo padro para computadores que executam o Windows e a 2000/2003. Se algum computador envolvido em uma transao no fornecer suca a porte a Kerberos V5, o protocolo NTLM ser usado. Com o protocolo Kerberos a V5, aps a autenticao, o cliente solicita a um controlador no dom o ca nio de sua conta uma permisso para o servidor no dom a nio conante. Essa permisso a e emitida por um intermedirio de conana do cliente e do servidor. O cliente a c apresenta essa permisso convel ao servidor do dom a a nio conante para que seja autenticada. Quando um cliente tenta acessar recursos de um servidor em outro dom nio usando a autenticao NTLM, o servidor que contm o recurso ca e deve entrar em contato com um controlador de dom nio no dom nio da conta do cliente para vericar as credenciais dessa conta. Alm de proteger o acesso ` rede por meio de autenticao, o AD ajuda e a ca a proteger os recursos compartilhados, pois facilita a autorizao de usurio. ca a Depois que um logon de usurio autenticado, os direitos atribu a e dos ao usurio a atravs de grupos de segurana e das permisses concedidas em relao ao ree c o ca curso compartilhado determinaro se o usurio ter autorizao de acesso ao a a a ca recurso. Ou seja, o AD tambm implementa CONTROLE DE ACESSO (simie lar ao do NTFS). Lembrando que o controle de acesso administrado no n e vel do objeto, por meio da congurao de diversos n ca veis de acesso, ou permisses, o aos objetos, como: Controle Total, Gravao, Leitura ou Sem Acesso. ca
455
54.3.5
Ferramentas de Controle
Vrias ferramentas adicionais que podem ser usadas para congurar, gerenciar a e depurar o Active Directory esto dispon a veis como ferramentas de linha de comando. Essas ferramentas so conhecidas como ferramentas de suporte. As a mais usadas so: Movetree, SIDWalk, LDP, Dnscmd, DSACLS, Netdom, NETa Diag, NLTest, Repadmin, Replmon, DSAStat, ADSI Edit, SDCheck, ACLDiag, DFSUtil, Dcdiag e ADMT.
54.4
IIS - Internet Information Services
O IIS (Internet Information Services) um SERVIDOR WEB criado pela Mie crosoft para seus sistemas operacionais para servidores. Na verdade, para ser mais preciso, ele um conjunto integrado de servios de rede que permite a e c publicao de contedo, disponibilizao de arquivos, e execuo de aplicaes ca u ca ca co em ambientes Intranet, Extranet e Internet. Por padro, o IIS NAO E instalado durante a instalao t a ca pica do Windows 2000/2003 Server. Para instalar o IIS, clique no boto Iniciar >> Painel a de Controle >> Ferramentas Administrativas >> clique em Assistente para congurar o Servidor >> clique em Avanar e Avanar. Para voc comear a c c e c congurar o IIS, clique no boto Iniciar >> Painel de Controle >> Ferramena tas Administrativas >> clique em Gerenciador dos Servios de informaes da c co Internet.
54.4.1
IIS versus Apache HTTP Server
Eles so servidores concorrentes diretos entre si, ento, de certa forma, possuem a a algumas caracter sticas convergentes e outras divergentes. Cada um possui suas fraquezas e foras. Ao longo desta seo, sero feitas as principais comparaes c ca a co entre os dois servidores. Origens O Apache HTTP Server, em sua primeira verso, foi baseado no UNIX httpd a Server. Este desenvolvimento ocorreu durante a primeira gerao da Web. Por ca muitos anos, este servidor esteve bastante atrelado ` plataforma UNIX. A verso a a 1.3, que ainda bastante utilizada, foi a ultima verso que assumia que o sise a tema operacional fosse UNIX ou UNIX-LIKE (Linux, OpenBSD, FreeBSD, Sun Solaris, etc.). Sua verso 2.0 foi reprojetada para abstrair o sistema operacional a utilizado, passando a ser, portanto, um SISTEMA MULTIPLATAFORMA. Isto feito utilizando-se basicamente do Apache Portable Runtime (APR) e e do Multi-Processing Modules (MPMs). Os MPMs so espec a cos para cada plataforma. Por exemplo, para a plataforma Windows, este mdulo baseado o e fortemente no conceito de threads, pois Windows favoresse esse tipo de aplicativo. J no caso da plataforma Linux, seu desenvolvimento baseado fortemente a e em forking process. Sua verso atual a 2.2. a e A Microsoft iniciou a distribuio do IIS a partir do Windows NT 3.51. ca Desde ento, este servidor sempre esteve dispon a vel (no como padro de ina a 456
stalao). Seu desenvolvimento sempre foi e continua sendo focado, unico ca e exclusivamente, na plataforma Windows. Portanto, ele NAO E MULTIPLATAFORMA. Um benef direto desta abordagem a vantagem de se poder cio e implementar uma forte cooperao entre o IIS e o prprio kernel do Windows, ca o o que inuencia e muito em sua performance. IIS na verdade uma coleo de e ca servios, incluindo servidores para: Web, FTP, SMTP e Network News Transfer c Protocol (NNTP). Sua verso atual a 6.0, mas a Microsoft incluir a verso a e a a 7.0 do IIS em sua nova plataforma chamada Windows Longhorn Server. Licenas c O Apache HTTP Server sempre teve e continua tendo seu cdigo aberto. Sua o licena permite seu desenvolvimento e seu uso de forma irrestrita. c Embora o IIS no tenha seu cdigo aberto, ele possui uma licena liberal a o c que garante seu desenvolvimento e uso. Aplicaes Web co O Apache usa por padro a Common Gateway Interface (CGI) para suportar a aplicaes web. Foram criados tambm diversos mdulos para suportar outras co e o linguagens de programao. Portanto, o Apache suporta diversas linguagens, ca tais como: PHP, ASP, Perl, Python, Ruby, C++, etc. Vale ressaltar que devido a sua natureza modular, o Apache pode suportar novas linguagens se necessrio. a O IIS suporta por padro o Active Server Pages (ASP). Pouco se comenta, a mas poss habilitar no IIS a utilizao de outras linguagens como Perl ou e vel ca PHP. Isto se deve ao fato do ASP ser a linguagem preferida pela Microsoft. Depois do lanamento da plataforma .NET em 2002 o IIS ganhou tambm a funo c e ca de gerenciar o ASP.NET. Alm disso, o IIS passou a suportar novos servios, e c como Universal Description, Discovery, and Integration (UDDI) Services, Simple Object Access Protocol (SOAP) e Web Services Description Language (WSDL). De qualquer forma, as opes de linguagens suportadas pelo IIS so menores co a que as suportadas pelo Apache. UDDI uma especicaao que dene um servio de registro para Web e c c Services. Um servio de registro UDDI um Web Service que gerencia inc e formao sobre provedores, implementaes e metadados de servios. Proveca co c dores de servios podem utilizar UDDI para publicar os servios que eles oferec c cem. Usurios de servios podem usar UDDI para descobrir servios que lhes ina c c teressem e obter os metadados necessrios para utilizar esses servios. A especia c cao UDDI dene: APIs SOAP utilizadas para publicar e obter informaes ca co de um registro UDDI; Esquemas XML do modelo de dados do registro e do formato das mensagens SOAP; Denies WSDL das APIs SOAP; Denies co co de registro UDDI (modelos tcnicos - tModels) de diversos sistemas de identie cao e categorizao, que podem ser utilizados para identicar e categorizar ca ca registros UDDI. WSDL uma linguagem baseada em XML utilizada para descrever Web e Services. Na verdade, trata-se de um documento escrito em XML que alm e
457
de descrever o servio, especica como acess-lo e quais so as operaes ou c a a co mtodos dispon e veis. SOAP um protocolo para troca de informaes estruturadas em uma e co plataforma descentralizada e distribu da, utilizando tecnologias baseadas em XML. Sua especicao dene uma framework que prov maneiras para se conca e struir mensagens que podem trafegar atravs de diversos protocolos e que foi e especicado de forma a ser independente de qualquer modelo de programao ca ou outra implementao espec ca ca. Performance Muitos estudos sobre performance tm sido feitos, contudo, seus resultados no e a apontam com clareza qual servidor tem maior performance. Na verdade, tem-se mostrado que o que mais inuencia na performance a qualidade da implee mentao da aplicao Web, indiferentemente se esta sendo executada no IIS ca ca ou Apache. Ambos os servidores oferecem alguns recursos importantes para o quesito performance, a saber: Uso extensivo de cache (o Apache exige um mdulo ` parte para isso); o a Suporte ao GNU zip (gzip), o que reduz signicativamente a largura de banda necessria entre o servidor e o usurio nal; a a Suporte a ltros, o que anula em partes a reduo da performance devido ca ao fato do uso de linguagens interpretadas como ASP, PHP ou Perl; Uso de kernel-level listener para aumentar a performance e escalabilidade. Por padro, o IIS utiliza-se do HTTP.sys que executado em modo sua e per usurio. De forma anloga, contudo no por padro e sim de forma a a a a opcional, o Apache utiliza-se do phhttpd no intuito de obter uma maior performance. Segurana c Com relao ao canal de comunicao, ambos os servidores utilizam o HTTPS ca ca (HTTP over SSL) para a realizao da encriptao dos dados. Portanto, no ca ca a existem grandes diferenas entre os dois servidores com relao ` segurana no c ca a c canal de comunicao. ca
Um outro aspecto da segurana que deve ser analisado a vulnerabilidade do c e prprio host e do Web server. Como o Apache um sistema multiplataforma, o e sua anlise quanto ` segurana no to trivial. Esta responsabilidade ca a a c a e a muito mais associada ao sistema operacional que propriamente ao servidor Web. O Apache geralmente utilizado com os SO UNIX-LIKE, que praticamente em e todos os casos executam o servidor Web em modo usurio. Desta forma, falhas a de segurana no servidor Web acabam no sendo to signicativas ao sistema c a a como um todo. Por outro lado, o IIS s pode ser utilizado com o Windows, o que desde suas primeiras verses bastante conhecido pelas suas falhas de seo e gurana. Mesmo em suas verses mais atuais, devido ` forte colaborao entre c o a ca o Windows e o IIS, via HTTP.sys, seu histrico de vulnerabilidade bastante o e
458
considervel. a Um terceiro aspecto da segurana a ser analisado o controle de acesso a c e contedo. Com relao a este aspecto, ambos os servidores so ecientes. O u ca a Apache tipicamente utiliza o HTTP Basic Authentication (geralmente sobre o SSL) para a realizao das autenticaes. E poss tambm este controle ser ca co vel e gerido pelo prprio administrador local via arquivos de usernames/password, o o que no seria nada modular. Como o Apache altamente modular, uma a e alternativa a isto a sua integrao com o LDAP ou Active Directory (AD). J e ca a o IIS, que altamente integrado ao Windows, oferece autenticao e autorizao e ca ca tipicamente via AD. Autorizaes para URLs especicas tipicamente ocorrem co sobre o sistema ACLs. Cabe ressaltar que em sites dinmicos, a realizao de a ca autorizao e autenticao pode se tornar extremante oneroso. Sendo assim, ca ca geralmente esta responsabilidade passada para a aplicao. e ca Administrao ca Sem dvida a maior diferena entre os dois servidores com relao aos seus u c e ca recursos de congurao e administrao. ca ca A congurao do Apache geralmente feita na mo, editando arquivos em ca e a formato texto. Isto feito tanto em pequenos servidores quanto grandes. A e principal vantagem existente a possibilidade de se utilizar de templates que e automatizam o processo de congurao em vrios servidores em uma Web ca a Farm. Por outro lado, a congurao manual pode se tornar dif se estiverem ca cil sendo congurados mltiplos Web sites. Uma alternativa a utilizao de feru e ca ramentas (Web-based ou GUI-based). Webmin um exemplo quando se estiver e utilizando sistemas UNIX-LIKE. Com relao ao IIS, a administrao sempre feita via console (GUI-based ca ca e Microsoft Management Console snap-in). Este console prove um ambiente comum para a administrao tanto do IIS quando dos diversos servidores (Web, ca FTP, SMTP e NNTP) que o compem. o
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 documentao que contempla administrao do ca ca servidor e publicao de contedos; ca u File Transfer Protocol (FTP) Server: instala o FTP; FrontPage 2000 Server Extensions: instala extenses que possibilitam ado ministrao de Web sites usando o FrontPage e o Microsoft Visual Interca Dev; Internet Information Services Snap-In: instala a ferramenta de administrao principal; ca 459
Internet Services Manager: instala uma verso baseada em browser da a ferramenta de administrao. Por padro, o acesso a este site somente ca a e local; NNTP Service: instala o Network News Transfer Protocol (NNTP). Este servio utilizado na criao e manuteno de newsgroups; c e ca ca SMTP Service: instala o SMTP; Visual InterDev RAD Remote Deployment Support: permite que aplicaes co sema distribu das remotamente; World Wide Web Server: instala o servidor Web.
54.4.3
Principais Recursos do IIS
Um servio que no faz parte do IIS, mas que esto altamente relacionados c a a e o INDEXING SERVICE. Este servidor utilizado na criao de catlogos de e ca a documentos que podem ser buscados dentro de um sistema. Quando este servio c adicionando a um Web site, usurios so capazes de fazer buscas por tpicos e a a o de interesse via formulrios do prprio HTML. a o Exclusivamente com relao ao IIS, os principais recursos disponibilizados ca so: a 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 cabealho HTTP c para determinar o site (pasta no servidor) que o usurio est acessando; a a FTP Restart: permite que downloads via FTP possam ser restabelecidos, em caso de uma eventual desconexo, a partir do ponto anterior; a Active Server Pages (ASP): utilizada juntamente com HTML e Component Object Model (COM) para criao de aplicaes dinmicas e interaca co a tivas baseadas em Web; Application Protection: permite que aplicaes ASP sejam executadas em co espaos separados de memria. Existem trs n c o e veis de proteo: BAIXA ca (in-process), MEDIA (pooled out-of-process) e ALTA (out-of-process);
Process Accounting and Throttling: Process Accounting prove informaes co sobre como certo Web site usa a CPU. Process Throttling permite que o uso da CPU; WebDAV: possibilita que usurios remotos possam publicar, trancar e a administrar recursos usando uma conexo HTTP; a SSL 3.0 and TLS: provem mtodos seguros de troca de informaes entre e co cliente e servidor; Digest Authentication: um dos muitos mecanismos de autenticao suporca tados pelo IIS. Ele o mecanismo que trabalha melhor entre servidores e proxy e rewalls. 460
54.4.4
Principais Diferenas entre IIS4, IIS5 e IIS6 c

IIS4 Windows NT 4.0 32-bit Binary Windows authentication; SSL IIS5 Windows 2000 32-bit Binary Windows authentication; SSL; Kerberos HTMLA; Terminal Services IIS6 Windows Server 2003 32-bit e 64-bit XML Windows authentication; SSL; Kerberos; Passport support Remote Administration Tool (HTML); Remote Desktop SMTP e POP3 IPv4 e IPv6
Plataforma Arquitetura Metabase conguration Segurana c
Administrao ca remota
HTMLA
Suporte a Mail Suporte a IP
SMTP IPv4
SMTP IPv4
Tabela 54.1: Principais Diferenas entre IIS4, IIS5 e IIS6 c
54.5
Terminal Services
Um SERVIDOR congurado para funcionar como terminal services pode suprir diversas necessidades em uma rede de uma organizao. Os benef ca cios de se ter um terminal services sero descritos na prxima subseo. Fundamentalmente, a o ca o princ pio de funcionamento o seguinte. Diversos CLIENTES estabelecem e conexes simultneas com o TERMINAL SERVICES e a partir da enviam soo a mente sinais de teclado e mouse. O terminal services responsvel por todo o e a processamento de aplicaes Windows e por enviar ao cliente, via rede, o sinal co de v deo que permitir a visualizao dos resultados do processamento. a ca Como conseqncia dessa congurao, no h necessidade dos clientes exeue ca a a cutarem o mesmo sistema operacional utilizado no terminal services (Windows). Ou seja, CLIENTES podem estar executando qualquer SO, inclusive os no a baseados em Windows. J o terminal services pode ser instalado basicamente a em Windows NT e Windows 2000/2003 Server (Standard Server, Enterprise Server, e Datacenter Server). Somente o Windows 2000/2003 Web Server no a pode ser congurado como SERVIDOR DE APLICACAO, mas pode ser con gurado para ADMINISTRACAO REMOTA. Durante a instalao do sistema operacional no servidor que funcionar como ca a SERVIDOR DE APLICACAO, fortemente recomendado a utilizao do sis e ca tema de arquivo NTFS. Este sistema prov basicamente os seguintes benef e cios: estabelecimento de cotas para usurios; compresso de parties e arquivos; a a co controle de acesso em n de diretrio e/ou arquivo. vel o
461
As conguraes do terminal services com relao aos parmetros de coco ca a municao podem ser realizadas em quatro n ca veis hierrquicos (descendente): a Group Policies (GPO); Terminal Services conguration; User conguration; Client conguration. Cabe tambm ressaltar que esta tecnologia no somente utilizada pela e a e Microsoft. Por exemplo, o Linux Terminal Server Project trabalha exatamente na questo de possibilitar servidores Linux funcionarem como terminal services. a
54.5.1
Principais Benef cios
E importante notar que, na realidade, esta tecnologia pode ser aplicada e utilizada tanto em clientes quanto em servidores. A seguir, so sintetizados os a mais relevantes benef cios ao se utilizar esta tecnologia. Alguns tpicos dizem o respeito ` utilizao em servidores e outros em clientes. a ca Administrao Remota versus Servidor de Aplicao. O terminal server ca ca (SERVIDOR) pode funcionar nestes dois modos (simultaneamente ou no). a No primeiro modo, ser poss acesso remoto ao servidor (simular ao Rea vel mote Desktop usado em clientes). O segundo modo permite que aplicaes co sejam executadas no servidor e que diversos clientes acessem essa aplicao ca de forma simultnea atravs da rede (este modo instalado como um a e e mdulo a parte do SO). Este recurso especialmente interessante para o e compartilhamento de aplicaes em uma intranet. Uma observao imporco ca tante: algumas aplicaes instaladas antes da congurao e ativao do co ca ca servidor como servidor de aplicao podem no funcionar corretamente. ca a Isto ocorre devido ao fato de aplicaes multiusurios terem requisitos co a diferentes de conguraes; co Construo de redes com clientes sem SO prprio. Geralmente estes ca o clientes so equipamentos pobres, em relao ao hardware. So gerala ca a mente computadores reaproveitados. Eles tambm so chamados de thin e a clients, pois suas conguraes so basicamente: HD AUSENTE, um co a m nimo de RAM, uma placa grca simples, uma placa de rede simples a e interfaces de entrada/sa (teclado, mouse e monitor). Como estes da equipamentos no possuem HD, eles utilizam via rede um unico SO, o do a terminal services. So estabelecidas ligaes necessrias para criaes de a co a co sesses de trabalho no servidor que so vis o a veis e controlveis pelos thin a clients;
Esta tecnologia tambm pode ser utilizada para redirecionamento de divere sos recursos de clientes, tais como: drives de CD, disquete, etc.; clipboard; portas COM; portas LPT; impressoras; sa de udio; etc.; da a Terminal Server Client. Dispon vel para Windows XP Home Edition e Professional Edition instalados em clientes. O Remote Desktop Protocol (RDP) permite acesso a terminal services. Em ambos os SOs, h a dispon vel tambm o Remote Assistance, que possibilita um usurio soe a licitar ajuda a um especialista, que pode assumir o controle da mquina a cliente. Para o Windows XP Professional, h um mdulo adicional, o Rea o mote Desktop, que possibilita o uso de mquinas clientes de forma remota. a 462
54.5.2
Protocolos de Comunicao ca
A tecnologia terminal services suporta diversos protocolos de COMUNICACAO e protocolos de TRANSPOTE. Protocolos podem ser instalados ou desinstalados a qualquer momento. Os protocolos de transporte so aqueles que implementam funcionalidades a das quatro camadas inferiores do modelo OSI (f sica, enlace, rede e transporte). Os principais protocolos suportados so: TCP/IP; NWLink; IPX/SPX; Neta BEUI. Os protocolos de comunicao so aqueles que implementam funcionalidades ca a da camada de aplicao do modelo OSI. Algumas dessas funcionalidades so ca a providas pelos processos de comunicao. Os processos de comunicao suca ca portados pelo terminal services so: named pipes; mail slots; Windows socka ets; remote procedure calls; NetBIOS; NetDDE, server message blocks, DCOM (COM+); SOAP. Um protocolo de comunicao muito importante para a tecnologia terminal ca services o Remote Desktop Protocol (RDP). Ele regulamenta as conexes entre e o terminal services e clientes utilizando como protocolo de transporte somente o TCP/IP. Como o terminal services trabalha de forma ex vel, ou seja, se comunicando atravs de diversas verses de protocolos com clientes que utilizam mais e o variados SOs, se faz necessrio uma troca prvia de parmetros que caracteriza a e a o cliente. Esta troca ocorre no in cio da conexo e os parmetros descrevem a a as capacidades do cliente. Estas capacidades so divididas em grupos: General a Abilities (plataforma e SO do cliente; verso do protocolo; compresso de dados a a suportada); Bitmaps (tamanho da tela; qualidade da cor; compresso bitmap); a Character Commands; Bitmap Cache; Color Table; Panel Activation; Remote Control (habilita a possibilidade do cliente ser controlado remotamente); Cursor (dene propriedades de cor do cursor do mouse). A tabela a seguir resume a evoluo deste protocolo. ca Surgiu com: RDP 5.0 Windows 2000 RDP 5.1 Windows XP 640 x 480 at e 1600 x 1200 pixels (24 bits); Transmisso de udio; a a Redirecionamento de portas COM; Suporte a Smart Cards; Administrao Remota do ca servidor RDP 5.2 Windows Server 2003 Todas as propriedades anteriores com poucas adies, co como reconexo a automtica; transa misso de Windows a key (ALT+TAB, etc.)
Caracter sticas 256 cores (8 bits); Monitoramento Remoto de clientes; Criptograa; com 56 ou 128 bits; Suporte a compresso a e caching (reduz o trco); Conexo a a com impressoras e clipboard no cliente
Tabela 54.2: Evoluo do RDP ca Atualmente, existem dois aplicativos que utilizam o protocolo RDP, o Re463
mote Desktop Connection (RDC) e o Remote Desktop MMC Snap-in. O RDC, aplicativo padro para usurios, substituiu o Windows 2000 Terminal Services a a client e tambm o Client Connection Manager. O Remote Desktop MMC Snape in no um aplicativo para usurio convencionais e sim uma ferramenta para a e a administradores (login de administrador necessrio). Esta ferramenta gerala mente utilizada para manter e administrar diversas conexes com mltiplos e o u servidores.
54.5.3
Licenas c
Para que um servidor funcione corretamente no modo servidor de aplicao, ca algumas licenas devem ser adquiridas. So elas: c a Server License: necessria para a instalao do sistema operacional do a ca servidor; Client Access License (CAL): necessria para que clientes possam se coneca tar ao servidor e utilizarem servios como: compartilhamento de arquivos c e impressoras; e outros servios de redes. Essa licena pode ser obtida c c por usurio ou por dispositivo, o que for mais vantajoso para quem estiver a comprando as licenas; c Terminal Server Client Access License (TS-CAL): necessria para que a clientes possam se conectar ao servidor e utilizarem aplicativos Windows. Essa licena tambm pode ser obtida por usurio ou por dispositivo. c e a Lembrando que a cada conexo, vericado se o usurio ou dispositivo a e a em questo tem sua licena ou no. Esta vericao feita por um servidor a c a ca e de licenas, que pode ser instalado no prprio equipamento que funcionar o c o a servidor de aplicao ou outros equipamentos da organizao, por exemplo, ca ca controladores de dom nio (DCs).
464
Parte XI
Banco de Dados
465
Cap tulo 55
Conceitos Bsicos a
Um sistema de gerncia de banco de dados (SGBD) uma coleo de arquivos e e e ca programas inter-relacionados que permitem ao usurio o acesso para consultas a e alteraes desses dados. O maior benef do banco de dados proporcionar co cio e ao usurio uma viso abstrata dos dados. a a A abstrao de dados se d em trs n ca a e veis: n vel canceitual, n vel lgico e o n f vel sico e sero explicados abaixo. a A capacidade de modicar a denio dos esquemas em determinado n ca vel sem afetar o esquema do n superior, chamado independncia dos dados. A vel e e independncia de dados lgica (alterao no n lgico) mais dif de ser ale o ca vel o e cil canada que a independncia f c e sica, uma vez que os programas de aplicao so ca a mais fortemente dependentes da estrutura lgica dos dados do que de seu acesso. o Como o modelo E-R, explicado com mais detalhes, ` frente, o modelo oria entado a objetos tem por base um conjunto de objetos. Aqui, utilizamos os conceitos de classes, mtodos, etc. Ao contrrio do modelo E-R, cada objeto, e a possui uma unica identidade, independente dos valores neles contidos. Existem trs modelos lgicos com base em registros: e o Modelo Relacional: Usa um conjunto de tabelas para representar tanto os dados como a relao entre eles; ca
Modelo de Rede: Os dados do modelo de rede so representados por um a conjunto de registros e as relaes entre estes registros so representadas co a por links (ligaes), as quais podem ser vistas pelos ponteiros. Os registros co so organizados no banco de dados por um conjunto arbitrrio de grafos; a a Modelo Hierrquico: E similar ao modelo de rede, pois os dados e suas a relaes so representados, respectivamente, por registros e links. A diferena co a c que no modelo hierrquico, os registros esto organizados em rvores. e a a a Uma transao uma coleo de operaes que desempenha uma funo ca e ca co ca lgica unica dentro de uma aplicao do sistema de banco de dados. Exigimos o ca que as transaes no violem nenhumas das regras de consistncia do sistema co a e 466
de banco de dados. E necessrio aceitar inconsistncias temporrias para que as a e a transaes possam ocorrer sem problemas, mas dever ser poss retornar caso co a vel ocorra uma falha, por isso todo SGDB deve conter um sistema de recuperao. ca O arquivo de dados armazena o prprio banco de dados, o dicionrio de dao a dos armazena os metadados relativos ` estrutura do banco de dados. E muito a usado, portanto uma implementao eciente importante. ca e Um projeto de banco de dados envolve as seguintes etapas: Anlise de Requisitos: Processo informal que envolve discusses entre grua o pos de usurios; a Projeto Conceitual: Descrio de alto n dos dados a serem armazenaca vel dos no BD (modelo ER); Projeto Lgico: Escolher um SGDB e converter o projeto conceitual em o um esquema do modelo de dados do SGDB, exemplo: modelo relacional; Renamento do esquema: Identicar potenciais problemas, usando teorias como a normalizao; ca Projeto F sico: Garantir critrios de desempenho, envolve, por exemplo, e a construo de ca ndices para tabelas; Projeto de Segurana: Identicar grupos de usurios e regras entre esses c a grupos e seus acessos `s tabelas. a
467
Cap tulo 56
Abordagem Relacional
56.1 Conceitos
O abordage relacional apresenta basicamente cinco conceitos que so: a Dom nio: Conjunto de valores permitidos para um dado; Atributo: Um item de dado do BD (possui um nome e um dom nio); Tupla: Um conjunto de pares (atributo, valor). Exemplo: (idade, 34); Relao: E um conjunto de tuplas. Composto por um cabealho e um ca c corpo. O cabealho possui um nmero xo de atributos no-amb c u a guos (grau da relao). Corpo um nmero varivel de tuplas (cardinalidade ca e u a da relao) em que a ordem no relevante. ca a Chave: Conjunto de um ou mais atributos de uma relao; ca
56.2
Esquemas e Restries de Integridade co
O esquema de um BD relacional um conjunto de esquemas de relao, S = e ca R1 , ..., Rm . Uma instncia de S um conjunto de relaes BD = r1 , ..., rm , onde a e co cada ri uma instncia do esquema de relao Ri . e a ca A restrio de dom ca nio a condio em que os atributos devem ser aceitos e ca somente dentro de um conjunto especicado, por exemplo: um valor maior que quatro ou um valor diferente de nulo. A restrio de integridade referencial a condio em que desejamos garantir ca e ca que um valor que aparece em uma relao para um dado conjunto de atributos ca tambm aparea para um certo conjunto de atributos de outra relao. Um e c ca conjunto de atributos FK no esquema da relao R1 uma chave estrangeira ca e de R1 que referencia R2 se: 1. os atributos em FK possuem os mesmos dom nios que os atributos da chave primria PK de R2 ; diz-se que os atributos FK fazem referncia ` a e a relao R2 . ca 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] nulo. e Violaes de restries que podem ocorrer: co co 1. inserir(v1,...,vn) pode causar: violao de integridade de identidade (chave prim. nula); ca violao de restrio de chave; ca ca violao de integridade referencial. ca 2. excluir(PK) pode causa violao de integridade refencial. Podemos lidar ca com isso das seguintes maneiras: rejeitar; propagar a excluso; . a modicar os valores dos atributos referenciados para nulo. co 3. atualizao(PK, atributo, novo valor): podem causar as mesmas violaes ca vistas anteriormente quando ou a chave primria ou chave estrangeira so a a atualizadas. Uma assero um predicado que expressa uma condio que desejamos que ca e ca seja sempre satisfeita no banco de dados. Restries de dom co nio e de integridade so casos particulares de asseres. Asseres complexas podem prejudicar a co co o desempenho do banco de dados. Um gatilho(trigger) um comando que executado pelo sistema automatie e camente, em conseqncia de uma modicao no banco de dados. O padro ue ca a SQL-92 no dispe da gatilhos. a o A noo de dependncia funcional generaliza o conceito de superchave. Quando ca e dizemos que uma determinada relao possui a dependncia funcional ca e queremos dizer que para todos os pares de tuplas t1 e t2 , se t1 [] = t2 [] ento a t1 [] = t2 []. Ou seja, se duas tuplas assumem os mesmos valores para o conjunto de atributos ento tambm deve assumir os mesmos valores para o a e conjunto de atributos . A clausura do conjunto dependncias funcionais F e e denotada por F + e inclui as dependncias funcionais logicamente impl e citas.
469
Cap tulo 57
Modelagem Entidade Relacionamento

57.1 Conceitos
Nesta etapa, nos movemos de uma descrio informal do que os usurios desejam ca a para uma descrio formal. Os conceitos mais importantes so: ca a Entidade: Objeto do mundo real disting de outros objetos, descrita uvel e utilizando um conjunto de atributos; Conjunto de Entidades: Uma coleo de entidades similares. Exemplo: ca todos os funcionrios; a Chave Superchave: o conjunto de um ou mais atributos que, tomados colee tivamente, nos permite identicar de maneira un voca uma entidade em um conjunto de entidades; Candidata: superchave em que nenhum subconjunto superchave; e Primria: chave candidata denida pelo projetista do BD para idena ticar as entidades; Estrangeira: atributo de um conjunto de entidades que chave primria e a de outro conjunto de entidades; Relacionamento: Associao entre duas ou mais entidades; ca Conjunto de Relacionamentos: Coleo de relacionamentos similares; ca Atributo Descritivo: registram informao sobre o relaciomento; ca Atributo Multivalorado: quando mais de um valor pode ser inserido, por exemplo, um funcionrio pode ter vrios dependentes e pode-se criar um a a atributo multivalorado para colocar o nome de cada um desses dependentes.
470
57.2
Cardinalidade
Um para um: uma entidade em A est associada a no mximo uma entia a dade em B. Um para muitos: uma entidade em A est associada a qualquer nmero a u de entidades em B. Muitos para muitos: uma entidade em A est associada a qualquer nmero a u de entidades em B e uma entidade em B est associada a qualquer nmero a u de entidades em A.
57.3
Representao Grca ca a
Conjunto de entidades: retngulos; a Atributos: elipses; Conjunto de relacionamentes: losangos; Atributos multivalorados: elipses duplas;
Figura 57.1: Um Diagrama Entidade Relacionamento
57.4
Recursos do Modelo Entidade Relacionamento
Conjunto de Entidades Fracas: no possui chave primria, mas o idena a ticador composto juntamente com a chave primria de um conjunto e a de entidades dominante (forte). Esse identicador chamado de chave e parcial (pname). Essa relao feita atravs de um relacionamento idenca e e ticador. Por exemplo, um pedido de compra pode possuir vrios itens, a mas cada um desses itens est associado a somente um pedido de compra. a Poderia-se associar um identicador parcial para cada item em relao ao ca seu pedido. A chave parcial poder ser formada entre esse identicador a parcial e a chave primria do conjunto de entidades que representa o pea dido. O relacionamento um para muitos e conjunto de entidades fracam e tem paticipao total (todo item est associado a um pedido). ca a
471
Especializao: no caso de um conjunto de entidades que possuem subca grupos de entidades, pode-se realizar a especializao fazendo que esses ca subconjuntos tenham os mesmos atributos do conjunto de entidades principal mais atributos espec cos para o subconjunto que no compartilhado a e com outros subconjuntos. E como se fosse uma herana. c Generalizao: Difere da especializao no sentido de como feito o proca ca e jeto. Na generalizao, o projetista procura atributos em comum para ca formar um conjunto de entidades pai. A representao no diagrama a ca e mesma (uso do losango ISA). Agregao: Permite-nos tratar um conjunto de relacionamento como um ca conjunto de entidades com o propsito de permitir a participao em outo ca ros relacionamentos.
472
Cap tulo 58
Normalizao ca
58.1 Aspectos desejveis em um bom projeto a
Considere o seguinte caso: queremos fazer um relatrio que representa um peo dido de compra, gostar amos de obter os nomes dos produtos, seu volume, seu peso e os seus preos e suponha que algum tenha pensado num esquema de c e item de um pedido da seguinte maneira: item(quantidade, nome do produto, volume, peso, preo). Sabemos que um determinado produto ter sempre o c a mesmo volume e o mesmo peso. Dizemos que h redundncia nesse caso, j que a a a poder amos criar outro esquema produto (id produto, volume, peso) e associarmos id produto como chaves estrangeira em item. Acabamos de realizar o que chamado de decomposio. Decomposies descuidadas, entretanto, podem e ca co gerar outro tipo de projeto de m qualidade. Podemos recuperar a relao dea ca sejada por meio da operao de juno natural (natural join), mas pode ocorrer ca ca que a resposta alcanada tenha mais tuplas do que realmente deveria ter, devido c a uma m decomposio (decomposio com perda de juno). a ca ca ca Um conjunto de esquemas de relaes R1 , R2 , ..., Rn uma decomposio de co e ca R se R = R1 R2 ... Rn . Assim, sempre vlido que r r1 r2 ... rn . e a Seja R um esquema de relao e F um conjunto de dependncias funcionais ca e sobre R. Sejam R1 e R2 formas de decomposio de R. Essa decomposio ca ca e uma decomposio sem perda de juno de R se ao menos uma das seguintes ca ca dependncias funcionais est em F + : e a
R1 R 2 R 1 R1 R 2 R 2 . Outro aspecto que desejamos para o banco de dados a preservao de e ca dependncia. O sistema deve checar se uma atualizao no banco de dados e ca criar uma relao ilegal (que no satisfaa todas dependncias funcionais). a ca a c e
58.2
Forma normal de Boyce-Codd
Uma relao do esquema R est na FNBC (forma normal de Boyce-Codd) com ca a respeito a conjunto F de dependncias funcionais se todas as dependncias fune e 473
cionais em F + da forma , em que R e R atendem ao menos uma das exigncias abaixo: e uma dependncia funcional trivial (isto , ). e e e uma superchave para o esquema R. e
58.3
Terceira forma normal
Podemos aceitar uma forma normal mais fraca chamada teceira forma normal (3FN). Essa forma normal permite dependncias funcionais no-triviais. e a Uma relao do esquema R est na 3F N com respeito a conjunto F de ca a dependncias funcionais se todas as dependncias funcionais em F + da forma e e , em que R e R atendem ao menos uma das exigncias abaixo: e uma dependncia funcional trivial. e e uma superchave para o esquema R. e Cada atributo de A em est contido em uma chave candidata de R. a Todo esquema F N BC tambm 3F N . Nem todo FNBC preserva as dee e pendncias funcionais, j em um projeto 3F N sempre poss garatir as dee a e vel pendncias funcionais e que as decomposies so sem perda de juno. Entree co a ca tanto, na 3F N pode haver repetio de informao e uso de valores nulos para ca ca representarmos um relacionamento entre itens de dados, mas mesmo assim e menos pior do que no garantir a preservao de dependncia. a ca e
474
Cap tulo 59
Transformao do Modelo ca Conceitual

Conjunto de entidades fortes: uma coluna para cada um de seus atributos; Conjunto de entidades fracas: uma columa para cada um de seus atributos mais as colunas que compreendem os atributos que formam a chave primria do conjunto de entidades dominantes; a Conjunto de Relacionamentos: Formado pelos seus atributos descritivos e pelas chaves primrias de cada uma das entidades participantes; a Um conjunto de Relacionamento que possui a cardinalidade muitos para um ou um para um e no possui atributos descritivos no precisa ser representado a a em tabela. Por exemplo, no caso de um relacionamento entre um conjunto de entidades fraca e um conjunto de entidades forte, a chave primria do conjunto a de entidades forte funciona como um atributo no conjunto de entidades fraca (chave estrangeira).
475
Cap tulo 60
Linguagem SQL
60.1 Criao de tabela ca
Uma nova tabela pode ser criada especicando o seu nome juntamente com os nomes das colunas e seus tipos de dado: CREATE TABLE clima ( cidade varchar(80), temp_min int, temp_max int, prcp real, data date );
-- temperatura mnima -- temperatura mxima a -- precipita~o ca
O comando INSERT utilizado para carregar as linhas da tabela: e INSERT INTO clima VALUES (S~o Francisco, 46, 50, 0.25, 1994-11-27); a 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~o Francisco, 43, 57, 0.0, 1994-11-29); a
60.2
Consultas
Para ver os dados de uma tabela, a tabela deve ser consultada. O comando SELECT do SQL utilizado para esta funo. Por exemplo, para ver todas as e ca linhas da tabela clima digite: SELECT * FROM clima Pode ser especicada qualquer expresso arbitrria na lista de seleo. Por a a ca exemplo, pode ser escrito SELECT cidade, (temp_max+temp_min)/2 AS temp_media, data FROM clima
476
Operadores booleanos arbitrrios (AND, OR e NOT) so permitidos na quala a icao da consulta. Por exemplo, o comando abaixo obtm o clima de So ca e a Francisco nos dias de chuva: SELECT * FROM clima WHERE cidade = S~o Francisco a AND prcp > 0.0; Pode ser desejado que os resultados da seleo retornem em uma determica 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 chamado de juno externa (outer join). As consultas e ca vistas anteriormente so junes internas (inner join). O comando ento ca a co a assim: SELECT * FROM clima LEFT OUTER JOIN cidades ON (clima.cidade = cidades.nome); Tambm poss fazer a juno da tabela consigo mesmo. Isto chamado e e vel ca e de autojuno (self join). ca
60.3
Funes de agregao co ca
Existem funes de agregao para contar (count), somar (sum), calcular a co ca mdia (avg), o valor mximo (max) e o valor m e a nimo (min) para um conjunto de linhas. Como exemplo, podemos obter a maior temperatura m nima 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 no funciona porque a funo de agregao max no pode ser usada na a ca ca a clusula WHERE (esta restrio existe porque a clusula WHERE determina a ca a as linhas que vo passar para o estgio de agregao e, portanto, precisa ser a a ca avaliada antes das funes de agregao serem computadas). Entretanto, uma co ca forma correta a subconsulta abaixo: e SELECT cidade FROM clima WHERE temp_min = (SELECT max(temp_min) FROM clima); As agregaes tambm so muito uteis quando combinadas com a clusula co e a a GROUP BY. Por exemplo, pode ser obtida a maior temperatura m nima observada em cada cidade com SELECT cidade, max(temp_min) FROM clima GROUP BY cidade; Cada resultado da agregaao calculado sobre as linhas da tabela corresponc e dendo a uma cidade. Estas linhas agrupadas podem ser ltradas utilizando a clusula HAVING a SELECT cidade, max(temp_min) FROM clima GROUP BY cidade HAVING max(temp_min) < 40; E importante compreender a interao entre as agregaes e as clusulas ca co a WHERE e HAVING do SQL. A diferena fundamental entre WHERE e HAVc ING esta: o WHERE seleciona as linhas de entrada antes dos grupos e e agregaes serem computados (portanto, controla quais linhas iro para o comco a puto da agregao), enquanto o HAVING seleciona grupos de linhas aps os ca o grupos e agregaes serem computados. Portanto, a clusula WHERE no co a a pode conter funes de agregao; no faz sentido tentar utilizar uma agregao co ca a ca para determinar quais linhas sero a entrada da agregao. a ca
60.4
Atualizaes e excluses co o
As linhas existentes podem ser atualizadas utilizando o comando UPDATE. Suponha que foi descoberto que as leituras de temperatura esto todas mais a altas 2 graus aps 28 de novembro de 1994. Estes dados podem ser corrigidos o da seguinte maneira: UPDATE clima SET temp_max = temp_max - 2, WHERE data > 1994-11-28; temp_min = temp_min - 2
478
Suponha que no estamos mais interessados nos dados do clima em Hayward. a Ento precisamos excluir suas linhas da tabela. As excluses so realizadas a o a utilizando o comando DELETE: DELETE FROM clima WHERE cidade = Hayward;
60.5
Vises o
Suponha que a consulta combinando os registros de clima e de localizao das ca cidades seja de particular interesse para sua aplicao, mas que voc no deseja ca e a digitar esta consulta toda vez que necessitar dela. Voc pode, ento, criar uma e a viso baseada na consulta, atribuindo um nome a esta consulta pelo qual a e poss referenci-la como se fosse uma tabela comum. vel a 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 no sero inseridas linhas na tabela clima sem que a a haja uma entrada correspondente na tabela cidades. Isto chamado de manter e a integridade referencial dos dados. As declaraes para as tabelas cariam co 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
Cap tulo 61
Conceitos de Datawarehousing e Bussiness Inteligence

61.1 Banco de Dados Multidimensionais
Os BDs Multidimensionais so altamente otimizados para minimizar o tempo a de consulta e apresentao. Os dados extra ca dos dos sistemas fontes so gravados a diversas vezes em vetores ou arraysordenadamente de forma que a realizao ca da consulta seja implementada como uma simples varredura de uma parte de um vetor. O BD Multidimensional tambm possui um conjunto de funes e co matemticas que podem ser estendidas e que so executadas dinamicamente ` a a a varredura dos registros. Com isso, o sistema trabalha com arquivos temporrios a menores, reduzindo drasticamente o tempo de I/O. Claro que a manuteno destas estruturas ordenadas so muito mais deca a moradas que num BD convencional. Mas como as atualizaes so realizadas co a periodicamente (de ms em ms, geralmente) e o seu tempo no cr e e a e tico ao n de aplicao (no importa para o usurio se a carga levou 24h, mas sim vel ca a a que a consulta levou menos de 10 min), no existe grande preocupao com o a ca tempo de atualizao dos dados. ca
Alm de j guardarem os dados de forma ordenada, os BDs Multidimene a sionais, tambm se utilizam de estruturas auxiliares de consulta que guardam e o resultado de consultas anteriores armazenados em disco e apenas consultam os registros novos que no foram consultados na pesquisa anterior, gerando um a incremental. Exemplo: em 01/02/2001 foi realizada uma consulta que demonstrava o nmero de produtos vendidos por cidade e ms da venda. Para fazer esta u e consulta o banco de dados teve que varrer todos os meses e todas as cidades que tiveram vendas. Quando esta consulta realizada novamente em 01/04/2001. e O BD em vez de varrer tudo de novo, apenas procura pelos registros de vendas de Fevereiro e Maro e utiliza os valores gerados na consulta de 01/02/2001 que c foram armazenadas em um arquivo de consulta.
480
Outra estrutura de consulta muito utilizada a gerao de diversos n e ca veis de granularidade das informaes. Isto , quando o usurio faz uma consulta como co e a a citada no exemplo acima, o BD em vez de fazer os agrupamentos somente ao n vel de Cidade e Ms ele dispara simultaneamente agrupamentos por Bairro, e Estado, Semana e Trimestre, supondo que a prxima consulta a ser disparada o pelo usurio seja uma operao de Drill Down ou Roll UP. a ca Varias outras estratgias de minimizar o tempo de consulta existem, mas os e dois tipos de estratgias apresentadas: consulta incremental e em vrios n e a veis de granularidade so as mais comumente utilizadas hoje em dia. a Bancos de dados multidimensionais so sistemas proprietrios que no seguem a a a padres (linguagem, API) estabelecidos pela indstria de banco de dados. Isto o u se torna uma desvantagem para tais sistemas, uma vez que a arquitetura no a e aberta.
61.1.1
Modelagem Multidimensional
O modelo multidimensional visa facilitar a compreenso do estruturamento dos a dados armazenados tanto para desenvolvedores quanto para os usurios do sisa tema. Neste tipo de modelo existem trs elementos bsicos: os fatos, as die a menses e as medidas ou variveis. o a Fato uma coleo de itens de dados compostos de dados de medidas e de e ca contexto. O fato reete a evoluo dos negcios do dia-a-dia e representado ca o e por valores numricos. E implementado em tabelas denominadas tabelas de fato e (fact tables). Dimenses so os elementos que participam de um fato. Elas determinam o o a contexto de um assunto de negcios. As dimenses normalmente no possuem o o a valores numricos, pois so somente descritivas e classicatrias dos elemene a o tos que participam de um fato. Um Datawarehouse que analisa vendas de um produto (fato) poderia ter as seguintes dimenses: tempo, localizao, clientes, o ca vendedores. As dimenses podem ser compostas por membros que podem conter hieraro quias. Membros (atributos) so as poss a veis divises ou classicaes de uma o co dimenso. A dimenso tempo poderia ser dividida nos seguintes membros: ano, a a trimestre e ms e a dimenso localizao em: cidade, estado e pa e a ca s. As Medidas (variveis) so os atributos numricos que representam um fato a a e e sobre eles que so feitas as anlises do negcio. So por exemplo, o valor e a a o a em reais das vendas, o nmero de unidades vendidas, o custo da venda. Uma u medida determinada pela combinao das dimenses que participam de um e ca o fato, e esto localizadas como atributos de um fato. a Para facilitar o entendimento, o modelo multidimensional representado e pelo desenho de um cubo. Todavia, o nmero de dimenses geralmente maior u o e 481
que trs, o que sugere um hipercubo. Como um hipercubo algo dif de se e e cil representar ` literatura utiliza geralmente como referncia somente o cubo. A a e gura 61.1 mostra um cubo para a medida vendas.
Figura 61.1: Abordagem Dimensional representada por cubos Utilizando a abstrao da organizao da informao em um cubo, podemos ca ca ca denir mais facilmente as quatro operaes bsicas OLAP: co a Drill Down: consiste em detalhar o n dos dados, navegar do mais alto vel n vel at o dado detalhado. Exemplo: Em vez de ver as vendas anuais, e passar a ver as vendas trimestrais. Ou em vez de ver as vendas por estado, ver por cidade; Roll UP: operao inversa da Drill Down. Navegao do n de detalhe ca ca vel para o mais alto n de sumarizao de dados; vel ca Slice: operao de corte do cubo, mantendo a mesma perspectiva de viso. ca a A idia selecionar apenas algumas dimenses ou membros de dimenses. e e o o Exemplo: analisar somente as vendas do Estado de So Paulo, no intervalo a de 1998 at 2001; e Dice: mudana da perspectiva de viso. Pode simplesmente ser a alterao c a ca da posio das linhas pelas colunas numa tabela, ou a apresentao dos ca ca dados de trs para frente (2001, 2000,1999 em vez de 1999, 2000, 2001). a Ou operaes mais complexas que mostram a variabilidade de uma medida co ao longo das diferentes instanciaes de uma ou mais dimenses. co o Dois modelos multidimensionais comuns so: o esquema estrela e o ocos de a neve (snowake). No esquema estrela existe uma tabela dominante no centro do esquema. Esta a unica tabela com mltiplos relacionamentos para as oute u ras tabelas. As outras tabelas possuem um unico relacionamento para a tabela central. A tabela central chamada fato (fact table) e as outras tabelas so e a chamados de dimenso (dimension table). A gura 61.2 ilustra o esquema esa trela. Como j dissemos uma dimenso pode conter uma ou mais hierarquias que a a podem ser decompostas em tabelas separadas, gerando uma estrutura conhecida por snowake. A gura 61.3 ilustra uma estrutura snowake.
482
Figura 61.2: Modelo Estrela
Figura 61.3: Modelo Snowake Na verdade, snowake signica a normalizao da tabela. Isto elimina ca redundncia e diminui o espao em disco. Mas, em um datawarehouse, rea c dundncia no importante porque no um ambiente transacional, operaes a a e a e co de update no ocorrem com freqncia. Espao f a ue c sico tambm irrelevante e e porque a tabela de fato que ocupar a maior parte deste espao. e a c Para uma boa performance do esquema estrela, importante determinar o e n de consolidao, ou a granularidade, dos fatos. O fato pode estar no n vel ca vel de transao, por exemplo, a venda individual de determinado produto, ou o ca fato pode ser armazenado com uma consolidao maior, como por exemplo, a ca venda de determinada linha de produtos em um dia. Armazenando o fato ao n de transao faz com que o tamanho da tabela fato se torne excessivo e, vel ca alm disso, este n de detalhamento pode ser de pouca utilidade. e vel
61.2
Datawarehousing
Um datawarehouse (ou armazm de dados, ou depsito de dados) um sistema e o e de computao utilizado para armazenar informaes relativas `s atividades de ca co a uma organizao em bancos de dados, de forma consolidada. O desenho da ca base de dados favorece os relatrios, a anlise de grandes volumes de dados e o a a obteno de informaes estratgicas que podem facilitar a tomada de deciso. ca co e a O datawarehouse possibilita a anlise de grandes volumes de dados, coletaa dos dos sistemas transacionais (OLTP). So as chamadas sries histricas que a e o possibilitam uma melhor anlise de eventos passados, oferecendo suporte `s a a
483
tomadas de decises presentes e a previso de eventos futuros. Por denio, os o a ca dados em um datawarehouse no so volteis, ou seja, eles no mudam, salvo a a a a quando necessrio fazer correes de dados previamente carregados. Os dados e a co esto dispon a veis somente para leitura e no podem ser alterados. A ferramenta a mais popular para explorao de um datawarehouse a Online Analytical Proca e cessing OLAP ou Processo Anal tico em Tempo Real, mas muitas outras podem ser usadas. Os datawarehouse surgiram como conceito acadmico na dcada de 80. Com e e o amadurecimento dos sistemas de informao empresariais, as necessidades de ca anlise dos dados cresceram paralelamente. Os sistemas OLTP no conseguiam a a cumprir a tarefa de anlise com a simples gerao de relatrios. Nesse contexto, a ca o a implementao do datawarehouse passou a se tornar realidade nas grandes ca corporaes. O mercado de ferramentas de datawarehouse, que faz parte do co mercado de Business Intelligence, cresceu ento, e ferramentas melhores e mais a sosticadas foram desenvolvidas para apoiar a estrutura do data warehouse e sua utilizao. ca Atualmente, por sua capacidade de sumarizar a analisar grandes volumes de dados,o datawarehouse o ncleo dos sistemas de informaes gerenciais e e u co apoio ` deciso das principais solues de business intelligence do mercado. a a co Um Datawarehouse caracterizado como uma coleo de dados orientada a e ca assunto, integrada, no-voltil e variante no tempo que auxiliam nas decises a a o de gerenciamento. Datawarehouses fornecem acesso aos dados para anlises a complexas, descoberta de conhecimento e tomada de decises. Algumas caraco ter sticas importantes dos datawarehouses so: a Orientada ao assunto: pois o objetivo tomar decises sobre o assuntoe o tema dos dados; Integrada: pois deve consolidar dados de diferentes origens ou fontes; No voltil: pois as informaes j presentes no banco so raramente a a co a a modicadas (sobrescrita). Os novos dados so absorvidos pelo banco, a integrando-se com as informaes previamente armazenadas; co Variante no tempo: pois deve-se manter um histrico dos dados, pero mitindo comparaes ao longo do tempo. co
Tipicamente o datawarehouse mantido separadamente dos bancos de dados e operacionais de uma organizao. Existem muitas razes para fazer isto. Um ca o datawarehouse suporta requerimentos funcionais e de performance para consultas OLAP (abordagem dimensional para o suporte ` deciso), os quais so a a a bastante diferentes de aplicaes online transaction processing (OLTP) tradico cionalmente suportadas por banco de dados operacionais. Aplicaes OLTP co tipicamente automatizam tarefas de processamento de dados do dia a dia tais como ordem de entrada de produtos e transaes bancrias que so processadas co a a durante todo o dia, dia aps dia. Estas tarefas so estruturadas e repetitivas, e o a consistem de transaes curtas, atmicas e isoladas. co o
484
Estas transaes requerem detalhes, dados atualizados, leitura e atualizao co ca de poucos (dezenas de) registros que so acessados tipicamente por suas chaves a primrias. Bancos de dados operacionais tendem a ter tamanho de centenas de a megabytes a gigabytes. Consistncia e capacidade de recuperao do banco de e ca dados so cr a ticas e a maximizao da vazo de transaes so mtricas chaves ca a co a e de performance. Conseqentemente, o banco de dados projetado para reetir u e a Semntica operacional de aplicaes conhecidas e, em particular, minimizar a co conitos de concorrncia. e Datawarehouse, em contraste, dirigido a suporte a deciso. Dados histricos, e a o sumariados e consolidados so mais importantes que dados detalhados em rega istros individuais. J que o datawarehouse contm dados consolidados gerala e mente a partir de muitos banco de dados operacionais, sobre muitos per odos de tempo, eles tendem a serem maiores que os banco de dados operacionais. Datawarehouse de empresas so projetados para ter tamanho de centenas de gia gabytes a terabytes. O trabalho pesado de um datawarehouse so as consultas a intensivas na maioria das vezes ad hoc (consultas complexas que podem acessar milhes de registros e realizar muitas buscas por registros), unies e agregaes. o o co Vazo de consulta e tempo de resposta so mais importantes que vazo de a a a transaes. Para facilitar anlises e visualizaes complexas, os dados em um co a co datawarehouse so tipicamente modelados multidimensionalmente. Por exema plo, em um datawarehouse de vendas, tempo de vendas, lugar de vendas, vendedor e produto podem ser algumas dimenses de interesse. Freqentemente, estas o u dimenses so hierrquicas, o tempo pode ser organizado na hierarquia dia-mso a a e trimestre-ano, produto como produto-categoria-indstria (marca) para facilitar u e ampliar o dom nio de consultas que podem ser feitas no Datawarehouse. O modelo estrela, oco de neves so dois exemplos de esquemas multidimensionais a com os quais um datawarehouse pode ser modelado.
61.3
OLTP, OLAP, MOLAP, ROLAP e HOLAP
OLTP ` E um acrnimo de Online Transaction Processing ou Processamento de a o transaes em tempo-real. So sistemas que se encarregam de registrar todas co a as transaes contidas em uma determinada operao organizacional, ou seja, co ca e uma aplicao que tem como caracter ca stica principal muitas atualizaes em daco dos operacionais. Por exemplo: sistema de transaes bancrias registra todas co a as operaes efetuadas em um banco. Os ERPs (Enteprise Resource Planning) co so sistemas que se enquadram nessa categoria. a OLAP ` E um acrnimo de Online Analitical Processing ou Processamento a o anal tico em tempo-real. E a categoria de tecnologia de software que capacita os analistas, gerentes e executivos a conseguir obter discernimento nos dados atravs de um acesso rpido, consistente e interativo, para uma larga variedade e a de possibilidades de vises da informao que vm a ser transformada a paro ca e tir de dados cruspara reetir o real dimensionamento da corporao como ca entendido pelo usurio. A funcionalidade OLAP caracterizada pela anlise a e a dinmica multidimensional dos dados consolidados da corporao, dando sua ca porte `s atividades de anlise e navegao do usurio nal. A funcionalidade a a ca a 485
OLAP implementada em um modo cliente/servidor multi-usurio, e oferece e a consistentemente rpidas respostas para consultas, apesar do tamanho e coma plexidade do banco de dados. Ela ajuda o usurio a sintetizar as informaes da a co corporao atravs de vises comparativas e personalizadas, assim como atravs ca e o e de anlises de histricos e projees de dados em vrios modelos de cenrios do a o co a a tipo what-if. Alguns exemplos de consultas t picas de OLAP so: Quais os a produtos mais bem vendidos no ms passado? Quais os 10 piores vendedores e do departamento X? Qual a mdia salarial dos funcionrios de informtica na e a a regio sul nos ultimos 5 anos? dentre outras. a Caracter sticas Operao T ca pica Granularidade Idade dos Dados Recuperao ca Orientao ca Modelagem Usurios a OLTP Transao ca Atmico o Presente Poucos Registros Registro Processo Muitos OLAP Anlise a Agregado Histrico, Atual e Projetado o Muitos Registros Arrays Assunto Poucos
Tabela 61.1: OLTP vs. OLAP Quanto ` localizao dos dados a serem utilizados na anlise, atualmente a ca a 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 anlise. a Sistemas OLAP que implementam a primeira abordagem so chamados de a MOLAP (Multidimensional OLAP) e aqueles que implementam a segunda so a chamados ROLAP (Relational OLAP). ROLAP ` OLAP Relacional. Sistemas ROLAP fornecem anlise multidia a 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 mltiplos passos e as tabelas u temporrias necessrias para o devido processamento das consultas; a a Executar comandos SQL para recuperar os dados, mas fazer todo o processamento (incluindo joins e agregaes) no servidor OLAP. co Alm das caracter e sticas bsicas de sistemas OLAP, servidores ROLAP dea vem tambm: e Utilizar metadados para descrever o modelo dos dados e para auxiliar na construo das consultas. Desta maneira um analista pode executar suas ca anlises utilizando seus prprios termos; a o 486
Criar comandos SQL otimizados para os bancos de dados com o qual trabalha. A principal vantagem de se adotar uma soluo ROLAP reside na utilizao ca ca de uma tecnologia estabelecida, de arquitetura aberta e padronizada como a e relacional, beneciando-se da diversidade de plataformas, escalabilidade e paralelismo de hardware (SMP e MPP). Quanto `s limitaes, pode-se citar o pobre a co conjunto de funes para anlise, a inadequao do esquema estrela para atuco a ca alizao dos dados e as soluoes proprietrias para metadados que acaba por ca c a anular muitas das vantagens do uso da tecnologia relacional. MOLAP ` OLAP multidimensional. MOLAP uma classe de sistemas que a e permite a execuo de anlises bastante sosticadas usando como gerenciador ca a de dados um banco de dados multidimensional. Em um banco de dados MOLAP, os dados so mantidos em arranjos e indexados de maneira a prover um a o timo desempenho no acesso a qualquer elemento. A indexao, a antecipao ca ca da maneira como os dados sero acessados e o alto grau de agregao dos dados a ca fazem com que sistemas MOLAP tenham um excelente desempenho. Alm de e serem rpidos, outra grande vantagem desses sistemas o rico e complexo cona e junto de funes de anlise que oferecem. co a HOLAP ` O armazenamento HOLAP (OLAP H a brido) uma combinao e ca dos tipos de armazenamento MOLAP e ROLAP. Os dados de agregao so ca a armazenados em MOLAP, enquanto os dados de base so deixados no banco de a dados relacional.
61.4
Outros conceitos importantes
Data Mart: um subconjunto de um data warehouse. E um repositrio e o de dados extra dos das fontes operacionais ou de um data warehouse que e projetado para servir as necessidades particulares de um grupo espec co. Na prtica, o data ware house e data mart pode trabalhar juntos. O data a warehouse atende as necessidades estratgicas da organizao, enquanto e ca o data mart atende as necessidades gerenciais mais a n vel operacional. Quando os data mart atualiza seus dados atravs do data warehouse, ele e considerado de dependente. Quando ele atualiza os dados atravs das e e fontes operacionais, ele considerado independente; e Agregaes: Grande parte dos usurios no est interessada em realizar co a a a uma consulta que retorne uma grande quantidade de linhas de uma tabela de fatos, mas sim em sumarizar os resultados usando operaes de soma ou co mdia por exemplo. Para evitar que as mesmas operaes sejam realizadas e co a cada vez que um usurio execute uma consulta, importante realizar a e um levantamento das agregaes e sumrios nos quais os usurios esto co a a a interessados; Funcionamento (Fluxo de dados). Os dados para serem usados para ns anal ticos devem ser transformados e carregados dos sistemas OLTP para
487
o Data Warehouse. Durante essas transformaes (realizadas pelas ferco ramentas ETL Extrair, Transformar e Carregar) so criados resumos e a agregaes entre esses dados, transformando-os em informaes de mais co co alto n e mais signitivas para os analistas, gerentes e executivos; vel Metadados: so os chamados dados sobre os dados. E um mapeamento a dos dados do modo como foram extra dos das fontes operacionais e como esto inseridos no data warehouse. Os metadados denem e descrevem a os dados de negcio (valor aos dados) e os tipos de dados (denies de o co tabelas, atributos, dom nio e relaes). Os metadados so geralmente co a armazenados em repositrios separados ao alcance dos usurios; o a Granularidade: o n e vel de detalhe contido nas unidades de dados existentes no data warehouse. A granularidade importante porque pode e diminui o tempo de acesso aos dados que realmente interessam e diminuem a quantidade de discos rpidos e caros necessrios para armazenar a a uma grande quantidade de dados histricos. o
488
Parte XII
Administrao de Bancos ca de Dados Relacionais
489
Cap tulo 62
Gerncia de Transaes e co
Uma transao a unidade lgica de processamento, e pode incluir uma ou mais ca e o operaes sobre o Banco de Dados. Para garantir a correo, uma transao co ca ca deve ser executada at o nal. As duas operaes bsicas fornecidas por um e co a banco de dados so READ e WRITE. As fronteiras de uma transao podem a ca ser denidas explicitamente na aplicao atravs das chamadas BEGIN TRANSca e ACTION e END TRANSACTION. Entende-se por transaes concorrentes aquelas que so executadas ao mesmo co a tempo e pelo menos uma operao de WRITE executada por alguma das ca e transaes. A possibilidade de existir transaes sendo executadas de forma co co concorrente faz com que o SGBD utilize tcnicas para realizar o controle de e concorrncia. Uma vez iniciado o processamento da transao, o SGBD deve e ca garantir que ela ser executada at o nal e os resultados sero armazenados a e a de forma permanete. No entanto, durante a execuo de uma transao podem ca ca ocorrer falhas como crash do sistema, falhas no disco, catstrofes. Isso faz com a que o SGBD tenha que utilizar tcnicas de Recuperao em caso de falhas. e ca Para efeitos e recuperao so utilizadas as seguintes operaes sobre as ca a co transaes: co BEGIN TRANSACTION - Marca o in da transao; cio ca READ/WRITE - Executa operaes como parte da transao; co ca
END TRANSACTION - Especica o m das operaes de leitura e escrita; co COMMIT TRANSACTION - Conrma o succeso da transao; ca ROLLBACK - Indica que ocorreram problemas com a transao. ca Alteraes devem ser desfeitas. As transao podem ainda se encontrar em co ca cinco estados que so: (1)Ativa; (2)Parcialmente Conrmada; (3)Conrmada; a (4)Falha; (5)Terminada. As propriedades desejveis de uma transao devem ser: a ca
490
Atomicidade: Garantir que sero executadas at o m; a e Consistncia - Devem levar o Banco de Dados de um estado consistente e para outro tambm consistente; e Isolamento - A execuo de uma transao no deve ser prejudicada por ca ca a transaes concorrentes; co Durabilidade - As alteraes realizadas por uma transao conrmada co ca devem ser persistitas no Banco de Dados. Estas quatro propriedades so usualmente referenciadas como ACID. a Quando vrias transaes so executas simultaneamente, as instrues de a co a co cada transao podem ser intercaladas. A atribuio da ordem dessas instrues ca ca co conhecido como escala de execuo. E responsabilidade do SGDB escolher uma e ca escala que deixe o banco de dados em estado inconsistente. As unicas operaes co signicativas de uma transao, do ponto de vista da escala de execuo, so ca ca a suas instrues de leitura e escrita. co Considere uma escala de execuo com duas instrues sucessivas Ii e Ij , ca co das transaes Ti e Tj , respectivamente. Se Ii e Ij referem-se a itens de dados co diferentes, ento podemos alternar Ii e Ij sem afetar os resultados de qualquer a instruo da escala. J quando se referem aos mesmos dados temos os seguintes ca a casos: 1. Ii = read(Q), Ij = read(Q): a seqncia no importa; ue a 2. Ii = read(Q), Ij = write(Q): a ordem importa, pois se Ii vier depois de Ij , Ii ir ler o valor escrito por Ij ; a 3. Ii = write(Q), Ij = read(Q): a ordem importa, por razes semelhantes a o anterior; 4. Ii = write(Q), Ij = write(Q): a ordem importa, no afeta as transaes a co Ti e Tj , entretanto, o valor obtido pela prxima instruo de leitura sobre o ca Q ser afetado. a Dizemos que Ii e Ij entram em conito caso a ordem importe. Se uma escala de execuo puder ser transformada em outra por uma srie de trocas de inca e strues no-conitantes, dizemos que essas escalas de execuo so equivalentes co a ca a em conito. Dizemos que uma escala conito serializvel se ela equivalente e a e em conito ` uma escala seqencial (uma escala que contm as instrues de a u e co cada transao agrupadas). E poss ca vel ter duas escalas de execuo que proca duzam o mesmo resultado, mas que no sejam equivalentes em conito. a
491
Cap tulo 63
Controle de Concorrncia e
Entende-se por transaes concorrentes aquelas que desejam executar ao mesmo co tempo e pelo menos uma operao de WRITE precisa ser realizada. O SGBD ca responsvel por garantir o acesso mutuamente exclusivo a um item de dados e a qualquer. Em outras palavras, enquanto uma transao acessa um item de dado, ca nenhuma outra poder modic-lo. A forma mais simples de se implementar a a o controle de concorrncia a utilizao de mecanismos de bloqueio baseados e e ca em locks binrios, atravs das operaes bsicas lock e unlock, que devem ser a e co a aplicadas antes e depois da realizao de uma operao qualquer (READ ou ca ca WRITE) sobre qualquer item de dados. Os locks binrios tem o incoveniente de no permitir que duas ou mais a a transaes que desejem realizar operaes apenas de leitura acessem o item sico co multaneamente. Isso diminui o desempenho do sistema, uma vez que muitas transaes tem que aguardar na la de espera por acesso a um item de daco dos. Para contornar esse problema, um outro mecanismo de lock baseado em 3 operaes foi criado. Quando um transao deseja aenas ler um item, ela realiza co ca uma operao read lock, permitindo que outras transaes que desejem apenas ca co ler o mesmo item tambm possam executar simultaneamente. Se uma operao e ca deseja escrever, deve primeiro executar uma operao do tipo write lock. Nenca huma operao de leitura ou escrita pode ser realizada por outra transao sobre ca ca um item que esteja bloqueado para escrita. A operao unlock deve ser aplicada ca aps o termino das operaes de leitura ou escrita por parte das transaes que o co co detem o lock de um item.
E comum que uma transao deseje mudar o tipo de lock que possui soca bre um determinado item. Esta operao chamada de converso de lock. Se ca e a apenas uma transao possuir o read lock, ela pode atualiz-lo para write lock. ca a Uma transao que possua um write lock pode convert-lo para read lock aps ca e o terminar suas operaes de escria. Essa operaes so tambm chamadas upco co a e grade e downgrade. Os locks binrios e os locks read/write embora garantam a exclusividade a mtua, no podem garantir a serializao na execuo de transaes concoru a ca ca co rentes. Um outro protocolo que visa solucionar os dois problemas o chamado e Two-Phase Locking (2PL). As fases so: (i) Crescimento (Growning) e (ii) Ena 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 a possibilidade de ocorrncia e e de deadlocks. Um protocolo de preveno de deadlocks baseado em timesca e tamps, que so identicadores unicos associados a cada transao. Outras duas a ca tcnicas para identicao e preveno de deadlocks so timeouts e grafos (Waite ca ca a For Graphs). Protocolos baseados em timestamps tambm podem ser utilizados e para controle de concorrncia. Os valores do timestamp para um dado item X e so: readTS(X ) e writeTS(X). Eles indicam a ultima leitura e escrita realizadas a sobre o item X respectivamente. Uma outra tcnica para controle de Concorrencia basea-se em guardar vale ores antigos de um determinado item. Procolos que se utilizam dessa tcnica e so chamados Multiverso. Operaes de leitura que antes em outros protocolos a a co no seriam permitidas, podem ser realizadas fornecendo-se a verso antiga de a a um item de dado. O principal encoveniente desta tcnica a necessidade de e e mais espao em disco. c A granularidade de um item de dado tambm exerce grande inuncia no dee e sempenho de operaes de controle de concorrncia. Por exemplo, uma transao co e ca que deseja realizar operaes sobre um resgistro, pode tornar ineciente o conco trole de transaes se bloquear inadequadamente um bloco f co sico inteiro. Protocolos que determinam tipo de bloqueio de acordo com a granularidade so a chamados Multiple Granularity Lockig (MGL).
493
Cap tulo 64
Gerncia de Desempenho e
O Design f sico do Banco de Dados o processo de escolha das estruturas de e armazenamento e mtodos de acesso de forma que um bom desempenho possa e ser atingido pelas diversas aplicaes. Cada SGBD oferece uma diversidade de co opes de organizao de arquivos e mtodos de acessos especiais como co ca e ndices, clustering de registros relacionados, encadeamento de registros relacionados usando ponteiros, e funes hash. Os critrios utilizados que guiam a escolha das co e opes de design f co sico so o Tempo de Rsposta, a Utilizao do Espao e o a ca c Throughput de Transaes. O desempenho das estruturas e mtodos de acesso co e 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 nmero u de registros por arquivo. A maioria dos SGBDs possuem ferramentas de monitorao que coletam esca tat sticas de desempenho, que so mantidas no Catlogo do Sistema (System a a Catalog). As informaes dizem respeito, por exemplo, ` nmero de chamadas co a u de transaes ou queries, atividade de I/O por arquivo, nmero de pginas por co u a arquivo, nmero de regsitros por u ndice e frequncia de utilizao dos e ca ndices. Assim que os requisitos do sistema mudam, pode se tornar necessrio adicionar a ou remover tabelas, reorganizar aquivos (mudar mtodo de acesso primrio), e a dropar ndices antigos e criar novos. Exemplos de atividades importantes no design f sico de um Banco de Dados: (i)Anlise de Transaes de de Queries - Envolve determinar arquivos ena co volvidos, atributos mais acessados, atributos utilizados em operaes de JOIN, co e determinao de operaes predominantes (SELECT, UPDATE, INSERT, ca co DELETE); (ii)Estimativa da Frequncia das Chamadas de Transaes e Queries e co - Geralmente para um grande volume de processamento, vlida a regra infore a mal que diz que 80% do processamento gasto com 20% das transaes e queries; e co (iii)Restries de Tempo - Identicar das restries de tempo de transaes e co co co queries; (iv)Restries de Unicidade de Atributos - Devem ser estabelecidos co mtodos de acesso para todas as chaves candidatas ou conjunto de chaves candie datas (ex: PK ou UNIQUE), tendo por objetivo otimizar os testes de unicidade. Os ind ces primarios e de clustering esto diretamente relacionados com a a 494
ordenao f ca sica dos registros no disco. Portanto, pode ser denido no mximo a um ndice deste tipo. Embora o desempenho das operaes de consulta seja co otimizado com a utilizao de ca ndices, importante ressaltar que a existncia e e de ndices representa um overhead signicativo nas operaes de insero, atuco ca alizao e excluso. Para consultas baseadas em multiplos campos, podem ser ca a denidos ndices mltiplos, ou seja, baseado em 2 ou mais campos. u Indices do tipo clustering so especialemte uteis em consultas envolvendo intervalo (range a queries). Os ndices baseados em B+Trees so uteis para pesquisas em intera valos e testes de igualdade, enquanto os ndices baseados em funes hash so co a extremamente ecientes para testes de igualdade, podendo otimizar bastante operaes de JOIN. co Uma outra estratgia utilizada para otimizao em Bancos de Dados a e ca e Desnormalizao. Essa tcnica consiste em armazenar o banco de dados em uma ca e forma normal mais fraca como a 1NF ou 2NF, introduzindo algumas depedncias e funcionais que no existiriam nas formas BCNF ou 4NF. Essa tcnica se baseia a e em eliminar a necessidade de operaes de JOIN, de forma que consultas posco sam ser respondidas acessando o menor nmero de arquivos poss u veis. Outras duas tcnicas que podem ser utilizadas so o Particionamento Vertical, que cone a siste na diviso de um tabela e mltiplas tabelas de colunas iguais, porm com a u e um nmero menor de linhas por tabela, e o Particionamento Horizontal, que u consiste em transformar uma relao R(K, A, B, C, D, ...) em mltiplas relaes ca u co R1 (K, A, B), R2 (K, C, D), R3 (K, ...). As tcnicas de particionamento so intere a ressantes pois no sacricam a forma normal da relao original. a ca Alguns cuidados adicionais podem ser tomados para garantir o bom desempenho do sistema. A utilizao da operao DISTINCT causa uma operao de ca ca ca ordenao, e portanto muito custosa. Clusulas DISTINC redundantes devem ca e a ser eliminadas. Deve-se ter cuidado com a utilizao de tabelas temporrias, ca a porm em casos especias elas podem ser uteis. e SELECT SSN FROM EMPLOYEE E WHERE SALARY = SELECT MAX (SALARY) FROM EMPLOYEE AS M WHERE M.DNO = E.DNO No caso acima, a utilizaao de uma tabela temporria pode impedir que c a o clculo do salrio mximo por departamento seja realizado para todos os a a a 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 no so capazes de determinar em qual a a ordem as tabelas que aparecem na clusula FROM devem ser varridas, e utilizam a na execuo a ordem em que elas aparecem na clusula. Portanto importante ca a e que se organize as tabelas de forma que as tabelas menores sejam varridas enquanto as tabelas maiores sejam indexadas de forma adequada. Condies co OR na clusula where podem inibir a utilizao de a ca ndices, portanto a estratgia e 495
ser tomada separar a querie em duas, forando a utilizao do e c ca ndice, e realizar uma operao UNION na sequncia. As operaes IN, =ALL, =ANY, =SOME ca e co devem ser substitu das por operaes do tipo JOIN sempre que poss co vel. Processamento de consultas so atividades envolvidas em extrair dados de a um banco de dados. O custo do processamento de uma consulta principalmente e determinado pelo acesso ao disco. Os passos envolvidos no processamento de consultas so: a 1. Anlise sinttica e traduo; a a ca 2. Otimizao; ca 3. Avaliao. ca O processo de traduo semelhante ` tarefa de um analisador sinttico em ca e a a um compilador. A otimizao, geralmente, ca a cargo do SGDB, no caso do ca modelo relacional. J para os modelos de rede e hierrquico, a otimizao ca a a ca a cargo do programador. Um plano de execuo de consulta um conjunto de ca e operaes primitivas que so usadas para avaliar uma consulta. Os diferentes co a planos de execuo podem possuir diferentes custos. A otimizao de consultas ca ca o processo de selecionar o plano de execuo mais eciente para uma cone ca sulta. Um aspectos de otimizao envolve a procura de expresso mais eciente ca a no n de lgebra relacional, mas diversas outras estratgias so importantes vel a e a como a escolha de um algoritmo para ser usado na execuo de uma operao ca ca e a escolha de ndices a usar. Para escolher diferentes planos de execuo, o otimizador deve estimar o ca custo de cada plano de avaliao. Os otimizadores de consulta usam informaes ca co estat sticas armazenadas em um catlogo e incluem: a Nmero de tuplas de cada relao; u ca Nmero de blocos que contm as tuplas de cada relao; u e ca Nmero de bytes de uma tupla para uma certa relao; u ca Nmero de valores distintos que aparecem numa relao para um deteru ca minado atributo; Nmero mdio de registros que satisfazem uma condio de igualdade para u e ca um determinado atributo. Podemos processar consultas que envolvem selees simples por meio da exco ecuo de uma varredura linear, de uma procura binria ou do uso de ca a ndices. Podemos tratar as selees complexas computando unies e interseces dos reco o co sultados de selees simples. Podemos ordenar relaes maiores que a memria co co o usando o algoritmo do merge-sort externo. Uma juno pode ser calculada por ca 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
Cap tulo 65
Administrao de Bancos ca de Dados Oracle

65.1
65.1.1
Arquitetura de um Servidor Oracle

Estruturas em memria o
Para operar, uma instncia Oracle aloca uma srie de reas de cache em memria a e a o para armazenar trs estruturas que so o SGA (System Global Area), o PGA e a (Program Global Area) e as Sort Areas. O SGA uma rea unica de memria e a o compartilhada composta por trs componentes principais que so: e a Database Buer Cache (DBBC): o DBBC uma rea de memria que e a o armazena os blocos de dados lidos do disco. Quando um processo necessita de acessar dados do banco ele primeiro consulta essa rea de memria. a o Todas as operaes sobre os dados do banco so realizadas nessa rea co a a antes de serem persistidas em disco. No Oracle, a pol tica de substituio ca de blocos utilizada a LRU (Last Recently Used ); e Shared Pool: o shared pool uma rea compartilhada que armazena ine a formaes sobre as instrues SQL enviadas pelos processos usurio (texto co co a do comando, planos de execuo etc.) e informaes sobre o dicionrio de ca co a dados (nome das tabelas, colunas, tipos, privilgios etc.); e
Redo Log Buer: buer circular que contm informaes sobre as modie co caes efetuadas no banco de dados. O redo log buer uma das estrturas co e utilizadas para realizar a recuperao do banco de dados. E importante ca ressaltar que o redo log buer utilizado apenas para recuperao e no e ca a para operaes de rollback; co J o PGA, em um sistema single-threaded, uma rea de memria no coma e a o a partilhada utlizada par guardar informaes de controle para um unico processo. co O PGA armazena informaes como arrays, estado de cursores e informaes soco co bre seses de usurios. Quando trata-se de um sistema multi-threaded (MTS), o a as informaes sobre sesses de usurios so guardadas em uma outra rea co o a a a chamada UGA (User Global Area), que alocada no shared pool. e
498
A Sort Area uma rea de memria compartilhada alocada especialmente e a o para realizao de operaes que exigem ordenao, como SORT BY, GROUP ca co ca BY e DISTINCT. Quando o tamanho da Sort Area no suciente, a operao a e ca de ordenao realizada em disco, em uma tablespace chamada TEMP. ca e Duas outras estruturas de memria tambm tm muita importncia na aro e e a quitetura Oracle. A primeira delas o Java Pool, que dene a quantidade de e memria que pode ser alocada pela JVM (Java Virtual Machine). A segunda o dela o Large Pool, que utilizada para operaes de backup, recuperao, e e co ca entre outras. Em alguns casos, pode ser utilizada para operaes de ordenao. co ca
65.1.2
Processos server
Os processos server so recebem as requisies dos processos user, realizam o a co parse das instrues SQL, vericam as permisses de acesso do usurio, traz os co o a dados do disco para o DBBC, caso necessrio, e retorna os dados para o usurio. a a Um processo server pode ser dedicado para um processo user (dedicated server process) ou compartilhado entre mltipos processos user (shared server process). u Os processos server compartilhados s so poss o a veis em sistemas multi-threaded.
65.1.3
Processos user
As funes desempenhadas pelos processos user so se conectar com os processos co a server, enviar instrues SQL e receber os resultados. Caso o servidor suporte co processos server compartilhados, diversos processos server podem ser atendidos por um mesmo processo server.
65.1.4
Processos em Background
Ao contrrio dos processos server, os processo em background no realizam a a nenhuma comunicao com os processos user. Os processos em backgound so ca a responsveis pelas tarefas de apoio para garantir o funcionamento do sistema a de gerenciamento de banco de dados como um todo. Um sistema Oracle tem inmeros processos em background, porm apenas 4 deles so obrigatrios que u e a o so: a Process Monitor (PMON): Realiza a recuperao quando algum processo ca falha, alm de liberar o cache, locks e demais recursos que o processo e estava utilizando; System Monitor (SMON): Realiza o processo de recuperao da instncia ca a durante o processo de inicializao, limpa segmentos temporrios que no ca a a esto mais em uso, recupera transaes terminadas de forma anormal e a co realiza desfragmentao nos arquivos de dados para facilitar a alocao; ca ca Database Writer (DBWR): A funo principal do DBWR escreve os ca e blocos de dados modicados (dirty) do DBBC para o disco. Isso feito e nas seguintes situaes: (i) quando a lista de blocos modicados atinge um co tamanho congurado; (ii) quando o processo percorre um quantidade congurada de blocos e no encontra nenhum bloco livre; (iii) quando ocorre a
499
um timeout; (iv) quando ocorre um checkpoint ou (v) quando o DBWR recebe um sinal do processo LGWR. Dessa forma, o processo DBWR alm e de garantir que as aleraes feitas em buer sero persistidas, tambm co a e gerencia o espao em buer para melhorar o desempenho do banco; c Log Writer (LGWR): E o responsvel por copiar as informaes do redo log a co buer para o o redo log le (arquivo de log com a mesma estrutura do redo log buer). O LGWR tambm resposvel por atualizar os headers dos e e a arquivos de dados quando ocorre um checkpoint. O LGWR disparado e nas seguintes situaes: (i) quando ocorre um commit; (ii) quando ocorre co um checkpoint; (iii) quando ocorre um timeout ou (iv) quando o redo log buer atinge um tero de sua capacidade. c Alm desses quatro, o Oracle possui uma srie de outros processos em backe e ground que so de instalao e uso opcionais. Os mais importantes so os a ca a seguintes: CKPT: Atualiza os headers dos arquivos de dados quando ocorre um checkpoint. A utilizao desse processo pode ajudar a melhorar o desemca penho do sistema permitindo que o processo LGWR se concentre apenas na cpia do redo log buer para o disco; o RECO: Responsvel pela recuperao de falhas envolvendo transaes disa ca co tribu das. Esse processo necessrio quando o Oracle est rodando de e a a forma distribu da; ARCH: E o responsvel por copiar o redo log le (que um buer circular) a e para um dispositivos de armazenamento oine para que os logs no sejam a perdidos; Pnnn: E o processo responsvel pela execuo de consultas paralelas; a ca SNPn: Controla a replicao de objetos dos banco de dados em outro site. ca Essas cpias so cahamadas snapshots. Esse processo pode ser escalonado o a para executar periodicamente; LCKn: Realiza o controle de locks entre mltiplas instncias; u a Dnnn: Esse processo funciona como um dispatcher quando o sistema est a utilizando processos server compartilhados. E necessrio um dispatcher a para cada protocolo de comunicao utilizado. ca
65.1.5
Arquivos
Em conjunto, O SGA e os processos em background formam uma intncia Ora acle. O banco de dados propriamente dito formado por trs tipos de arquivos e e que so: a Datales: Armazenam as tabelas e ndices do banco; Redo Log Files: Armazenam os logs do sistema. Esse arquivo consiste de um buer circular assim como o redo log buer. O processo LGWR o e responsvel por copiar os logs em memria para este arquivo; a o 500
Control Files: Este um arquivo binrio que descreve a estrutura e o e a status do banco de dados. Contm a identicao dos arquivos de log e de e ca dados, o nome do banco e informaes de sincronismo entre os arquivos co que o compe. o Embora na arquitetura do Oracle o banco de dados seja composto somente por esses trs arquivos, uma srie de outros arquivos so importantes para coloe e a car uma intncia no ar. Exemplos desses arquivos so: a a Parameter File: Arquivo texto que contm todos os parmetros necessrios e a a para colocar uma instncia do Oracle no ar, por exemplo, quantidade de a memria alocada para o SGA, nome e localizao de arquivos de controle, o ca tamanho de buers e de blocos etc; Alert File: Arquivo de log onde so registrados os erros ocorridos (proa cesso, blocos corrompidos, deadlock etc.), tarefas administrativas alm dos e valores de parmetros de incializao no momento que a instncia posta a ca a e no ar; Trace File: Arquivo de log onde so armazenadas informaes delatalhadas a co sobre os problemas ocorridos. A utilizao desse arquivo opcional; ca e
65.2
Arquitetura Oracle de Armazenamento de Dados
Um banco de dados composto por uma ou mais tablespaces. Uma tablespace e contm um ou mais arquivos no n de sistema operacional. Cada tablespace e vel pode ter um ou mais segmentos. Um segmento adicionado na tablespace e quando uma tabela ou um ndice criado, ou seja, um segmento associado a e e cada objeto de banco de dados. E poss que um objeto seja atribu a mais vel do de um segmento, mas, para isso, o usurio dever particionar explicitamente o a a objeto. Vrias tabelas ou a ndices podem ser inclu dos em um mesmo segmento atravs da criao de um objeto conhecido como cluster. e ca A medida que um objeto de banco de dados necessita de mais espao, c e necessrio que o segmento aloque mais dados. O banco de dados procura, nos a arquivos do tablespace, reas cont a guas de tamanho pr-determinado para o e armazenamento de novos dados. Essa rea cont a gua conhecida como extenso e a (extent), que por sua vez formada por diversos blocos de banco de dados. Cada e bloco de banco de dados possui um tamanho xo determinado nos parmetros a de congurao, esse tamanho xo deve ser mltiplo do tamanho de um bloco do ca u n do sistema operacional. O tamanho extent tambm pode ser congurado vel e pelo usurio ou determinado automaticamente pelo Oracle. a
65.3
65.3.1
Tratamento de Transaes no Oracle co

Gerenciamento do Redo Log
O Redo Log a estrutura mais crucial para as operaes de recuperao. Cada e co ca instncia possui um Redo Log para proteg-la em caso de falha. Como explia e cado anteriormente, o processo LGWR responsvel por copiar para o disco o e a 501
contedo do redo log buer em determinadas situaes, como em um COMMIT u co por exemplo. Essa escrita feita de maneira circular. Quando no houver mais e a espao para escreve no arquivo de Redo Log atual, o LGWR comea a escrever c c no prximo arquivo. Caso esteja no ultimo arquivo do buer, o LGWR voltar o a a escrever no primeiro arquivo. E poss vel congurar o banco de dados para arquivar as informaes escritas nos arquivos de redo. Com essa congurao, co ca o processo ARCH ser ativado. a Um log switch o ponto quando o banco de dados para de escrever em um e arquivo de Redo Log e comea a escrever em outro. Um log switch tambm c e pode ser forado pelo DBA e pode ser congurado para ocorrer em intervalos c regulares. O Oracle atribui, para cada arquivo de Redo Log, um log sequence number toda vez que um log switch ocorre. A ordem atribu pelos log sequence da numbers utilizada na recuperao do banco de dados em caso de falha. e ca
65.3.2
Checkpoints
A um tempo espec co, todos os dados do database buer cache modicados so a escritos em disco pelo processo DBWR; este evento chamado de checkpoint. O e processo CKPT responsvel para informar ao processo DBWR o momento de e a gravar os dados em disco. O DBWR tambm atualiza os arquivos de controle e do banco de dados para indicar o mais recente checkpoint. O processo CKPT opcional; se ele no estiver presente, o LGWR assume sua responsabilidade. e a No momento do checkpoint a falta de sincronismo entre o DBBC e os arquivos de redo eliminada. Os eventos em que um checkpoint ocorre so: e a A cada log switch. Aps ocorrido um certo tempo desde o ultimo checkpoint (LOG CHECKo POINT TIMEOUT). Quando a instncia sofre um shutdown, a menos que ela seja abortada. a Quando forada pelo DBA. (ALTER SYSTEM CHECKPOINT) c Quando uma tablespace colocada oine com pelo menos um arquivo e (datale) online.
65.3.3
Segmentos de rollback
Um segmento de rollback uma poro de um banco de dados que registra as e ca aes das transaes dos usurios nos dados para que possam ser desfeitas sob co co a certas circunstncias. a Um segmento de rollback usado para permitir a consistncia da leitura, ree e cuperar um comando quando ocorre o dead-lock, recuperar uma transao at ca e uma certa marca identicada por um SAVEPOINT (marcador para instrues co no conrmadas), recuperar uma transao terminada por uma falha de proa ca cesso de um usurio e desfazer todas as transaes pendentes durante a recua co perao de uma instncia. ca a Todas as operaes de atualizao de dados em um banco de dados envolvem co ca os segmentos de rollback para permitir a consistncia da leitura, a recuperao e ca das informaes e permitir que uma transao ou um comando sejam desconco ca siderados ou desfeitos. 502
65.3.4
Consistncia de leitura e
O Database Buer Cache organizado em duas listas: a dirty list e a least e recently used list (LRU). A dirty list uma lista que contm os blocos alterados e e que ainda no foram escritos em disco. A LRU uma lista que contm blocos a e e do ORACLE que foram alterados pelos comandos dos usurios mas ainda no a a foram gravados em disco. Contm ainda blocos livres e blocos em uso. Assim, e quando um processo servidor precisa ler um bloco de dados do disco para a memria, ele: o 1. Pesquisa nas listas LRU e dirty list pelo bloco de dados desejado. 2. Caso esse bloco de dados no seja localizado, o processo servidor pesquisa a 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 no gravados nos arquivos de dados, de acordo com a a localizao de cada um deles, durante o processo de pesquisa de um bloco ca livre. 4. Finalmente, o processo servidor efetua uma cpia do bloco de dados do o disco para um bloco livre. 5. Esse procedimento termina quando o processo servidor localiza um bloco livre ou se um nmero espec u co de blocos forem pesquisados sem encontrar 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 espao em memria para c o os novos blocos de dados que precisam ser manipulados pelos comandos dos usurios. a
65.4
Congurao do Servidor ca
A criao de um banco de dados pode ser realizada atravs de uma ferramenta ca e grca conhecida como Database Conguration Assistant. Com essa ferramenta a tambm poss e e vel congurar opes de um banco de dados existente, deletar co um banco de dados e gerenciar gabaritos de banco de dados. As etapas so as a seguintes:
Etapa 1 Em uma tela, ser poss escolher se desejado criar um banco de a vel e dados, congurar ou deletar um j existente ou gerenciar gabaritos. Nesse a caso, ser criado um banco de dados. a Etapa 2 Ser poss a vel escolher sobre qual gabarito se deseja basear o banco de dados a ser criado. H como escolher gabaritos otimizados para data a warehouse, processamento de transaes ou para uso geral. co Etapa 3 Ser atribu o Nome do Banco de Dados Global, pelo qual o banco a do de dados identicado exclusivamente. Alm disso, ser necessrio idene e a a ticar o nome de uma instncia para o banco de dados que est sendo a a criado. 503
Etapa 4 Ser necessrio selecionar se deseja que o banco esteja em Modo Servia a dor Dedicado ou em Modo de Servidor Compartilhado. No primeiro caso, cada conexo cliente atendida um processo servidor para atender soa e mente a esse cliente. No segundo caso, ser poss a vel para um processo servidor atender mais de uma conexo cliente. a Etapa 5 Nessa etapa, os parmetros de inicializao relacionados ` memria, ` a ca a o a localizao dos arquivos de congurao e ao conjunto de caracteres sero ca ca a congurados. Etapa 6 Ser congurado o armazenamento do banco de dados, atravs de uma a e tela ser poss congurar arquivos de controle, tablespaces, arquivos de a vel dados, segmentos de rollback e grupos de redo logs. Etapa 7 Na ultima etapa, haver a opo de criar o banco de dados ou, sim a ca plesmente, utiliz-lo como gabarito. a
65.5
Tipos de Usurios Oracle a
Os tipos de usurios (papis) variam de acordo com o lugar, mas podem ser dia e vididos em administadores de banco de dados, responsveis pela segurana, ada c ministradores de rede, desenvolvedores de aplicao, administradores de aplicao ca ca e usurios do banco de dados. a
65.5.1
Administradores de banco de dados
Cada banco de dados requer no m nimo um DBA (database administrator ). As suas responsabilidades incluem: Instalao e atualizao dos servidores de banco de dados Oracle e das ca ca ferramentas de aplicao. ca Alocao de espao para o sistema e planejamento de futuras necessidades. ca c Criao de estruturas de armazenamento primrias do banco de dados ca a (tablespaces). Criao e alterao de objetos primrios: tabelas, vises etc. aps os ca ca a o o desenvolvedores terem projetado a aplicao. ca
Administrao de usurios, controle de acesso e segurana do sistema. ca a c Garantia do atendimento aos termos da licena Oracle e contato direto c com o suporte tcnico da Oracle. e Monitorao e otimizao do desempenho do banco de dados. ca ca Planejamento e execuo de backup e de restaurao das informaes do ca ca co banco de dados.
504
65.5.2
Outros ppeis a
Responsvel pela segurana E um papel que existe somente em alguns caa c sos. Pode assumir as responsabilidades de administrao de usurios, ca a controle de acesso e segurana do sistema. c Administradores de redes Responsveis em administar os produtos de rede a da Oracle como os servios de rede da Oracle. c Desenvolvedores de aplicao Entre as atividades desse papel, pode-se destacar: ca o projeto e desenvolvimento da aplicao e o projeto da estrutura do banco ca de dados bem como os requisitos necessrios em relao ao espao de ara ca c mazenamento necessrio. a Administradores de aplicao Cada aplicao deve ter um administrador ca ca de aplicao, que ser responsvel por ela. ca a a Usurios do banco de dados Responsveis pela criao, modicao e deleo a a ca ca ca de dados quando permitidos, alm da obteno de realatrios atravs do e ca o e dados.
505
Cap tulo 66
Administrao de Bancos ca 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 f sico de um conjunto de objetos de esquema de um banco de dados em um ou mais arquivos f sicos. Os bancos de dados podem ser classicados como bancos de dados de sistemas e bancos de dados dos usurios. Os banco de dados de sistema a armazenam dados do sistema e tambm controlam o armazenamento temporrio e a requerido para os dados de aplicao. ca Cada instncia do SQL Server pode suportar vrios bancos de dados. Alm a a e disso, pode haver vrias instncias em um mesmo computador. Cada banco de a a dados pode suportar grupos de arquivos (legroups), que provem a funcionalie dade de distribuir os dados sicamente. Um banco de dados pode possuir vrios a legroups, mas o contrrio no poss a a e vel. Aps a criao do banco de dados, os o ca legroups do banco de dados podem ser adicionados. Por padro, o SQL Server instala os seguintes bancos de dados: a Modelo um template para os outros banco de dados. Tempdb para armazenamento temporrio, como as operaes de ora co denao. ca
Msdb suporta o agente do SQL Server, com tarefas agendadas, alertas e informaes sobre replicao. co ca Adventure Works e AdventureWorksDW opcionais, so banco de dados a de exemplos.
66.1.1
Catlogos de sistema a
Cada banco de dados Oracle executa em catlogo de sistema centralizado, ou a dicionrio de dados, que reside na tablespace SYSTEM. No caso do SQL Server a 2005, cada banco de dados mantm seu catlogo de sistema, que possui ine a formaes relacionadas, por exemplo, `: objetos do banco de dados (tabelas, co a
506
ndices, procedimentos, vises, triggers etc.), restries, usurios, permisses e o co a o Tipos de dados denidos pelo usurio. a As informaes relativas ao n co vel do sistema so armazenadas no Master a Database (Msdb). Essas informaes incluem, por exemplo: contas de login, co valores de congurao, mensagens do sistema, nomes dos bancos de dados e a ca localizao dos arquivos primrios de cada banco de dados. ca a Ateno, no SQL Server 2005, os objetos do sistema no so armazenados ca a a 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 so os a checkpoints. O SQL Server periodicamente gera checkpoints automaticamente em cada banco de dados. Outro processo em background importante o Lazywriter que unico para e e cada instncia. O lazywriter adormece um intervalo de tempo e ento acorda a a para checar o espao livre na lista do buer. Caso esse espao livre esteja abaixo c c de um certo ponto (dependente do tamanho do cache), o processo lazywriter procura pginas no utilizadas no buer cache e escreve as pginas com write a a a dirty que no foram recentemente referenciadas em disco. a Um processo conhecido como ResourceMonitor utilizado para controlar o e restante do caches, pois o lazywriter s controla as pginas de dados. o a
66.2
Arquitetura SQL Server de Armazenamento de Dados
O SQL Server utiliza a unidade bsica de IO xo (pgina) em 8KB. Para ora a ganizar melhor os dados, essas pginas so agrupadas em uma quantidade de a a oito cont guas entre si formando as chamadas extenses (extents). O espao o c e gerenciado em termos de extenses. Cada pgina pertence a um objeto de um o a tipo (dado, ndice etc), mas uma extenso pode pertencer a vrios objetos. a a Uma extenso em que as oito pginas pertencem ao mesmo objeto consida a e erada uma extenso uniforme, caso contrrio, trata-se de uma extenso mista. a a a O SQL Server utiliza os legroups para controlar a alocao das tabelas e dos ca ndices. Os dados contidos em legroup so proporcionalmente distribu a dos entre os arquivos do legroup. Se os legroups no estiverem denidos, os objetos do a banco de dados sero armazenados em um legroup padro que implicitamente a a e denido durante a criao do banco de dados. ca Os segmentos utilizados no Oracle no so necessrios no SQL Server. Em a a a vez disso, o SQL Server distribui os dados atravs de RAID suportado em harde ware ou software (soluo presente no Windows ou em outro software). ca
66.3
Tratamento de Transaes no SQL Server co
O Oracle executa recuperao automtica toda vez que iniciado. Ele checa ca a e se os arquivos do tablespace esto sincronizados com o contedo dos arquivo a u de redo log. Caso no estejam, o Oracle aplica o contedo do arquivo de redo a u log no caso das transaes comitadas e remove as transaes no comitadas co co a
507
Figura 66.1: Comparao grca entre os esquemas de armazenamento do Orca a acle e do SQL Server com o aux dos segmentos de rollback. Se o Oracle no possui a informao lio a ca requerida, ele consulta os arquivos redo log arquivados pelo processo ARCH. O SQL Server tambm executa recuperao automtica atravs da checagem e ca a e de cada banco de dados. Primeiramentem o SQL Server checa o Msdb e ento a inicia threads para recuperaao autpmtica em todos os bancos de dados. Para c a cada banco de dados, o mecanismo de recuperao automtica checa o transacca a tion log. O tratamento o mesmo do Oracle para transaes comitadas e no e co a 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 alteraes do banco de dados e compartilhado com todos co e os usurios do banco de dados. a Internamente, os transaction logs so quebrados em pedaes menores cona co hecidos como virtual log les (VLFs). Quando um VLF no possui mais registros a de logs para transaes ativas, ento o VLF pode ser dividido. O crescimento co a dos VLFs pode ser congurado para se ocorrer de forma automtica e assim a como no Oracle so preenchidos em forma circular. a
508
Parte XIV
ITIL
509
Cap tulo 67
Suporte a Servios c
67.1
67.1.1
Service Desk
Objetivos
Atuar como ponto unico de contato entre o usurio e o Gerenciamento de a Servios de TI; c Tratar incidentes e requisio de servios; ca c Ser a principal interface operacional entre a TI e seus usurios; a Promover a reteno e a satisfao do usurio; ca ca a Aumentar o percentual de resoluo de chamados no primeiro ponto de ca contato.
67.1.2
Responsabilidades
Receber, registrar, priorizar e rastrear chamadas de servio; c Prover uma avaliao inicial de todos os incidentes reportados pelos usurios; ca a Resolver incidentes com base em solues j conhecidas ou identicar co a solues de contorno para o reestabelecimento dos servios; co c Escalar chamado para suporte em n adequado; vel
Monitorar e acompanhar as chamadas com base nos acordos de n de vel servios; c Manter usurios informados; a Produzir informaes gerenciais; co Fechar incidentes e conrmar com o cliente / usurio. a
510
67.1.3
Vrios Tipos de Central a
Central de Atendimento Call Center. Apenas registra e encaminha para outras reas da organizao. a ca Central de Suporte Call Center. Gerencia, coordena e resolve incidentes o mais rpido poss a vel. Utiliza o gerenciamento de comunicao e ferramenca tas de suporte ao conhecimento como tecnologia de apoio. Normalmente, trata apenas incidentes. Central de Servios Service Desk. No trata somente incidentes, problemas c a e dvidas, mas tambm fornece uma interface para outras atividades como u e requisies de mudana do usurio, contratos de manuteno, licenas de co c a ca c software, gerenciamento de n de servio etc. vel c
67.2
67.2.1
Gerenciamento de Incidentes
Objetivos
Um incidente qualquer evento que no faz parte do servio combinado. A e a c indisponibilidade de um servio ou a diminuio de sua qualidade tambm pode c ca e ser considerado um incidente. Exemplos de incidente em um ambiente de TI so, por exemplo, uma aplicao com erro, um usurio que esqueceu a senha a ca a ou a indisponibilidade de um servidor, mesmo que os usurios no tenham sido a a impactados. O objetivo do processo de gerenciamento de incidentes restaurar a operao e ca normal de um servio minimizando o impacto no negcio. E importante enfatic o zar que o gerenciamento de incidentes trata o efeito e no a causa. A porta de a entrada para o tratamento de incidentes o Service Desk. e Os incidentes podem ser detectados pelos usurios ou por algum processo de a monitorao, alm de poderem surgir de dvidas, manifestaes ou requisies ca e u co co de servio. As sa c das do processo de gerenciamento de incidentes podem ser o reestabelecimento do servio, o esclarecimento da dvida, a atendimento da c u requisio de servio, a identicao de uma necessidade de mudana, ou ainda, ca c ca c o registro de um problema.
67.2.2
Atividades do Processo
Identicao e Registro do Incidente: Registro dos incidentes seja qual ca for a fonte de abertura, reportando sintomas, diagnstico bsico, itens de o a congurao envolvidos, perl do usurio etc; ca a Anlise e Classicao: Especica melhor os sintomas do incidente para a ca determinar a soluo; ca Priorizao: Combina os fatores impacto e urgncia para denir a priorca e idade do incidente em relao ao demais (Matriz Impacto x Urgncia). ca e Tambm levado em considerao o acordo de n de servio (ANS ou e e ca vel c SLA);
511
Suporte Inicial: Caso exista uma soluo previamente identicada na ca base de solues (BDS), o analista dever aplic-la. Caso contrrio, uma co a a a soluo dever ser implementada. Dependendo da complexidade, o regca a istro pode ser escalado para n veis mais especializados; Investigao e Diagnstico: Caso no seja encontrada uma soluo denica o a ca tiva, uma soluo de contorno pode ser especicada. Nesse caso, deve ser ca aberto um registro de problema; Estratgia de Recuperao: Aps denida a soluo, esta deve ser implee ca o ca mentada. Em algumas situaes pode ser necessrio abrir uma requisio co a ca de mudana (RDM); c Fechamento: Garantir que o incidente foi devidamente tratado. Em alguns casos, isso signica checar se a RDM foi implementada. A validao do ca cliente tambm importante para o fechamento; e e Informao e Comunicao: O Service Desk deve manter o histrico comca ca o pleto do registro e garantir que o usurio tenha acesso `s informaes seja a a co qual for o status de atendimento do incidente ou requisio. ca
67.2.3
Gestor de Incidentes: Avaliar e garantir a ecincia e qualidade do servio, e c auditar base de incidentes, garantir a avaliao da satisfao dos usurios, ca ca a produzir relatrios gerenciais e realizar anlise cr o a tica do processo; 1o N vel de atendimento: Receber, categorizar e priorizar as requisies co dos usurios. Realizar investigao inicial e aplicar solues de contorno a ca co conhecidas. Caso necessrio, encaminhar os incidentes para o n adea vel quado de atendimento; 2o N vel de atendimento: Desenvolver, quando poss vel, uma soluo de ca contorno ou denitiva. Caso necessrio, encaminhar incidente para o tera ceiro n vel; 3o N vel de atendimento: N vel mais alto de atendimento de incidentes. Deve obrigatoriamente desenvolver uma soluo de contorno; ca Equipes Especializadas: Atende `s solicitaes de servio, esclarecimento a co c de dvidas e manifestaoes dos usurios encaminhadas pelo primeiro n u c a vel. Deve executar os servios segundo procedimentos pr-denidos. c e
Os trs n e veis de atendimento e as equipes especializadas devem, quando necessrio, emitir uma RDM, vericar as divergncias encontradas na banco a e de dados de solues e na banco de dados de gerenciamento de congurao co ca (BDGC).
67.3
67.3.1
Gerenciamento de Problemas
Objetivos
Eliminar erros na infra-estrutura de TI, identicando e removendo a causa raiz, evitando assim, a recorrncia de incidentes e problemas no ambiente operacional. e 512
67.3.2
Denies Importantes co
SC Solues de Contorno. Eliminam o sintoma ou reduzem o impacto de um co erro, sem eliminar as suas causas. Problemas e Erros Conhecidos Um problema a causa subjacente descone hecida de um ou mais Incidentes. Um Problema passa a Erro Conhecido quando a causa-raiz for conhecida e for identicada uma soluo de conca torno ou uma alternativa denitiva. BDP Base de Dados de Problemas. Base de Dados que contm todos os rege istros de problemas. BDS Base de Dados de Problemas. Base de Dados que contm informaes e co referente aos Erros Conhecidos, suas respectivas Solues de Contorno e co demais solues denitivas. co
67.3.3
Identicao e registro do Problema ca Classicao do Problema ca Investigao e diagnstico do Problema ca o
Controle de Problemas
Controle de Erros Identicao e registro do Erro ca Avaliao do Erro ca Registro da resoluo do Erro ca Fechamento do Erro Monitoramento da resoluo do Erro ca
Apoio no tratamento de Incidentes Graves Preveno pro ativa de Problemas ca Anlise de tendncias a e Direcionamento das aes de suporte co Fornecimento de informaes para a organizao co ca
Obteno de Informaes gerenciais a partir dos dados de Problemas ca co Completar as revises dos principais Problemas o
67.3.4
Gestor de Problemas Analisar e garantir a ecincia do processo atravs da e e auditoria e da reviso. Responsvel tambm pela produo de relatrios a a e ca o gerenciais, alocao dos Responsveis Tcnicos e pela identicao de ca a e ca tendncias. e Responsvel Tcnico pelo Problema Identicar, registrar, categorizar e pria e orizar. Investigar e diagnosticar a causa do Problema. 513
67.4
67.4.1
Gerenciamento de Congurao ca
Objetivos
O objetivo do processo de gerenciamento de congurao prover informaes ca e co conveis sobre as conguraes e documentaes relativas a infra-estrutura de a co co TI de forma suportar os demais processos de gerenciamento de servios. O proc cesso de gerenciamento de congurao o principal responsvel pela construo ca e a ca e manuteno do banco de dados de gerenciamento de congurao (BDGC), ca ca considerado o corao do modelo de gerenciamento de servios do ITIL. Essa ca c base de dados deve conter informaes sobre todos os itens de congurao co ca (ICs) do ambiente e os seus respectivos relacionamentos. Um item de congurao um componente que faz parte ou est associado ca e a a infra-estrutura, fazendo-se necessrio para a prestao de um servio. (Exema ca c plo: servidor, software, procedimento etc.) Cada IC composto por atributos e como identicador unico, nome, tipo etc. O BDGC fundamental para o gerenciamento de n de servio, uma vez e vel c que a partir dele poss identicar todos os itens de congurao que fazem e vel ca parte de um servio espec c co. Alm disso, o BDGC permite identicar se incie dentes, problemas e mudanas em um determinado IC iro impactar nos demais. c a O BDGC s pode ser alterado mediante uma requisio de mudana (RDM). o ca c Uma baseline o estado do BDGC em determinado instante do tempo. Ela e serve como referncia para auditorias e tambm para estipular uma base de e e retorno aps mudanas mal sucedidas, por exemplo. o c
67.4.2
Atividades
Planejamento: Identicao do escopo, granularidade, objetivos, pol ca ticas e procedimentos para o processo de gerenciamento de congurao; ca Identicao e Denominao: Seleo e identicao dos ICs, denindo ca ca ca ca seus atributos, inter-relacionamento e identicao; ca Controle: Garante a autorizao e identicao dos ICs nos processos ca ca de incluso, alterao e descarte, alm de no permitir alteraes sem a ca e a co documentao de controle sejam feitas no BDGC; ca
Registro e Histrico da Situao: Realiza a atualizao no BDGC seguindo o ca ca procedimentos pr-denidos, de forma no perder o controle do ciclo de e a vida dos ICs e vinculaao `s RDMs; c a Descrio da Situao: Gerao de relatrios sobre status e ciclo de vida ca ca ca o dos ICs, permitindo a localizao de mudanas; ca c Vericao e Auditoria: Vericar a consistncia entre a situao real e o ca e ca BDGC e demais bibliotecas controladas.
514
67.4.3
Gestor de Congurao: Implementar pol ca ticas de gerenciamento de congurao e assegurar sua disseminao e utilizao por toda organizao. ca ca ca ca Elaborar relatrios com indicadores do processo e anlises de impacto. o a Deve ser membro do Grupo de Aconselhamento de Mudanas (GAMA); c Administrador de Congurao: Administrar o BDGC, assegurando sua ca atualizao a cada mudana. Deve ainda auditar o BDGC, garantindo sua ca c consistncia com o inventrio f e a sico.
67.5
67.5.1
Gerenciamento de Mudanas c
Objetivos
Garantir a aplicao de mtodos e procedimentos padronizados a m de lidar ca e ecientemente com todas as mudanas no ambiente operacional, minimizando c os impactos na qualidade dos servios e prevenindo a ocorrncia de incidente c e provenientes das mudanas realizadas. c
67.5.2
Responsabilidades
Controle das alteraes em todos os Ices; co Levantamento e registro das mudanas; c Avaliao de impacto, custo, benef e risco associado `s mudanas; ca cio a c Justicativa da mudana perante o negcio e obteno de aprovao para c o ca ca as mudanas; c Gerncia e coordenao da implementao de mudanas; e ca ca c Monitoramento e informes sobre a implementao; ca Reviso e fechamento das RDM (requisies de mudanas). a co c
67.5.3
Mudana Padro E a mudana bem conhecida, rotineira e que comprovadac a c mente no causa alto impacto. a
Mudana Normal Planejada E a mudana planejada e programada respeic c tando o cronograma de atividades e o acordo com os clientes. Mudana Emergencial E a mudana executada para recuperar servios a m c c c de evitar danos ` imagem do negcio, perdas nanceiras e conseqncias a o ue legais. RDM Requisio de mudana. RFC - Requests for Change. Documento que ca c formaliza a necessidade da mudana e dene detalhes de como ela aconc tecer. Inclui identicao numrica, descrio e identicao dos ICs, a ca e ca ca motivo da mudana, efeito da no implementao da mudana, nome do c a ca c solicitante da mudana, data proposta para a mudana, grau de prioric c dade, assinatura, plano de implementao, plano de retorno etc. ca 515
Gestor de Mudana Change Manager E responsvel pelas mudanas que c a c ocorrero no ambiente de TI. Ele no detm o poder de autorizar qualquer a a e mudana, isso cabe ao GAM. c GAM Grupo de Aconselhamento de Mudanas. CAB - Change Advisory Board. c Tem a responsabilidade de planejar, avaliar e aprovar mudanas de mdio c e e alto impacto. O grupo multidisciplinar, pode ter representantes do e Service Desk, desenvolvedores, rea de relacionamento com o cliente etc. a GAM/CE Grupo de Aconselhamento de Mudanas/Comit Emergencial. CAB/EC c e - Change Advisory Board/Emergency Committee. Tem a mesma funo ca do GAM, porm para mudana emergenciais de alto e mdio impacto. e c e Envolve n veis hierrquicos mais altos da TI. a Agenda de Mudanas (AM) Contm detalhes de todas as mudanas aprovadas c e c e suas datas de implementao. E usada para que todos os grupos afetados ca por uma mudana possam se planejar. c Projeo de Indisponibilidade PSA - Projected Services Availability. Contm ca e detalhes das mudanas e sua interferncia nos Acordos de N de Servios c e vel c e na disponibilidade de servios. c Reviso Ps-Implementao Reviso da Mudana realizada aps a implea o ca a c o mentao. Tem por objetivo avaliar se a mudana atingiu e se houve ca c imprevistos ou efeitos colaterais. Priorizao de Mudanas A priorizao das mudanas realizada de acordo ca c ca c e com o seu impacto e a sua urgncia. e
67.6
67.6.1
Gerenciamento de Liberao ca
Objetivo
Gerenciar a liberao de componentes de software, hardware e documentos nas ca implementaes e modicaes dos servios, garantindo liberaes compat co co c co veis, licenciadas e apropriadas para o ambiente de produo. Opera como interface ca entre o Gerenciamento de Mudanas e o Gerenciamento de Conguraes. c co
67.6.2
Planejar e administrar um implementao bem sucedida de hardware e ca software. Projetar e implementar procedimentos ecientes para a distribuio e inca stalao de mudanas. ca c Garantir a localizao do HW e do SW e assegurar que apenas as verses ca o corretas sejam instaladas. Gerenciar as expectativas dos clientes durante o planejamento e implementao (rollout) de novas liberaes. ca co Acordar o plano de implementao com o Gerenciamento de Mudanas. ca c 516
Testar o Plano de Retorno (fallback). Implementar as liberaes no ambiente operacional, atualizando os ICs co necessrios. a Garantir que as cpias originais de todos os softwares esto seguras em o a uma Biblioteca de Software Denitiva (BSD) e que o BDCG reita as informaes do BSD e das liberaes realizadas no ambiente. co co Garantir a acurcia do DHD (Depsito de Hardware Denitivo) e que todo a o IC retirado para ser utilizado no ambiente operacional seja reposto. Garantir que todo o hardware a ser implantado ou alterado esteja protegido e seja localizvel, utilizando os servios de Gerenciamento de Cona c gurao. ca
67.6.3
BSD Biblioteca de Software Denitiva. DSL - Denitive Software Library. Coleo de itens de congurao de software e documentao guardados ca ca ca em local seguro. Todas verses liberadas devem estar salvas na BSD. o DHD Depsito de Hardware Denitivo. DHS - Denitive Hardware Store. o Depsito de componentes de reposio no mesmo n dos sistemas coro ca vel respondentes no ambiente de produo. Uma vez encerrada a utilizao ca ca dos componentes, devem retornar ao DHD, ou adquirir substitutos. Assim como a BSD, o DHD um repositrio e quem contm as informaes e o e co sobre os atributos dos itens o BDGC. e Liberao completa Todos os componentes so constru ca a dos, testados, distribu dos em conjunto. Liberao Delta So inclu ca a dos os ICs alterados desde a ultima alterao. ca Liberao Pacote Liberaes completas, deltas ou as duas so agrupadas em ca co a pacote para liberao. ca
67.6.4
Gestor de Liberaes Garantir que o processo seja seguido. Efetua auditoria co no BSD e no DHD. Autoriza a liberao para o ambiente de produo. ca ca
Responsvel Tcnico pela Liberao Desenvolver o projeto, construo e a e ca ca congurao da liberao. Realizar testes. Realizar a instalao e disca ca ca tribuio de SW e HD. Armazenar o software na BSD. ca
517
Cap tulo 68
Entrega de Servios c
68.1
68.1.1
Gerenciamento do N vel de Servio c

Objetivos
O gerenciamento do n de servio visa a melhoria da qualidade dos servios vel c c de TI atravs de um ciclo cont e nuo de negociao e monitorao, promovendo ca ca aes para eliminar n co veis de servio inaceitveis. A essncia do processo em c a e questo o Acordo de N de Servio (ANS) (Service Level Agreement - SLA), a e vel c que funciona como um contrato entre a TI e os clientes. O ANS deve descrever em detalhes os servios fornecidos, alm especic-los quanto a qualidade, c e a quantidade, desempenho e disponibilidade. Os principais objetivos do processo de gerenciamento de n de servio so: vel c a Melhorar a especicao dos servios; ca c Reduzir demandas imprevistas; Avaliar o custo dos servios; c Controlar o n de servio; vel c Promover a melhoria da qualidade do servio; c Manter alinhamento com o negcio. o
Para alcanar tais objetivos, o processo de gerenciamento de n de servio c vel c tem as seguintes responsabilidades: Catlogo de Servios: Dene, do ponto de vista do cliente, os servios a c c fornecidos; Acordo de N vel de Servio (ANS): Acordos formais entre a TI e seus c clientes, onde so denidas as metas e as responsabilidades de ambas a as partes. Um ANS deve conter informaes como descrio do servio, co ca c agenda (24x7,5x8), suporte (sobreaviso, prorrogao, tempo de reparo), ca procedimentos para mudanas, metas para disponibilidade, conabilidade, c segurana, capacidade etc; c
518
Requisies de N co vel de Servio: Documentos para fornecer viso dec a talhada das necessidades do cliente, usados para ajustar ou criar novos servios (Service Level Request - SLR); c Acordo de N Operacional (ANO): Formalizao de acordos com fornecevel ca dores internos da organizao, sobre manuteno de servios ou compoca ca c nentes de servios (Operational Level Agreement - OLA); c Contratos de Apoio: Contratos de apoio com fornecedores externos (Underpinning Contract - UC); Programa de Aperfeioamento de Servios (PAS): Identicar e implemenc c tar aes necessrias para superar diculdades e restabelecer a qualidade co a do servio; c Gerenciamento do Relacionamento com o Cliente: Administrar o relacionamento com os clientes visando a sustentao dos acordos de n de ca vel servio e nivelamento das expectativas; c Monitorao, Reviso e Informao: Garantir o andamento do processo e ca a ca o cumprimento das metas estabelecidas nos acordos.
68.2
68.2.1
Gerenciamento Financeiro
Objetivos
Administrar os recursos monetrios, garantindo o planejamento e execuo dos a ca objetivos de negcio. Identicar, calcular e gerenciar os custos de entrega de o servio. Fornecer dados de previso oramentria para a administrao. c a c a ca
68.2.2
Responsabilidades
Otimizar os recursos nanceiros. Apoiar decises de investimentos. o Atribuir valores dos servios e rateio dos custos por cliente. c Inuenciar o comportamento do cliente. Melhorar o controle dos contratos Externos/Fornecedores.
68.2.3
Dentro de uma organizao de TI existem trs disciplinas principais para o ca e Gerenciamento Financeiro: Oramento c Processo de previso e controle dos gastos em dinheiro. As suas responsabilia dades compreendem: Previso do oramento necessrio para a realizao de servios de TI no a c a ca c per odo acordado. 519
Garantia que a despesa real possa ser comparada com a despesa prevista a qualquer momento do per odo. Reduo do risco de gastar alm do orado. ca e c Garantir a disponibilizao de verba para cobrir despesas extras. ca Garantia que as receitas estaro dispon a veis para cobrir despesas previstas. Contabilidade Conjunto de processos que permite a organizao de TI prestar contas de como ca o dinheiro foi gasto em um determinado per odo de tempo, sendo capaz de identicar custo por clientes, servios ou atividades. Deve ter focos nos custos para c justicar investimentos e lucro zero para que a organizao possa contabilizar ca as despesas de TI. As responsabilidades da disciplina compreendem: Contabilizao do dinheiro gasto para proviso dos servios de TI. ca a c Clculo do custo de provimento dos servios de TI para clientes externos a c e internos. Anlise Custo x Benef ou o retorno do investimento (ROI). a cio Identicao do custo de mudanas. ca c Cobrana c Conjunto de processos necessrios para faturar um Cliente (Oops...) pelos a servios prestados, otimizando a relao custo/benef c ca cio do ponto de vista do negcio. As responsabilidades da disciplina compreendem: o Recuperao dos custos dos servios de TI dos clientes dos servios. ca c c Rateio dos custo entre os clientes da TI. Inuncia do comportamento do Cliente. e Precicar os servios. c
68.2.4
Elementos de Custo
Os elementos de custo t picos so: hardware, software, pessoal, acomodaes, a co servio externo e transferncia de custo (cobrados por outros centros de custo c e da empresa). Os elementos de custo podem ser classicados em xos, variveis, a diretos, indiretos (que devem ser divididos entre vrios clientes), de capital e a operacional (do dia-a-dia).
520
68.3
68.3.1
Gerenciamento da Capacidade
Objetivos
O gerenciamento de capacidade visa garantir o atendimento das necessidades futuras do negcio estabelecendo sempre um equil o brio entre demanda e custos. O principal produto do processo A principal sa desse processo um da e documento chamado Plano de Capacidade. Nele so reportadas as previses a o de carga, hardware e software necessrios, custos e outras recomendaes. Os a co principais modelos para elaborao de um plano de capacidade so os seguintes: ca a Modelagem por Referncia: Modelagem a partir de um modelo vlido e a pr-existente; e Anlise de Tendncias: Projees futuras com base em dados histricos; a e co o Modelagem Anal tica: Validao de um modelo matemtico com a situao ca a ca real; Modelagem por Simulao: Utilizao de dados ct ca ca cios para dimensionamento de novas aplicaes; co Testes de Laboratrio: Testes como dados reais em um ambiente real. o O gerenciamento da demanda tem por objetivo inuenciar a demanda, direcionando o seu comportamento. Para isso pode ser necessrio realizar cobrana a c diferencial de acordo com o horrio, limitar tempo de uso em horrios de pico etc. a a A tarefa de monitorao de desempenho dos recursos e servios para garantir o ca c estabelecido no plano de capacidade chamada gerenciamento de performance. e No contexto de gerenciamento de capacidade outra atividade muito importante a modelagem e dimensionamento de aplicaes (Sizing de Aplicaes). e co co Um elemento importante no processo de gerenciamento de capacidade o e BDC (Banco de Dados de Capacidade), que armazena dados do negcio, dos o servios, nanceiros e de utilizao, sendo, portanto, base para elaborao de c ca ca relatrios relacionados a questo de capacidade atuais e futuras. o a
68.3.2
Atividades
Gerenciamento de Capacidade do Negcio: Garante que as capacidades o futuras do negcio sejam consideradas e planejadas em tempo certo. Reo quer conhecimento do Plano de Negcio da organizao e tcnicas de modo ca e elagem; Gerenciamento da Capacidade do Servio: Monitorao do desempenho c ca dos servios de TI; c Gerenciamento da Capacidade dos Recursos: Gerencia os componentes de infra-estrutura de TI para garantir que desempenho e demanda esto de a acordo com o planejado.
521
68.4
68.4.1
Gerenciamento de Disponibilidade
Objetivos
O processo de gerenciamento de disponibilidade visa garantir que os servios de c TI estaro dispon a veis sempre que os clientes necessitarem deles, de acordo com os n veis de disponibilidade acordados. Os principais elementos de disponibilidade de um servio so: c a Disponibilidade: Tempo durante o qual o servio estar dispon c a vel; Conabilidade: Capacidade de se manter operacional dentro de um determinado per odo de tempo; Sustentabilidade: Capacidade de retorno ao estado normal aps algum o incidente; Resilincia: Capacidade de se manter operacional mesmo na falta de um e ou mais componentes; Ociosidade: Obrigaes contratuais com terceiros (Contratos de Apoio); co Segurana: Condencialidade, Integridade e Segurana. c c Dizemos que um servio esta dispon quando o cliente o recebe dentro das c vel condies do acordo de n de servio. Portanto, a taxa de disponibilidade co vel c e dada pela seguinte frmula: o Disponibilidade = 100((T SA T F )/T SA)) onde T SA o tempo de servio acordado e T F o tempo durante o qual e c e o servio cou indispon c vel. Exemplo: Se um servio tem T SA 24x7 (precisa c estar dispon 24 horas 7 dias por semana) e cou indispon por um total de vel vel 10 horas durante um ms, ento a taxa de disponibilidade do servio no per e a c odo 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 interrupo de um servio. No instante t2 o servio foi restabelecido, e em um ca c c instante posterior t3, um outro incidente voltou a interromper o servio. A c partir dos valores de t1, t2 e t3 podemos denir as seguintes mtricas: e TMPR (Tempo Mdio para Reparo) = t2 t1; e TMEF (Tempo Mdio Entre as Falhas) = t3 t2; e TMEIS (Tempo Mdio entre Incidentes de Sistema) = t3 t1. e
522
68.5
68.5.1
Gerenciamento de Continuidade
Objetivos
O processo de gerenciamento de continuidade tem como principal objetivo a continuidade operacional dos servios de TI em ocasies de desastre, a m de c o suportar os requisitos m nimos do negcio. O principal produto desse processo o um documento chamado Plano de Continuidade dos Negcios (Business Cone o tinuity Plan - BCP). Os principais componentes de um plano de continuidade so: a Administrao: Quando e como invocar o plano; ca Infra-Estrutura de TI: Quais os itens envolvidos; Procedimentos Operacionais: Instrues de trabalho; co Pessoal: Responsveis, contatos e substitutos; a Site de Contingncia: Localizao, contato e transporte; e ca Retorno ao normal: Como, onde e quanto tempo para o retorno. Algumas mtricas importantes de retorno a normalidade so o RTO (Ree a covery Time Objective) e o RPO (Recovery point Objective). O RTO indica o ultimo instante no tempo a partir do qual a operao deve ser restabelecida ca aps um desastre. O RPO, por sua vez, determina o ponto a partir do qual os o dados devem ser recuperados aps um desastre. o No processo de gerenciamento de continuidade so realizadas anlises dea a talhadas de risco e impacto, utilizando metodologias de anlise de risco como a CRAMM (CTTA Risk Analysis and Management Methodology), OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation), CORAS etc. Todas essas metodologias so baseadas na norma ISO 27001. Uma elaborao a ca de uma anlise de risco e impacto, geralmente, se baseia na identicao de trs a ca e elementos que so: Ativos, Ameaas e Vulnerabilidades. a c E a sopa de letrinhas no tem m. Algumas outras siglas que podem ser a uteis na hora da prova so: BIA (Business Impact Analysis), OCP (Operational a Continuity Plan), DRP (Disaster Recovery Plan). Todas essas anlises e planos, a na verdade, fazem parte do Plano de Continuidade de Negcios. o
68.5.2
Estgios a
In cio: Obteno do aval gerencial e levantamento dos servios de TI ca c cr ticos para o negcio; o Requisitos Estratgicos: Anlise de Risco e de Impacto e elaborao da e a ca estratgia de continuidade; e Implementao: Planejamento e implementao das instalaes para reca ca co cuperao, elaborao do plano de continuidade, medidas para reduo de ca ca ca riscos e realizao de testes iniciais; ca 523
Gerenciamento Operacional: Educao, reviso, auditoria, testes, treinaca a mento e gerenciamento de mudanas. c
68.5.3
Tipos de Continuidade
Solues de contorno manuais: Medidas temporrias at que os servios co a e c sejam restabelecidos; Acordos de reciprocidade: Organizaes concordam auxiliar uma a outra co em caso de desastres; Recuperao Gradual (Cold Standby): Ambiente computacional vazio, exca ceto por energia e telecomunicaes. M co nimo de 72 horas para reestabelecimento dos servios; c Recuperao Intermediria (Warm Standby): Ambiente com equipamenca a tos para recuperao dos servios mais cr ca c ticos entre 24 e 72 horas; Recuperao Imediata (Hot Standby): Instalao alternativa com espelca ca hamento cont nuo de equipamentos e dados.
524
Parte XV
Gerncia de Projetos e segundo PMBOK
525
Cap tulo 69
Gerenciamento de Escopo
A primeira rea de conhecimento denida pelo PMBOK a de Gerenciamento a e de Escopo. Os principais processos respectivas atividades desta rea so: a a 1. Iniciao: declarao formal do in ca ca cio do projeto, com a elaborao do ca Project Charter ; 2. Planejamento: declarao do escopo, indicando justicativas para o proca jeto, alm dos principais produtos, subprodutos e objetivos do projeto; e 3. Detalhamento: elaboraao da Estrutura Anal c tica do Projeto (EAP ), tambm e conhecida como Work Breakdown Structure (WBS ), que tem por objetivo identicar fases, atividades e pacotes de trabalho. A WBS de grande e importncia para realizao de estimativas de tempo e custo; a ca 4. Vericao: trata da aceitao do escopo; ca ca 5. Controle de Mudanas: identica as mudanas de escopo assim como seus c c motivos e impactos, alm de tratar dos ajustes necessrios. e a
69.1
WBS e Denio do Escopo ca
No processo de Denio do Escopo, as entregas so subdivididas em comca a ponentes menores e gerenciveis, para permitir o planejamento de tarefas e a atividades. As ferramentas e tcnicas desse processo so a decomposio e os e a ca modelos da estrutura anal tica do projeto (EAP ou WBS - Work Breakdown Structure). Segundo o PMBOK, a EAP um conjunto de componentes do projeto, estrue turados com base nas entregas, que organiza e dene o escopo total do projeto; o trabalho no inclu na EAP est fora do escopo do projeto. Assim, com a a do a declarao de escopo, a EAP equivale a um acordo bsico entre os stakeholders ca a e os integrantes da equipe com relao ao escopo do projeto. Enm, a EAP deve ca especicar o escopo completo do trabalho necessrio para concluir o projeto. a A decomposio uma das ferramentas usadas na preparao da EAP, e ca e ca envolve a subdiviso das entregas em componentes distintos o suciente para a 526
facilitar a realizao das estimativas, a denio de baseline para controle de ca ca desempenho e a atribuio clara de responsabilidades. A estrutura mais comum ca usada para representar essa decomposio rvore. O n 1 (raiz) considca e a vel e erado o prprio projeto, seguido pelas entregas, que podem ser seguidas por o outras entregas, seguidas por atividades e assim por diante. Cada elemento de cada n da EAP deve receber um identicador exclusivo. vel
Figura 69.1: WBS - Work Breakdown Structure O gerente de projeto pode determinar ` vontade o nmero de n a u veis na EAP, com base na complexidade do projeto. Independentemente do nmero de n u veis da EAP, o n mais baixo de cada estrutura denominado pacote de trabalho. vel e Pacotes de trabalho so as atividades ou componentes que podem ser facilmente a atribu dos a uma pessoa ou grupo, que assumiro a clara responsabilidade pelo a seu cumprimento. E no n de pacotes de trabalho que se fazem as estimativas vel de tempo, custos e recursos. Cabe ressaltar que no existe nenhuma regra no a PMBOK determinando a presena de atividades na EAP. Entretanto, quando c poss vel, considera-se uma boa prtica. a Finalmente, o Dicionrio da EAP contm uma descrio do n a e ca vel dos pacotes de trabalho e os detalhes relativos `s atividades dentro de cada pacote. a Nele se encontram informaes como custos, oramentos, prazos, distribuio de co c ca recursos e descrio das atividades. Outro conceito importante so os marcos ca a de projeto (milestones). Os marcos so realizaes signicativas do projeto que a co ajudam a vericar o andamento dos trabalhos.
527
Cap tulo 70
Gerenciamento de Recursos Humanos

A fase de Gerenciamento de Recursos Humanos engloba os seguintes processos: 1. Planejamento Organizacional : denio de equipes, pers e responsabilica dades, alm do formato da equipe (ex: democrtica descentralizada, cone a trolada centralizada, controlada descentralizada). Deve levar em considerao as caracter ca sticas da organizao (matricial forte ou fraca, orientada ca a projetos,etc); 2. Montagem de Equipe: alocao de pessoas ou equipes aos papeis denidos; ca 3. Desenvolvimento da Equipe: estratgias para aumentar capacidade das e pessoas e equipes, gerenciar conitos (ex: negociao,panos quentes,retirada,fora,etc). ca c Principais tericos: McGregor (Teoria XY ), Maslow (Pirmide de Neceso a sidades), Hezberg (Fatores Motivacionais).
70.1
70.1.1
Estruturas Organizacionais
Organizao Funcional ca
As organizaes funcionais giram em torno de especialidades e so agrupadas co a por funo - da o nome organizao funcional. Nela pode haver, por exemplo, ca ca um departamento de recursos humanos, outro de marketing e etc. O trabalho executado nesses departamentos especializado e requer que os funcionrios e a tenham aptides espec o cas e experincia nas funes para cumprir as response co abilidades. Esse tipo de organizao congurado de maneira hierrquica, ou ca e a seja, cada funcionrio responde a um unico gerente e, em ultima instncia, existe a a um unico responsvel no topo. Cada departamento ou grupo administrado a e separadamente e tem um mbito de controle limitado. A seguir so apresena a tadas as vantagens e desvantagens dessa organizao. ca As principais vantagens e desvantagens dessa organizao so: ca a Vantagens:
528
Figura 70.1: Organizao Funcional ca Estrutura organizacional duradoura; Carreira prossional transparente; Cadeia de comando expl cita. Desvantagens: O gerente de projeto tem pouca ou nenhuma autoridade ocial; Vrios projetos disputam recursos limitados e prioridades; a Os integrantes do projeto so leais ao gerente funcional. a
70.1.2
Organizao por Projeto ca
As organizaes por projeto so praticamente o oposto das organizaes funco a co cionais. O enfoque o prprio projeto, assim cultiva-se a lealdade ao projeto e e o no a um gerente funcional. Os gerentes de projeto tm total autoridade sobre a e o projeto e respondem diretamente ao CEO. As equipes so formadas e seus a membros com freqncia so co-alocados, ou seja, trabalham no mesmo local ue a f sico.
Figura 70.2: Organizao por Projeto ca As principais vantagens e desvantagens dessa organizao so: ca a Vantagens: O gerente de projeto a autoridade mxima; e a
529
O enfoque da organizao o projeto; ca e Os recursos da organizao so destinados ao projeto; ca a Lealdade ao gerente do projeto; Comunicao efetiva. ca Desvantagens: Quando o projeto nalizado a equipe desalocada; e e Uso dos recursos pode no ser eciente; a Duplicao de funes. ca co
70.1.3
Organizao Matricial ca
As organizaes matriciais surgiram para minimizar as diferenas entre os pontos co c fortes e fracos das organizaes funcionais e das estruturadas por projeto.e melco hor explor-los. Assim, os objetivos so atendidos, tcnicas ecientes de gerena a e ciamento de projetos so aplicadas, ao mesmo tempo que tambm se mantm a a e e estrutura hierrquica da organizao. a ca
Figura 70.3: Organizao Matricial ca Os funcionrios de uma organizao matricial se reportam ao gerente funa ca cional e a, no m nimo, um gerente de projeto - podendo ser subordinados a vrios a gerentes de projeto, caso trabalhem em vrios projetos simultneos. O gerente a a funcional responde por incumbncias administrativas e aloca funcionrios para e a os projetos, alm de monitorar o trabalho de seus funcionrios nos diversos proe a jetos. O gerente de projeto, por sua vez, responsvel pela execuo do projeto e a ca e distribuio das tarefas de acordo com as atividades previstas. Ambos divica dem as responsabilidades pela avaliao de desempenho dos funcionrios. ca a Como se pode perceber, h muita comunicao e negociao entre os gerentes a ca ca de projeto e funcional. Isso requer um equil brio de poder entre os dois. Desse modo, so trs os tipos de organizao matricial: a e ca Matricial forte: gerente de projeto tem prioridade sobre gerente funcional; Matricial fraca: gerente funcional tem prioridade sobre gerente de projeto; Matricial Equilibrada: h negociao entre gerente funcional e gerente de a ca projeto. 530
Em todo o caso, as vantagens e desvantagens so: a Vantagens: Quando o projeto nalizado, a equipe alocada em outras ativie e dades na empresa; A disseminao de informaes ocorre na vertical e horizontal; ca co Os recursos escassos so bem utilizados. a Desvantagens: Mais de um gerente para a equipe do projeto se reportar; Grande probabilidade de conitos; Precisa de pessoal administrativo extra para cumprir as necessidades dos projetos.
70.2
Planejamento Organizacional
O objetivo desse processo documentar as funes e responsabildiades de ine co div duos e grupos para cada elemento do projeto e, em seguida, registrar as relaes de subordinao de cada um. Neste momento devem ser denidas toco ca das as equipes que estaro envolvidas no projeto. Dessa forma, Marilyn Mantei a prope trs tipos de estruturas para equipes: o e Democrtica Descentralizada: nessa estrutura no h um l a a a der ou gerente permanente. As decises so tomadas por consenso. Na prtica, no o a a a funciona muito bem para projetos; Controlada Descentralizada: nessa estrutura h um gerente geral para o a projeto e gerentes secundrios ou l a deres locais. As decises de problemas o do projeto so tomadas por consenso entre o gerente do projeto e os gera entes secundrios. A execuo das aes so controladas pelos gerentes a ca co a secundrios. H comunicao horizontal e vertical. Essa estrutura coa a ca e mum em projetos que possuem vrios mdulos, principalmente, se estes a o so desenvolvidos em paralelo; a Controlada Centralizada: nessa estrutura h um gerente geral para o proa jeto e os demais membros esto diretamente ligados a ele. No h l a a a deres secundrios. S h comunicao vertical. a o a ca
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 coordenado, funcional e eciente. Nesse aspecto desejvel manter a equipe sempre e a motivada. So vrias as teorias sobre a motivao. As principais so: a a ca a Hierarquia de necessidades de Maslow; 531
Teoria da Higiene ou teoria Motivao-Higiene; ca Teoria das Expectativas; Teoria da Realizao. ca Maslow defendia a hiptese de que os seres humanos possuem cinco necessio dades bsicas, distribu a das em ordem hierrquica. Eis um resumo de cada uma a delas, do n mais alto at o mais baixo: vel e Realizao pessoal - Trabalhar no seu potencial mximo; ca a Necessidade de auto-estima - Realizao, respeito por si mesmo, cpacitao; ca ca Necessidades sociais - Senso de pertencimento, amor, aceitao, amizade; ca Necessidade de proteo e segurana - Seu bem-estar f ca c sico e seus pertences. Quando todas as necessidades f sicas, de proteo. Sociais e de auto-estima ca forem atendidas, a pessoa alcanar um estado de independncia em que conc a e seguir se expressar e realizar ao mximo, e far um bom trabalho apenas pelo a a a fato de fazer um bom trabalho. Herzberg desenvolveu a teoria da Higiene que postula a existncia de duas e categorias de fatores que contribuem para a motivao: fatores de higiene e ca motivadores. Os primeiros tratam de questes relacionadas ao ambiente de trao balho: evitam a insatisfao: salrio, benef ca a cios, as condies de ambiente de co trabalho. Os motivadores dizem respeito ` substncia do trabalho em si e com a a a satisfao do sujeito ao exercer as funes do cargo: conduzem a satisfao. ca co ca Segundo a Teoria das expectativas, a perspectiva de um resultado positivo e que aciona a motivao: as pessoas vo apresentar um determinado comportaca a mento de acharem que recebero uma boa recompensa para isso. Alm disso, a e a fora da expectativa inui no comportamento. A teoria alega ainda que as c pessoas se tornam o que se esperam delas. Segundo a Teoria da Realizao somos motivados por trs necessidades: reca e alizao, poder e aliao. A motivao da realizao a necessidade de triunfar ca ca ca ca e ou atingir um dado objetivo. A motivao do poder refere-se ao desejo de inca uenciar os comportamentos alheios. E a necessidade de aliao diz respeito a ca relacionamentos. Ao lado das teorias motivacionais esto as teorias de sobre a liderana. a c Destacam-se as teorias X e Y e a teoria da contingncia. e 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 no gosta de trabalhar, tm pouca ou nenhuma ambio, a e ca precisam de superviso constante no cumpriro suas obrigaes, a menos que a a a co 532
ameaadas. Em razo disso, agem como ditadores e impem ao seu pessoal c a o controles muito r gidos. J os gerentes partidrios da Teoria Y entendem que as a a pessoas vo se interessar por dar o melhor de si, se tiverem a motivao certa a ca e as expectativas adequadas. Assim, proporcionam apoio `s suas respectivas a equipes, preocupam-se com seus membros e so bons ouvintes. a A teoria da contingncia resulta de uma combinao entre as Teorias Y e ca e da Higiene; em suma, argumenta que somos motivados a atingir n veis de competncia e continuaremos motivados por essa necessidade mesmo depois de e atingir a competncia. e
533
Cap tulo 71
Gerenciamento do Tempo
Os processos da rea de Gerenciamento do Tempo segundo o PMBOK so: a a 1. Denio das Atividades: denir as atividades e respectivos responsveis. ca a 2. Sequenciamento das atividades: estabelecer relaes de precedncia entre co e as atividades (Diagramas de Precedencia); 3. Estimativas de Durao: estimar a durao do projeto utilizando alguma ca ca abordagem (TopDown, BottomUp). As principais tcnicas utilizadas para e realizao de estimativas so Modelos Matemticos, Analogias e Consulca a a toria de Especialistas; 4. Desenvolvimento do Cronograma : utilizao de alguma tcnica matemtica ca e a como PERT, CPM (Critical Path Method ) para formalizar o cronograma. Tcnicas de Nivelamento de Recursos leva a alocao dos recursos em e ca conta no estabelecimento de precedncias das atividades. Para comprimir e o cronograma as tcnicas mais comuns so Crashing (adio de recursos) e a ca e Fast-Tracking (antecipao de inicio de atividade); ca 5. Controle do Cronograma: comparar, analisar e revisar o cronograma para permitir administrar desvios ao longo do projeto.
71.1
Tcnicas de Desenvolvimento do Cronograma e
Consiste em formalizar o cronograma, identicando suas datas, caminhos cr ticos e registrando os marcos e pontos de controle identicados. H seis ferramentas a e tcnicas usadas no Desenvolvimento de Cronograma: e Anlise Matemtica; a a Compresso de cronograma; a Simulao; ca Heur stica de nivelamento de recursos; Software de gerenciamento de projeto; Estrutura de Codicao. ca 534
71.1.1
Anlise Matemtica a a
A anlise matemtica consiste no clculo das datas de in a a a cio mais cedo e de trmino mais tarde das atividades do projeto - sem levar em conta as limitaes e co dos recursos, o que acaba gerando prazos tericos. A anlise matemtica abrange o a a trs tcnicas: e e Mtodo do caminho cr e tico (CPM - Critical Path Method); Tcnica de Anlise e Avaliao Grca (GERT - Graphical Evaluation e a ca a and Review Technique); Tcnica de Anlise e Avaliao de Programa (PERT - Program Evaluation e a ca and Review Technique). O mtodo CPM calcula as datas de in mais cedo, de m mais cedo, de e cio in cio mais tarde e de m mais tarde de cada atividade. Para isso, baseia-se em redes seqenciais (em que uma atividade acontece depois da outra) e numa u estimativa unica de durao para cada atividade. O caminho cr ca tico de todo o projeto o caminho mais longo. Toda atividade com folga igual a zero e e considerada uma tarefa do caminho cr tico. Assim, para calcular a durao do ca caminho cr tico basta somar a durao de cada atividade com folha igual a zero. ca Existem dois tipos de folga: folga total e folga livre. A primeira o tempo toe tal pelo qual poss e vel atrasar o in cio da tarefa sem prorrogar o trmino do e projeto. J a folga livre o tempo durante o qual poss atrasar o in da a e e vel cio tarefa sem prorrogar o in de uma tarefa subseqente. cio u O que preciso saber sobre a tcnica GERT que ela aceita desvio condie e e cional, looping e tratamento probabil stico. Por exemplo, um o projeto de um software pode exigir o teste de mdulos individuais antes da vericao do proo ca grama como um todo, a cada mdulo precisa ser aprovado em seu teste ` parte. o a Cada teste constitui uma execuo no lao. ca c A tcnica PERT usa o valor esperado para denir a durao do projeto, pore ca tanto se baseia em ferramentas estat sticas para isso. As tcnicas com e PERT e so muito parecidas, entretanto CPM usa a durao mais provvel e PERT o a ca a valor esperado (ou mdia ponderada). e
71.1.2
Compresso do Cronograma a
Trata-se de uma condensao do cronograma de modo a nalizar todas as ativica dades antes do estimado. Duas tcnicas so usadas; compresso propriamente e a a dita (crashing) e paralelismo (fast tracking). A compresso uma tcnica que a e e leva em conta a relao entre custo e cronograma. Uma das possibilidades ca e adicionar recursos `s tarefas do caminho cr a tico, j que estas atividades posa suem folga zero. Podem-se tambm limitar ou reduzir os requisitos do projeto. e Nem sempre produz os resultados esperados e geralmente acaba aumentando os custos. O paralelismo consiste em iniciar ao mesmo tempo duas atividades que a princ pio estavam programadas para serem seqenciais. A tcnica pode u e aumentar os riscos do projeto e acarretar retrabalho.
535
71.1.3
Simulao ca
Na simulao parte-se de diferentes conjuntos de premissas para chegar a diverca sas duraes par ao projeto. O principal representante a Simulao de Monte co e ca Carlo que mostra a probabilidade de todas as poss veis datas de trmino do proe jeto. Outra tcnica chamada what-if (anlise de hipteses) permite examinar o e a o cronograma sob diversas circunstncias. a
71.1.4
Heur stica do nivelamento de recursos
A anlise matemtica no leva em considerao a disponibilidade de recursos. a a a ca Entretanto, com freqncia o cronograma inicial tem per ue odos de tempo com mais atividades do que recursos dispon veis para elas e que nem sempre poss e vel alocar `s tarefas 100 % do tempo dos membros da equipe. Nesse contexto, o a nivelamento de recursos - tambm chamado mtodo baseado em recursos - visa e e a aplainar a distribuio de recursos para que as tarefas sejam conclu ca das sem sobrecarregar ningum, ao mesmo tempo procurando manter o projeto dentro e do cronograma.
71.1.5
Estrutura de Codicao ca
A estrurura de codicao uma ferramenta e tcnica relacionada ` possibilca e e a idade de ordenar atividades com base em caracter sticas que lhes podem ser atribu das - como por exemplo classicaes da EAP, fases do projeto, tipo de co atividades e etc.
536
Cap tulo 72
Gerenciamento de Custo
Os processos englobados pela rea de Gerenciamento de Custo so: a a 1. Planejamento dos Recursos: determinar quais recursos sero necessrios a a e em que quantidade; 2. Estimativa dos Custos: associar custo aos recursos enumerados; 3. Oramentao dos Custos: alocao das estimativas globais de custo so c ca ca a utilizadas para formalizar o oramento; c 4. Controle dos Custos: revisar o oramento, identicar e administrar desvios. c
72.1
Tcnicas de Estimativas de Custos e
As estimativas de custos emprega cinco ferramentas e tcnicas para gerar estie mativas: Estimativa Anloga a Modelagem Paramtrica e Estimativas bottom-up Ferramentas computadorizadas
72.1.1
Estimativas Anlogas a
As estimativas anlogas, tambm chamadas de estimativas top-down, so uma a e a forma de opinio especializada. Nessa tcnica usa-se a durao real de uma a e ca atividade similar realizada num projeto anterior para projetar a durao da ca atividade atual. Essa tcnica muito util quando as atividades anteriores de e e referncia so realmente prximas com a atividade que esto sendo avaliada. E e a o a particularmente util quando no h informaes minuciosas sobre o projeto a a co como ocorre em suas fases iniciais, por exemplo.
537
72.1.2
Modelagem Paramtrica e
E um modelo matemtico que usa parmetros - ou caracter a a sticas do projeto para prever custos. A idia descobrir um ou vrios parmetros que se mode e a a iquem paralelamente aos custos do projeto, incorporando-os ao modelo para chegar a um custo total. Para utilizar essa tcnica preciso haver um padro e e a no trabalho, de modo que possamos usar uma estimativa desse elemento para gerar a estimativa total do projeto. A modelagem paramtrica semelhante ` e e a estimativa anloga, na medida em que prev o custo do projeto inteiro de cima a e para baixo.
72.1.3
Estimativa bottom-up
Esta tcnica oposta ` top-down, pois estima-se cada atividade ou item de trae e a balho separadamente para depois reuni-las ou agreg-las numa estimativa total a do projeto. Trata-se de um mtodo de estimao muito preciso, entretanto e ca e muito demorada, j que o pacote de trabalho deve ser avaliado e estimado com a exatido para ser inclu no clculo. Essa no uma alternativa adequada para a do a a e fazer uma estimativa de custo na fase inicial do projeto, dada a inexistncia de e dados sucientes nessa etapa.
538
Cap tulo 73
Gerenciamento de Riscos
A rea de gerenciamento de riscos responsvel por minimizar a probabilidade a e a de ocorrncia de desvios ao longo do ciclo de vida do projeto. Os processos do e Gerenciamento de Riscos so: a 1. Planejamento: denir qual ser a abordagem aos riscos; a 2. Identicao: identicar, descrever e classicar os riscos; ca 3. Anlise Qualitativa: associar probabilidades e graus de impacto aos riscos a atravs de tcnicas como Matriz de Graduao, Matriz Probabilidade x e e ca Impacto; 4. Anlise Quantitativa: associar probabilidades e graus de impacto de forma a numrica utilizando tcnicas como Anlise de Sensibilidade, Arvore de e e a Deciso e Simulaes; a co 5. Planejamento de Respostas: denir qual ao ser tomada mediante os ca a riscos identicados (ex: evitar, transferir, mitigar, aceitar); 6. Controle e Monitoraao: garantir a execuo do plano,identicar novos c ca riscos, monitorar riscos residuais e realizar ajustes necessrios. a
73.1
Anlise Qualitativa a
A Anlise Qualitativa de Riscos visa ` deteco do impacto dos riscos identia a ca cados sobre os objetivos do projeto e sua probabilidade de ocorrncia. Tambm e e classica os riscos por prioridade, de acordo com os efeitos sobre os objetivos do projeto. Nesse processo, basta atribuir ao risco um valor alto, mdio ou baixo e (ou alguma combinao similar). ca 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 tcnica Probabilidade e Impacto do Risco e atribui probabilidades aos eventos de risco identicados e calcula seu efeito sobre os objetivos do projeto. Esses mtodos permitem determinar que riscos e demandam o gerenciamento mais agressivo.
539
Outra ferramenta e tcnica a Matriz de classicao de riscos por probabile e ca idade e impacto (PI) cujo objetivo atribuir uma classicao genrica a cada e ca e um dos risos identicados do projeto, geralmente expressa como alta, mdia ou e baixa. Segundo o guide to PMBOK, os riscos elevados correspondem a uma situao vermelha, os mdios a uma situao amarela e os baixos, verde. Esse ca e ca tipo de classicao denominado de escala ordinal, porque os valores so ordeca e a nados de forma descendente. Ao m desse processo, portanto, os riscos podem ser enumerados por ordem de prioridade. A prioridade estabelecida por meio e da matriz PI. A matriz de PI determinada a partir da multiplicao de dois valores: o e ca valor da probabilidade do risco vezes o valor do seu impacto (cada qual gerado na escala correspondente). A avaliao da probabilidade e impacto dos riscos cosca tuma se dar por meio de tcnicas de opinio especializada e entrevistas. Antes e a de se chagar a matriz PI, porm, so elaboradas a escala de probabilidades e a e a escala de impacto dos riscos. O objetivo dessas escalas desenvolver medidas e predenidas que determinem que valor atribuir a determinado evento de risco.
73.2
Anlise Quantitativa de Riscos a
A Anlise Quantitativa de Riscos avalia os impactos e quantica a exposio do a ca projeto aos riscos por meio da atribuio de probabilidades numricas a cada ca e um e aos seus impactos sobre os objetivos do projeto. Para tanto, so usadas a tcnicas como a simulao de Monte Carlo e a anlise de decises. Pode-se e ca a o usar tanto a Anlise Qualitativa quanto a Anlise Quantitativa para avaliar os a a riscos, ou usar apenas uma dos dois. Essa deciso ser tomada com base na a a complexidade do projeto. As ferramentas e tcnicas desse processo so: e a Entrevistas; Anlise de Sensibilidade; a Anlise da rvore de decises; a a o Simulao. ca Anlise de Sensibilidade um mtodo de anlise do poss a e e a vel impacto dos eventos de risco sobre o projeto e determinao de que evento (ou eventos) de ca risco tem maior impacto potencial. Tambm pode ser empregada para averiguar e os n veis de tolerncia aos riscos por parte dos stakeholders. Ela examina a exa tenso a qual a incerteza de cada elemento do projeto afeta o objetivo que est a a sendo examinado quando todos os outros elementos incertos so mantidos em a seus valores iniciais. A anlise da rvore de decises so diagramas que mostram a seqncia de a a o a ue decises inter-relacionadas e os resultados esperados de acordo com a alternativa o escolhida. Em geral existe mais de uma escolha ou opo dispon ca vel quando nos deparamos com uma deciso - ou, nesse caso, poss a veis conseqncias de ue um evento de risco. As escolhas dispon veis so expostas em forma de rvore, a a comeando ` esquerda com a deciso relacionada ao risco, e ramicando para a c a a 540
direita, com as poss veis conseqncias. Essas rvores costumam ser usada para ue a os eventos de riscos associados a tempo e custo. A simulao tem como principal representante a tcnica de Monte Carlo. ca e Ela ajuda a quanticar os riscos associados ao projeto com um todo. Os riscos identicados e seus poss veis impactos sobre os objetivos do projeto so exama inados sob o prisma do projeto global. A tcnica usada para determinar os e e poss veis resultados pr meio da simulao do projeto diversas vezes seguidas. ca
541
Cap tulo 74
Gerenciamento de Qualidade
Os processos para realizao do Gerenciamento de Qualidade como denidos no ca PMBOK so: a 1. Planejamento: denio dos padres de qualidade relevantes ( Benchca o marking, Diagrama Espinha de Peixe (causa/efeito) e Fluxograma Processo); 2. Garantia: vericar relevncia dos processos denidos; a 3. Controle: analisar de padres esto sendo seguidos, identicar causas de o a desvios. Ferramentas muito utilizadas so a Carta Controle, Diagrama de a Pareto (direcionar aes corretivas). co
74.1
Tcnicas de Planejamento da Qualidade e
O processo de Planejamento da Qualidade visa ao cumprimento de padres de o qualidade para o projeto em questo, elaborando, para tanto, um plano. Sea gundo o guide to PMBOK a qualidade planejada, no inspecionada. Portanto, e a uma sa desse processo o plano de gerenciamento da qualidade que especida e ca como a pol tica de qualidade ser implementada pela equipe de gerncia de a e projeto no decorrer das atividades. Para isso, vrias ferramentas so emprea a gadas. Os principais exemplos so: anlise de custo/benef a a cio, benchmarking, uxograma, elaborao de experimentos e custo da qualidade. ca
74.1.1
Anlise Custo/Benef a cio
Anlise de custo/benef a cio aborda as compensaes no custo da qualidade. E co mais barato e eciente prevenir problemas do que ter de perder tempo e dinheiro para corrigi-los mais tarde. O guide to PMBOK salienta que o custo bsico do a cumprimento dos requisitos de qualidade num projeto equivale `s despesas ima plicadas na execuo das atividades de gerenciamento da qualidade. ca
542
74.1.2
Benchmarking
E um processo de comparao de atividades anteriores similares `s do projeto ca a atual para obter um parmetro de referncia para a avaliao do desempenho. A a e ca comparao acaba sugeringo idias para melhorar a qualidade no projeto atual. ca e Por exemplo, se a impressora imprime 8 pginas por minuto e o projeto est a a considerando comprar uma que imprima 14 pginas por minuto, a referncia a e e a impressora usada no projetos at ento. e a
74.1.3
Fluxograma
So diagramas que mostram as etapas lgicas a serem executadas para atingir a o um objetivo. Tambm podem discriminar como se do as relaes entre os die a co versos elementos de um sistema. Os uxogramas podem ajudar a identicar possibilidades de ocorrncia de problemas no projeto. H dois tipos mais coe a muns de uxogramas: os diagramas de processo ou sistema e os diagramas de causa e efeito. Os diagramas de causa e feito mostram a relao entre os efeitos dos probca lemas e suas causas, apresentando todas as poss veis causas primrias e sea cundrias dos problemas, bem como os efeitos de cada soluo sugerida. Esse a ca diagrama tambm chamado de espinha de peixe ou de Ishikawa. e e
Figura 74.1: Diagrama Causa/Efeito O uxograma de sistema ou processos exibe as etapas lgicas necessrias para o a atingir determinado objetivo, bem como a relao entre diferentes elementos de ca um sistema. Esse o mais conhecido; geralmente constru com retngulos e e do a e paralelogramos que, ordenados numa seqncia lgica, permitem ramicaes ue o co baseadas em sim e no a
74.1.4
Elaborao de Experimentos ca
E uma tcnica estat e stica que identica os elementos ou variveis que surtiro a a os efeitos mais profundos sobre os resultados globais do projeto. Ela aplicada e com mais freqncia ao produto do projeto, mas tambm pode ser utilizada nos ue e processos de gerenciamento que examinam relaes de compensao. O processo co ca cria e realiza experimentos para chegar ` soluo ideal de um problema, a partir a ca de um nmero limitado de exemplos. u
543
74.1.5
Custo da Qualidade
O custo da qualidade diz respeito ao custo total da gerao do produto ou servio ca c do projeto de acordo com os padres de qualidade, e engloba todo o trabalho o necessrio para atender os requisitos do produto - quer tenha sido planejado ou a no. Existem trs custos associados ao custo da qualidade: a e Custo de Preveno; ca Custo de Avaliao; ca Custo de falhas, divididos em custos internos e custos externos. Os custos de preveno so aqueles associados ao cumprimento dos requica a sitos dos clientes por meio da gerao de produtos livres de defeitos; vm a ca e tona logo no comeo do processo e compreendem fatores como planejamento da c qualidade, treinamento, anlise de projeto. a Os custos de avaliao so aqueles em que se incorre para examinar o proca a duto ou processo e averiguar se determinados requisitos esto sendo atendidos. a Podem incluir custos associados a elementos como inspees e testes. co Custos de falhas so aqueles que ocorrem quando as coisas no se passam a a conforme o planejado. So dois tipos: internos (tambm chamado de custo de a e erro) e externos (tambm chamado de custo de defeito). O primeiro se impe e o quando os requisitos do cliente deixam de ser satisfeitos com o produto ainda sob controle da organizao. Os custos de falhas externas se do quando o proca a duto j chegou ao cliente e este entende que suas determinaes ainda no foram a co a atendidas. Trs tericos em particular so responsveis pela expanso do movimento e o a a a pelo gerenciamento da qualidade e das teorias a respeito do custo da qualidade: Crosby, Juran e Deming. Crosby criou a prtica do zero defeito - que a signica, basicamente, acertar de primeira. A preveno a pea central da ca e c teoria de Crosby. Juran conhecido pelo seu princ e pio da adequao ao uso ca - que signica, em termos simples, a satisfao ou superao das expectativas ca ca dos stakeholders clientes. A conformidade pea central na teoria de Juran. e c Deming arma que at 85% do custo da qualidade so problemas gerenciais. e a Quando a questo da qualidade chega ` base, ao patamar dos operrios, estes a a a tm pouco controle a exercer. Ao lado dos trs tericos, pode-se citar como de e e o importante relevncia a Abordagem Kaizen que signica melhoria cont a nua.
74.2
Tcnicas de Controle da Qualidade e
O controle de qualidade preocupa-se particularmente com o monitoramento dos resultados do trabalho, a m de vericar se esto cumprindo os padres estaba o elecidos no plano de gerenciamento da qualidade. Existem vrias ferramentas e a tcnicas nesse processo: e
544
Inspeo; ca Grcos de Controle (Carta de Controle); a Diagramas de Pareto; Diagramas de Disperso; a Amostragem Estat stica; Elaborao de Fluxogramas (Diagramas de Causa e Efeito, Fluxograma ca de Sistemas); Anlise das Tendncias. a e
74.2.1
Grcos de Controle a
Medem os resultados dos processos ao longo do tempo e exibem-nos em formato grco; constituem uma maneira de mensurar variaes a m de averiguar se a co as variaes dos processos esto ou no sob controle. Os grcos de controle co a a a se baseiam na mediao de variaes de amostras escolhidas e mensuradas das ca co quais se determinam a mdia e o desvio-padro. O controle da qualidade cose a tuma ser mantido - ou considerado sob controle - dentro de mais ou menos trs e desvios-padro. Em outras palavras, o Controle da Qualidade considera que o a processo encontra-se sob controle quando se sabe que 99,73% das peas a ele c submetidas vo recair num intervalo aceitvel da mdia. Caso de descubra uma a a e pea fora desse intervalo, deve-se averiguar a necessidade de eventuais medidas c corretivas.
Figura 74.2: Grco de Controle a Existen dois tipos de grcos de controle que so (i) Controle por variveis a a a e (ii) Controle por atributos.
74.2.2
Diagramas de Pareto
Baseia-se na regra 80/20 onde armado que 80% dos problemas so causados e a por um pequeno nmero de causas, 20%. Os diagramas de Pareto assumem a u forma de histogramas que classicam os fatores mais importantes (como atrasos, custos, defeitos ou outros) conforme a freqncia ao longo do tempo. A teoria ue prega que se obtm o mximo benef se for dedicado a maior parte do tempo e a cio a ` correo dos problemas mais relevantes. Os problemas so classicados de ca a acordo com a freqncia e a porcentagem de defeitos. ue
545
74.2.3
Diagramas de Disperso a
Os diagramas de disperso usam duas variveis, uma denominada varivel ina a a dependente, que entrada, e outra chamada varivel dependente, que uma e a e sa da, e mostram a relao entre ambas, sob a forma de pontos no grco. ca a
546
Cap tulo 75
Gerenciamento da Comunicao ca
Segundo o PMBOK,o Gerenciamento da Comunicao dividido nos seguintes ca e processos: 1. Planejamento: denio das informaes necessrias, objetos de comuca co a nicao e layouts de documentos; ca 2. Distribuio das Informaes: disponibilizar as informaes necessrias ca co co a a `s partes envolvidas; 3. Relato de Desempenho: relatrios de situao, de progresso e previses; o ca o 4. Encerramento Administrativo: encerramento formal do projeto. Divulgao ca dos resultados do projeto para patrocinadores e cliente, consideres nais, co anlise dos pontos fracos e fortes. a
75.1
Um mais sobre Planejamento da Comunicao ca
Compreende a determinao das necessidades de comunicao do stakeholders ca ca por meio da denio dos tipos de dados necessrios e do formato em que sero ca a a transmitidos. Dois fatores inuenciam esse processo: os requisitos de comunicao e a tecnologia envolvida. A sa desse processo o plano de gerenca da e ciamento das comunicaes. Ele estabelece como coletar, armazenar, arquivar co e corrigir ou atualizar materiais j divulgados. Contm tambm uma lista das a e e informaes a serem distribu co das, o momento de sua comunicao e a estrutura ca de distribuio, alm de descrever como os stakeholders podem ter acesso a inca e formaes do projeto antes das datas de divulgao. As informaes a serem co ca co compartilhadas e os mtodos de distribuio dependem das necessidades dos e ca stakeholders, da complexidade do projeto e das pol ticas organizacionais.
547
Cap tulo 76
Gerenciamento das Aquisies co

A rea de gerenciamento de comunicaes composta pelos seguintes processos: a co e 1. Planejamento: identicao das necessidades que sero melhor atendidas ca a por terceiros. Elaborao da SOW (Specication of Work ); ca 2. Preparao: elaborao da documentacao para licitaes ou concorrncia; ca ca co e 3. Obteno de Propostas: seleo de fornecedores utilizando critrios denidos; ca ca e 4. Administrao de Contratos: acompanhar desempenho de fornecedores; ca 5. Encerramento Contrato: formalizar m de contrato e arquivamento de informaes. co
76.1
Um pouco mais sobre Planejamento de Aquisies co
O Planejamento de Aquisies um processo que identica os bens ou servios a co e c serem comprados fora da organizao - o que inclui conrmar se devem adquirir ca os produtos ou servios e, em caso armativo, quanto e quando. Duas ferrac mentas so usadas com freqncia nesse processo: anlise ?make or buy? e a ue a seleo do tipo de contrato. A principal deciso a ser tomada por mdio dessa ca a e anlise se vai ser melhor, em termos de custos para a organizao, comprar ou a e ca fabricar os bens ou servios necessrios par ao projeto. J a outra tcnica trata c a a e da seleo do tipo de contrato usado para aquisio de produto ou servio. Os ca ca c tipos de contrato so: a Contratos de preo xo ou preo global: O contratado arca com a maior c c parte dos riscos; Contrato de custos reembolsveis: O contratante arca com a maior parte a dos riscos; + Custo mais remunerao xa ca
548
+ Custo mais remunerao de incentivo ca Contrato por tempo e material: Tipo h brido. As duas partes dividem os riscos. A principal sa desse processo a Declarao de Trabalho(DT) ou Especida e ca cao de Trabalho (SOW - Especication of Work). A DT descreve o item ca a ser contratado com suciente detalhamento para permitir que os potenciais fornecedores possam avaliar se so capazes de atender o edital Deve conter no a m nimo: Os objetivos do projeto; Uma descrio do trabalho do projeto; ca Especicaes concisas do bem ou servio necessrios; co c a Um cronograma do projeto.
549
Cap tulo 77
Gerenciamento da Integrao ca
Para assegurar que reas esto bem coordenadas o PMBOK dene a rea de a a a Gerenciamento da Integrao, que composta pelos seguintes processos: ca e 1. Desenvolvimento do Plano do Projeto: reune todas as reas em em um a documento chamado Plano de Projeto); 2. Execuo do Plano: onde gasto maior parte Oramento; ca e c 3. Controle Integrado de Mudanas: analisar as poss c veis mudanas, motivos c e respectivos impactos ao longo do projeto. Os ajustes devem ser feitos de forma integrada.
77.1
Ferramentas de Apoio ` Integrao a ca
Duas ferramentas so usadas nessa rea: Gerenciamento de Valor Agregado a a (GVA ou EVM - Earned Value Management) e os softwares de gerenciamento de projetos. O GVA uma metodologia de integrao de projetos empregada e ca para integrar processos e mensurar o desempenho do projeto ao longo do ciclo de vida do projeto. O MS Project um exemplo de software de apio ` gerencia e o a de projetos. Outro exemplo o Primavera TeamPlayer. e
O GVA pode ser empregado tanto no processo de controle de custos quanto no processo de planejamento. No ultimo caso, o GVA, que visa ` mensurao a ca e ao relato do andamento do projeto, incorpora o cronograma do projeto, seu escopo e recursos como um todo para determinar se existem discrepncias no a projeto. No primeiro caso, OGVA apia o clculo das variaes de custo. o a co
550
Cap tulo 78
Sobre os Ciclos do Projeto e Processos de Gerenciamento

Todos os projetos so divididos em fases e, sejam grandes ou pequenos, tm um a e ciclo de vida parecido. O conjunto de fases coletivas atravessadas pelo projeto denominado ciclo de vida do projeto. O trmino de cada fase pode ser e e reconhecido pela apresentao de uma entrega espec ca ca (ou vrias), marcando a o nal daquela etapa. Entrega tudo o que deve ser produzido para que a e fase ou o projeto sejam encerrados; so elementos tang a veis, que podem ser avaliados e comprovados com facilidade. As avaliaes empreendidas ao nal de co cada estgio recebem vrios nomes tais como: sa a a das de fase, passagem de estgio ou pontos de encerramento. a Como mencionado anteriormente, os projetos possuem um ciclo de vida parecido. Esse ciclo de vida pode ser organizado nos seguintes grupos processos: iniciao, planejamento, execuo, controle e encerramento. Os cinco grupos ca ca so iterativos. A gura 78.1 apresenta os grupos de processos em um ciclo de a vida de projeto t pico.
Figura 78.1: Ciclo de Vida do Projeto 551

HB - Ti Concursos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HB - Ti Concursos

Uploaded by

Copyright:

Available Formats

http://www.candidatoreal.

7.6 7.7 7.8

Linguagem de Programao Java ca

213 215 216 217

42 Camada de Aplicao ca 364 42.1 Proxy Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

43 O protocolo SNMP 367 43.1 Management Information Base . . . . . . . . . . . . . . . . . . . 368

. . . . . . . . . . . . 17799 e a ISO 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

375 376 376 377 377

Administrao de Bancos de Dados Relacionais 489 ca

62 Gerncia de Transaes e co 63 Controle de Concorrncia e 64 Gerncia de Desempenho e

Oracle e Microsoft SQL Server

67 Suporte a Servios c 510 67.1 Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

Gerncia de Projetos segundo PMBOK e

69 Gerenciamento de Escopo 526 69.1 WBS e Denio do Escopo . . . . . . . . . . . . . . . . . . . . . 526 ca

Arquitetura e Organizao ca de Computadores

Estrutura e Funcionamento da CPU

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 Interrupo ca

Figura 1.5: Diagrama do Tempo para Pipeline de Instrues co

Figura 1.6: Efeito do desvio condicional no Pipeline de Instrues co

O desempenho de um computador pode ser denido como: Desempenho = (1.1)

Tempo de execuo de um programa ca

No de ciclos de clock = No instrues do programa x CPI co

Tempo de CPU = No de instrues x CPI x Per co odo do clock

Programas para medir desempenho

Programa 1 (s) Programa 2 (s) Total (s)

Computador A 1 1000 1001

Computador B 10 100 110

Tabela 1.1: Tempo total de execuo de 2 programas ca

Mdia Aritmtica = Tempo (i,n) = e e Mdia Harmnica = Taxa (i,n) = e o

Mdia Geomtrica = Tempo Normalizado (i,n) = e e

Nmero de op. de ponto utuante u Tempo de execuo x 106 ca

Principais componentes de Hardware

Figura 2.3: Trilha com 16 setores e diferentes fatores de entrelaamento c

Construo de uma Unidade Lgica Aritmtica ca o e

Figura 3.2: ALU

4. Arredondamento O nmero nal est OK. u a

Figura 4.1: Sistema Operacional

Camadas do subsistema de Entrada e Sa da

Figura 4.3: Camadas do Subsistema de E/S

Conceitos bsicos sobre arquivos a

partir dos mtodos seqencial e relativo. e u

Cache de Sistema de Arquivos

Gerenciamento do espao livre c

Sistemas Operacionais Distribu dos

Tabela 4.1: Sistemas Operacionais

Estruturao de Sistemas Distribu ca dos

Principais Processadores de Mercado

Fam Celeron lia

Fam Core lia

Princ pios de programao orientada a obca jetos

Modelo seq encial linear u

Modelos de processo de software evolucionrios a

Modelo espiral ganha-ganha

Modelo de desenvolvimento concorrente

Desenvolvimento baseado em componentes

Modelo de mtodos formais e

Tcnicas de quarta gerao e ca

Anlise Comparativa de a Processos de Desenvolvimento

RUP - Rational Unied Process

Figura 8.2: O modelo de ciclo de vida proposto no RUP

Feature Driven Development (FDD)

javax.servlet.; javax.servlet.http.; java.io.; java.util.;