1

SISTEMAS COMPUTACIONAIS ...................................................................................................................7

ORGANIZAO DE COMPUTADORES..........................................................................................................................................7
lgebra booleana .................................................................................................................................................................7
Sistemas de numerao e representao de dados...............................................................................................................8
Aritmtica computacional ....................................................................................................................................................8
Microprocessadores: Componentes .....................................................................................................................................8
Microprocessadores: Arquitetura ........................................................................................................................................9
Dispositivos perifricos........................................................................................................................................................9
Conceitos de interrupes ..................................................................................................................................................10
Estruturas de endereamento.............................................................................................................................................10
Compiladores, Ligadores e Interpretadores.......................................................................................................................11
SISTEMAS OPERACIONAIS .......................................................................................................................................................12
Conceitos Bsicos...............................................................................................................................................................12
Gerenciamento de Processos .............................................................................................................................................13
Gerenciamento de Memria...............................................................................................................................................13
Sistemas de Arquivos..........................................................................................................................................................15
Gerenciamento de Dispositivos..........................................................................................................................................16
Concorrncia......................................................................................................................................................................17
Concorrncia: Deadlocks...................................................................................................................................................17
REDES DE COMPUTADORES.....................................................................................................................................................19
Comunicao de dados.......................................................................................................................................................19
Meios de transmisso .........................................................................................................................................................19
Redes locais e de longa distncia.......................................................................................................................................20
Topologias..........................................................................................................................................................................20
Servios de comunicao ...................................................................................................................................................21
Protocolos ..........................................................................................................................................................................22
Equipamentos .....................................................................................................................................................................22
Sistemas Distribudos .........................................................................................................................................................23
Segurana...........................................................................................................................................................................23
ARQUITETURA OSI DA ISO.....................................................................................................................................................24
Camada Fsica ...................................................................................................................................................................24
Camada de Enlace de Dados .............................................................................................................................................25
Camada de Rede.................................................................................................................................................................25
Camada de Transporte.......................................................................................................................................................26
Camada de Sesso..............................................................................................................................................................26
Camada de Apresentao...................................................................................................................................................26
Camada de Aplicao ........................................................................................................................................................26
TCP/IP....................................................................................................................................................................................26
Camadas do TCP/IP...........................................................................................................................................................27
Camada de Acesso Rede (ou Camada de Interface)........................................................................................................27
Camada Internet (ou Camada de Inter-Rede) ....................................................................................................................27
Camada de Transporte.......................................................................................................................................................28
Camada de Aplicao ........................................................................................................................................................28
Protocolo IP.......................................................................................................................................................................28
Protocolo TCP....................................................................................................................................................................28
Formato do Pacote IP........................................................................................................................................................29
Classes de Endereos IP ....................................................................................................................................................29
Algoritmo de Transmisso de pacotes IP...........................................................................................................................30
Algoritmo de Recepo de pacotes IP................................................................................................................................30
WINDOWS (2003/XP/2000/98)................................................................................................................................................31
Bibliotecas de ligaes dinmicas......................................................................................................................................31
Arquitetura Distribuda......................................................................................................................................................32
MODELO CLIENTE SERVIDOR..................................................................................................................................................32
2 camadas...........................................................................................................................................................................32
3 camadas...........................................................................................................................................................................32
N camadas ..........................................................................................................................................................................32
Chamadas remotas .............................................................................................................................................................32
Sincronismo e filas de mensagens ......................................................................................................................................33
CONCEITOS DE INTERNET........................................................................................................................................................33
Domain Name Service/System (DNS).................................................................................................................................33
2
Default Gateway.................................................................................................................................................................33
Backbone ............................................................................................................................................................................34
Intranet ...............................................................................................................................................................................34
Extranet ..............................................................................................................................................................................35
Firewall ..............................................................................................................................................................................35
BANCO DE DADOS........................................................................................................................................36
CONCEITOS .............................................................................................................................................................................36
Administrao de Dados ....................................................................................................................................................36
Sistemas Gerenciados de Bancos de Dados (SGBDs)........................................................................................................36
Linguagem de definio de dados e Linguagem de manipulao de dados.......................................................................38
Dicionrio de dados ...........................................................................................................................................................38
Arquitetura de banco de dados...........................................................................................................................................38
Bancos de dados relacionais..............................................................................................................................................38
MODELAGEM DE DADOS .........................................................................................................................................................39
Modelo Entidade-Relacionamento .....................................................................................................................................39
Modelo Relacional .............................................................................................................................................................40
12 Regras de Codd .............................................................................................................................................................40
lgebra Relacional.............................................................................................................................................................41
NORMALIZAO .....................................................................................................................................................................41
Dependncia Funcional......................................................................................................................................................42
Primeira Forma Normal.....................................................................................................................................................42
Segunda Forma Normal .....................................................................................................................................................42
Terceira Forma Normal .....................................................................................................................................................43
Outras Formas Normais.....................................................................................................................................................43
AMBIENTE OPERACIONAL.......................................................................................................................................................43
Conceito de transao........................................................................................................................................................43
Concorrncia......................................................................................................................................................................43
Recuperao.......................................................................................................................................................................44
Segurana...........................................................................................................................................................................44
Independncia dos Dados...................................................................................................................................................44
Integridade .........................................................................................................................................................................45
Procedimentos (Stored Procedures) ..............................................................................................................................45
Vises (views).................................................................................................................................................................45
Gatilhos (Triggers) ........................................................................................................................................................45
ndices e otimizao de acesso...........................................................................................................................................45
BANCOS DE DADOS DISTRIBUDOS..........................................................................................................................................45
Caractersticas ...................................................................................................................................................................46
Fragmentao e Replicao...............................................................................................................................................46
BANCO DE DADOS DE OBJETOS...............................................................................................................................................46
SQL (ANSI)............................................................................................................................................................................47
Principais instrues de manipulao de dados ................................................................................................................47
Uso do Join.........................................................................................................................................................................47
Subconsultas.......................................................................................................................................................................48
Elaborao de consultas SQL ............................................................................................................................................48
SOLUES DE SUPORTE DECISO.....................................................................................................50
CONCEITOS DE DATA WAREHOUSE E APLICAES.................................................................................................................50
Estruturas de armazenamento para Data Warehouse........................................................................................................51
Data Marts .........................................................................................................................................................................52
Metadados no ambiente de inteligncia de negcios. ........................................................................................................52
Ferramentas de front-end: principais recursos e aplicaes.............................................................................................52
Processo de construo de um Data Warehouse................................................................................................................53
OLAP (ON-LINE ANALYTICAL PROCESSING)..........................................................................................................................53
Arquiteturas OLAP.............................................................................................................................................................54
CONCEITOS DE MODELAGEM DIMENSIONAL............................................................................................................................54
Desenho de modelos dimensionais a partir de modelos transacionais normalizados........................................................55
EIS - ENTERPRISE INFORMATION SYSTEM...............................................................................................................................56
ECM - ENTERPRISE CONTENT MANAGEMENT ........................................................................................................................56
DATA MINING.........................................................................................................................................................................57
ANLISE E PROJETO DE SISTEMAS.......................................................................................................58
3
ANLISE E PROJETO ESTRUTURADO DE SISTEMAS..................................................................................................................58
MODELAGEM DE DADOS..........................................................................................................................................................58
MODELAGEM FUNCIONAL.......................................................................................................................................................58
O Dicionrio de Dados ......................................................................................................................................................58
DFD e Modelagem de Fluxo de Dados ..............................................................................................................................59
MTODOS FUNCIONAIS X MTODOS OO.................................................................................................................................60
Mtodos Funcionais ...........................................................................................................................................................60
Mtodos OO (orientados por objetos)................................................................................................................................61
ANLISE ESSENCIAL ...............................................................................................................................................................61
Anlise Essencial x Anlise Estruturada............................................................................................................................62
ANLISE E PROJETO ORIENTADO A OBJETOS............................................................................................................................62
Modelagem Dinmica ........................................................................................................................................................62
UML ...................................................................................................................................................................................63
Diagrama de casos de uso..................................................................................................................................................63
Agregao x composio....................................................................................................................................................64
Diagrama de estados..........................................................................................................................................................65
Diagrama de seqncia......................................................................................................................................................65
Diagrama de atividades .....................................................................................................................................................66
Diagrama de colaborao/comunicao ...........................................................................................................................66
Diagrama de implementao .............................................................................................................................................67
Diagrama de componentes .................................................................................................................................................67
Utilizao dos diagramas...................................................................................................................................................68
PADRES DE PROJETOS (DESIGN PATTERNS)............................................................................................................................69
USO/CONCEITOS DE FERRAMENTAS DE SUPORTE ANLISE E PROJETOS ORIENTADOS A OBJETOS..........................................70
ENGENHARIA DE SOFTWARE..................................................................................................................71
PRINCPIOS DE ENGENHARIA DE SOFTWARE............................................................................................................................71
Engenharia de sistemas......................................................................................................................................................71
Ciclo de Vida......................................................................................................................................................................71
Processos de Software........................................................................................................................................................71
Anlise................................................................................................................................................................................72
Projeto (design) e Codificao...........................................................................................................................................72
Verificao x Validao .....................................................................................................................................................72
Testes..................................................................................................................................................................................72
Garantia da qualidade .......................................................................................................................................................73
Manuteno........................................................................................................................................................................73
MODELOS DE CICLO DE VIDA...................................................................................................................................................73
Modelo Clssico ou Cascata..............................................................................................................................................73
Modelo orientado a reuso ..................................................................................................................................................74
Modelo Evolucionrio ou Prototipagem............................................................................................................................74
Tcnicas de quarta gerao ...............................................................................................................................................74
Modelo em Espiral .............................................................................................................................................................75
RAD - Desenvolvimento rpido de aplicaes ...................................................................................................................75
TESTES....................................................................................................................................................................................76
Tipos de Testes ...................................................................................................................................................................76
Walkthough.........................................................................................................................................................................77
Tcnica de prova de corretitude.........................................................................................................................................77
Simulaes..........................................................................................................................................................................77
Testes de caixa preta..........................................................................................................................................................77
Testes de caixa branca .......................................................................................................................................................78
ENGENHARIA DE REQUISITOS ..................................................................................................................................................78
Requisitos ...........................................................................................................................................................................79
Processo da Engenharia de Requisitos ..............................................................................................................................79
Elicitao de requisitos ......................................................................................................................................................79
ENGENHARIA DE USABILIDADE...............................................................................................................................................80
Anlise de requisitos de usabilidade ..................................................................................................................................80
Projeto de interfaces ..........................................................................................................................................................81
PROCESSOS DE SOFTWARE ......................................................................................................................................................81
ISO 12207...........................................................................................................................................................................81
Metodologias geis: Extreme Programming......................................................................................................................82
Metodologias geis: FDD..................................................................................................................................................83
4
MDA Model Driven Architecture ....................................................................................................................................84
MDD Model Driven Development...................................................................................................................................85
RUP........................................................................................................................................................................................85
Melhores Prticas do RUP.................................................................................................................................................86
Elementos Estticos do RUP.............................................................................................................................................87
Disciplinas do RUP............................................................................................................................................................88
Fases do RUP.....................................................................................................................................................................88
MODELOS DE MELHORIA DE QUALIDADE DE PROCESSO E PRODUTO........................................................................................88
CMM/CMMI.......................................................................................................................................................................89
ISO 9126.............................................................................................................................................................................92
Gesto da Qualidade..........................................................................................................................................................93
Atividades da Qualidade Total (ISO 9001) ........................................................................................................................94
MODELAGEM DE PROCESSOS DE NEGCIO.......................................................................................95
Conceitos bsicos ...............................................................................................................................................................95
Identificao e delimitao de processos de negcio.........................................................................................................95
Tcnicas de mapeamento de processos (modelos AS-IS) ...................................................................................................96
Tcnicas de anlise e simulao de processos ...................................................................................................................96
Construo e mensurao de indicadores de processos ....................................................................................................96
Tcnicas de modelagem de processos (modelos TO-BE) ...................................................................................................96
MODELAGEM DE PROCESSOS EM UML...................................................................................................................................96
Notao ..............................................................................................................................................................................96
Artefatos .............................................................................................................................................................................96
Atividades ...........................................................................................................................................................................97
GERNCIA DE PROJETOS..........................................................................................................................98
PMBOK..................................................................................................................................................................................98
Conceitos............................................................................................................................................................................98
reas de Conhecimento......................................................................................................................................................98
Anlise de Risco ...............................................................................................................................................................100
Stakeholders .....................................................................................................................................................................100
Ciclo de Vida do Projeto..................................................................................................................................................101
Estrutura da Organizao................................................................................................................................................101
PROJETOS DE SOFTWARE.......................................................................................................................................................101
Estrutura de decomposio de trabalho (WBS) ...............................................................................................................101
Planejamento....................................................................................................................................................................102
Acompanhamento e Controle ...........................................................................................................................................102
Grfico de Gantt...............................................................................................................................................................102
Ferramentas de Controle de Qualidade...........................................................................................................................103
COLETA DE MTRICAS DE SOFTWARE...................................................................................................................................103
Estimativa de tamanho de software..................................................................................................................................104
Anlise de Pontos por Funo (APF)...............................................................................................................................105
COCOMO ............................................................................................................................................................................106
Implementao Bsica......................................................................................................................................................106
Implementao Intermediria ..........................................................................................................................................106
Implementao Avanada ................................................................................................................................................107
ANLISE DE DESEMPENHO....................................................................................................................................................107
Modelos Analticos ...........................................................................................................................................................107
Simulao.........................................................................................................................................................................108
Medio de Desempenho..................................................................................................................................................108
Mtricas de Desempenho .................................................................................................................................................108
Planejamento de Capacidade...........................................................................................................................................109
GESTO E RECURSOS INFORMACIONAIS..........................................................................................110
Servio de TI.....................................................................................................................................................................110
Funes de TI ...................................................................................................................................................................110
MODELOS DE GOVERNANA EM TI: ITIL..............................................................................................................................111
Service Support.................................................................................................................................................................111
Service Delivery ...............................................................................................................................................................112
MODELOS DE AUDITORIA EM TI COBIT............................................................................................................................113
Processos do COBIT ........................................................................................................................................................113
5
Ferramentas de Gerenciamento do COBIT......................................................................................................................114
SISTEMAS DE GERENCIAMENTO ELETRNICO DE DOCUMENTOS (GED) ................................................................................115
Aspectos Tcnicos.............................................................................................................................................................115
Evoluo do GED.............................................................................................................................................................116
SISTEMAS INTEGRADOS DE GESTO......................................................................................................................................116
ERP - Enterprise Resource Planning...............................................................................................................................116
CRM - Customer Relationship Management....................................................................................................................117
AUTOMAO DE PROCESSOS DE TRABALHO (WORKFLOW) ...................................................................................................118
Modelo de Referncia.......................................................................................................................................................118
Workflow no contexto do ERP..........................................................................................................................................119
GERENCIAMENTO DE PROCESSOS DE NEGCIO (BPM) ..........................................................................................................119
E-COMMERCE........................................................................................................................................................................120
TCNICAS E LINGUAGENS DE PROGRAMAO..............................................................................121
LGICA .................................................................................................................................................................................121
Lgica Formal..................................................................................................................................................................121
ALGORITMOS E ESTRUTURAS DE DADOS...............................................................................................................................121
Noes de complexidade de algoritmo.............................................................................................................................121
Tipos de dados..................................................................................................................................................................122
Listas Encadeadas............................................................................................................................................................122
Pilhas................................................................................................................................................................................122
Filas..................................................................................................................................................................................123
Vetores e Matrizes............................................................................................................................................................123
rvores balanceadas ........................................................................................................................................................124
Listas invertidas e ndices ................................................................................................................................................125
Mtodos de acesso............................................................................................................................................................125
Mtodos de ordenao e pesquisa....................................................................................................................................125
Hashing ............................................................................................................................................................................126
PROGRAMAO.....................................................................................................................................................................126
Programao Estruturada................................................................................................................................................126
Modularizao..................................................................................................................................................................126
Sub-rotinas .......................................................................................................................................................................127
Escopo de Variveis .........................................................................................................................................................127
Tipos de dados..................................................................................................................................................................127
Programao Orientada a Objetos ..................................................................................................................................127
Refactoring.......................................................................................................................................................................128
DESENVOLVIMENTO J2EE.....................................................................................................................................................128
Especificao J2EE..........................................................................................................................................................128
Conceito de servidor de aplicao...................................................................................................................................128
Container web e EJB........................................................................................................................................................129
Padres e anti-padres de projeto J2EE..........................................................................................................................130
Padro MVC de Projeto...................................................................................................................................................130
DESENVOLVIMENTO DE SISTEMAS WEB...........................................................................................132
HTML...................................................................................................................................................................................132
CSS.......................................................................................................................................................................................133
JAVASCRIPT...........................................................................................................................................................................133
Comandos do Javascript ..................................................................................................................................................133
Eventos .............................................................................................................................................................................134
Funes do Javascript......................................................................................................................................................134
DHTML................................................................................................................................................................................135
ARQUITETURA DE APLICAES PARA AMBIENTE WEB...........................................................................................................135
WEB SERVICES ......................................................................................................................................................................135
Arquitetura Service-Oriented Architecture (SOA) ...........................................................................................................136
Tecnologias dos Web Services..........................................................................................................................................136
PORTAIS CORPORATIVOS ......................................................................................................................................................137
Motivao e Caractersticas dos Portais .........................................................................................................................137
Gesto de Contedo .........................................................................................................................................................138
JSR 168 - Java Specification Request 168 Portlet Specification......................................................................................140
WSRP - Web Services for Remote Portlets.......................................................................................................................141
ACESSIBILIDADE ...................................................................................................................................................................142
6
Decreto n 5296, de 02/12/2004.......................................................................................................................................142
Modelo de acessibilidade .................................................................................................................................................142
Cartilha tcnica................................................................................................................................................................143
Recursos tcnicos para implementao da acessibilidade em HTML..............................................................................144
SEGURANA DA INFORMAO.............................................................................................................146
POLTICA DE SEGURANA......................................................................................................................................................146
Regras gerais da Poltica de Segurana ..........................................................................................................................146
AMEAAS, ATAQUES E ANLISE DE VULNERABILIDADE........................................................................................................147
AUDITORIA DE SISTEMAS E SOLUES BASEADAS EM TECNOLOGIA DA INFORMAO.........................................................147
Requisitos de Segurana...................................................................................................................................................148
CERTIFICAO DIGITAL ........................................................................................................................................................148
Criptografia......................................................................................................................................................................149
Criptografia Simtrica .....................................................................................................................................................149
Criptografia Assimtrica..................................................................................................................................................150
Hashing ............................................................................................................................................................................150
Protocolos Criptogrficos ................................................................................................................................................150
Assinatura Digital ............................................................................................................................................................151

7
Sistemas Computacionais
Organizao de Computadores
Um computador organizado basicamente pela UCP, pela Memria e os Dispositivos de Entrada e Sada.
A UCP ou CPU (Central Processing Unit) responsvel pelo processamento e execuo dos programas armazenados na
memria principal. Ela composta pela UAL (Unidade Aritmtica e Lgica) e a UC (Unidade de Controle), que busca, inter-
preta e controla as instrues e demais componentes do computador.
Registradores so dispositivos de armazenamento temporrio, localizados na UCP, extremamente rpidos, com capacidade
para apenas um dado (uma palavra). Est localizado no chip, e os seus dados so volteis.



lgebra booleana
Os circuitos lgicos so construdos a partir das portas lgicas, que implementam fisicamente as funes booleanas bsicas. A
representao padro destes trs blocos lgicos mostrada a seguir.



NOT AND OR
Os trs principais operadores da lgebra booleana so os operadores NOT, AND e OR.
O operador unrio NOT representado como . O resultado desta operao sobre uma varivel a inverso ou ne-
gao do valor da varivel. Isto , se a A = 1 ento = 0 e vice-versa.
O operador AND representado pelo smbolo , como em A B. O resultado da aplicao deste operador sobre vari-
veis booleanas igual a 1 somente se todas as variveis forem iguais a 1. Caso contrrio, o resultado 0. Esta ope-
rao conhecida como produto lgico.
O operador OR representado pelo smbolo +, como em A + B. O resultado da aplicao deste operador sobre vari-
veis booleanas igual a 1 se pelo menos uma das variveis for igual a 1. Caso contrrio, o resultado 0. Esta ope-
rao conhecida como soma lgica.
Existem vrias leis descritas pela lgebra de Boole que so teis no tratamento das equaes lgicas:
Lei da identidade: A + 0 = A e A 1 = A;
8
Lei do zero e do um: A + 1 = 1 e A 0 = 0;
Lei da inverso: A + = 1 e A = 0;
Lei da comutatividade: A + B = B + A e A B = B A;
Lei da associatividade: A + (B + C) = (A + B) + C e A (B C) = (A B) C;
Lei da distributividade: A (B + C) = (A B) + (A C) e A + (B C) = (A + B) (A+ C).
Alm dessas leis existem dois teoremas conhecidos como Teoremas de De Morgan, cuja formulao :


Sistemas de numerao e representao de dados
A nossa representao de nmeros baseada em um sistema de 10 algarismos (0 a 9), manipulados em mltiplos de 10. Esta
representao conhecida como a base 10.
J os computadores utilizam apenas dois smbolos (0 e 1), representados pela voltagem eltrica (ligado ou desligado). Essa
unidade de informao chamada de bit, e a abreviatura de binary digit, em ingls. Assim, um bit pode representar dois
nmeros, o 0 e o 1. Se usarmos dois bits, poderemos representar quatro estados diferentes, com trs bits, j so oito estados, e
assim por diante. Chamamos de um byte, o conjunto de oito bits, que pode representar 2
8
estados (256), ou os nmeros de 0 a
255.



Aritmtica computacional
As palavras de um computador so compostas por bits e podem representar nmeros armazenados na memria. Estes nme-
ros podem ter diferentes significados, como inteiros ou reais, serem positivos ou negativos:
Complementa Dois: Os computadores manipulam tanto nmeros positivos quanto nmeros negativos, que so re-
presentados em complemento a 2. Nesta conveno os nmeros que possuem 0s esquerda so considerados positi-
vos e os nmeros com 1s esquerda so considerados negativos. O complemento a 2 obtido invertendo-se o nme-
ro binrio e depois somando 1 a este valor.
Adio e Subtrao: Numa soma os bits so somados um a um da direita para a esquerda, com os carries sendo
passados para o prximo bit esquerda. A operao de subtrao usa a adio. O subtraendo simplesmente negado
antes de ser somado ao minuendo.
Multiplicao e Diviso: A multiplicao precisa apenas de dois passos principais: o teste do produto e o seu deslo-
camento. A diviso a operao recproca da multiplicao. Dentre as operaes aritmticas a que aparece menos
freqentemente nos cdigos dos programas.

Microprocessadores: Componentes
O processador (CPU) o componente vital de um sistema de computao, responsvel pela realizao das operaes de pro-
cessamento (clculos, entre outros) e de controle durante a execuo de um programa.
O ciclo bsico de uma instruo : BUSCA -> DECODIFICO -> EXECUO. Outra diviso (para pipelines) : Busca
(fetch), Decodificao, Busca do Operando, Execuo e Armazenamento do resultado.
9
O seu principal componente a UC (Unidade de Controle). O processador conta tambm com uma Unidade Lgica e Aritm-
tica (ALU), sendo que a sua ao complementada pelo uso de registradores de processamento. E tambm possui um clock,
fundamental para gerar pulsos e manter uma freqncia constante.
O processador tambm possui trs barramentos: de endereo, de dados e de controle.
Alguns registradores importantes, que fazem parte da unidade de controle so: PC (Program Counter), IR (Instruction Regis-
ter), MAR (Memory Address Register) e MBR (Memory Buffer Register).
As instrues executadas por um processador so as seguintes:
Operaes lgicas e aritmticas: somar, subtrair, multiplicar, dividir, and, or, xor, not,... ;
Movimentao de dados: memria-CPU, CPU-memria, registrador-registrador, ...;
Desvios: alterao da seqncia de execuo das instrues;
Operaes de entrada ou sada: para comunicao com dispositivos de I/O.
Note que o hardware e o software so logicamente equivalentes, ambos podem executar as mesmas funes.
A funo do processador executar programas armazenados na memria principal. Para isso ele conta tambm com uma
memria interna, os registradores. Revisando o passo a passo de execuo de um programa:
1. Busca instrues da memria para o registrador de instruo (IR)
2. Atualiza o contador de programa (PC)
3. Determina o tipo de instruo, e (se usar) localiza os dados na memria
4. Busca os dados (se houver) para registradores
5. Executa a instruo, e armazena resultados
6. Volta ao passo 1 para a prxima instruo

Microprocessadores: Arquitetura
No incio, mainframes, minicomputadores e microcomputadores possuam claras distines tcnicas, em relao quantidade
de memria, palavras de 32, 16 e 8 bits (respectivamente), etc. Mas no existe nenhuma diferena conceitual entre eles, hoje
em dia essa diferena ainda menor.
As arquiteturas de microprocessadores so classificadas pelo nmero e quantidade de instrues:
RISC (Reduced Instruction Set Computer): o conceito de processadores RISC foi levantado por John Cocke (da
IBM), em 1974. O seu argumento era que os processadores s utilizavam 20% das instrues, e quanto menos ins-
trues o processador conseguisse interpretar, menor o nmero de transistores (e menor o seu custo). Reduzindo o
nmero de transistores e instrues a um mnimo possvel, o processador conseguiria executar mais tarefas em um
tempo menor. Exemplos so o MIPS, Power PC, Sparc e DEC Alpha.
CISC (Complex Instruction Set Computer): Em contraste com o RISC, os chips CISC possuem uma grande quan-
tidade de instrues diferentes e complexas. Os programadores executam um nmero menor de instrues do pro-
cessador, pois cada instruo realiza tarefas mais complexas. Isso reduz o tamanho do cdigo, diminuindo a necessi-
dade de memria e armazenamento, e por conseguinte, diminuindo custos. Exemplos so os processadores da Intel.

Dispositivos perifricos
Em sistemas tais como microcomputadores e estaes de trabalho, as interfaces de E/S so ligadas ao processador atravs de
barramentos de endereo, dados e controle, de maneira semelhante conexo entre memria principal e processador. A orga-
nizao tpica de um computador incluindo o sub-sistema de E/S dado:
A comunicao entre a CPU e os perifricos feita normalmente atravs de uma controladora ou interface, o que permite o
CPU agir de maneira independente dos dispositivos, sem comunicao direta:
Polling: O programa checa o estado do perifrico manualmente. A CPU pode se manter ocupada at o trmino da
operao. Uma soluo checar de tempos em tempos, executando concorrentemente.
Interrupo: Ao terminar uma operao de E/S, uma interrupo gerada para o processador. Isso elimina a neces-
sidade de esperar pelo trmino, e vrias operaes podem ocorrer simultaneamente, atravs de um vetor de interrup-
10
o. Quando a CPU interrompida, ela pra e transfere a execuo para um local fixo (rotina de servio) para tratar
a interrupo (diviso por zero, acesso invlido...)
Spooling: Vm de Simultaneneous peripheral operation on-line, e uma tcnica para aumentar a eficincia dos sis-
temas operacionais, base do sistema batch. Um exemplo a utilizao de impressoras.
Canais de DMA (Direct Memory Access): um recurso da placa me que permite que os dispositivos perifricos
(placa de vdeo ou som, disco rgido, CD-ROM) acessem diretamente a memria RAM, sem consumir poder de pro-
cessamento da CPU (apenas no incio e no final da transferncia). Cada dispositivo pode ocupar apenas um canal.
Note que o processador no acessa a memria enquanto a controladora de DMA o faz (um s barramento), mas pode
usar a memria cache.

Conceitos de interrupes
Inicialmente, quando comeou-se a usar sistemas operacionais, um programa que estivesse sendo executado tomava o contro-
le da mquina e s quando o programa encerrava que o controle era devolvido para o sistema operacional. Quando ocorria
algum problema (por exemplo, um erro no programa) no havia meios do sistema operacional retomar o controle da mquina,
exceto com o usurio derrubando o sistema e recarregando o sistema operacional. Ficou ento evidente a necessidade de ha-
ver um meio do sistema operacional poder retomar o controle da mquina, em situaes de exceo.
Tambm ocorreu que as UCP's ficaram mais rpidas e mais eficientes, porm os dispositivos perifricos de E/S compatveis
progrediram menos em velocidade (ou seja, ficaram comparativamente mais lentos).
A resposta a estes problemas foi a utilizao do mecanismo de INTERRUPES. Interrupes so modificaes no fluxo de
controle causadas por uma ao externa, geralmente relacionada a Entrada ou Sada. Uma interrupo um sinal de controle
enviado por um agente externo (um dispositivo) ao microprocessador, quando um determinado evento detectado. A inter-
rupo um sinal de hardware.
Este mecanismo fora o processador a tratar o evento externo. A deteco de uma interrupo faz com que o processador
transfira o controle para uma rotina de tratamento de interrupo (interrupt handler). A rotina de tratamento de interrupes
faz o processador executar as seguintes aes:
1. Detectar a fonte da interrupo (o dispositivo que interrompeu)
2. Executar as aes apropriadas (que dependem do dispositivo)
3. Retornar ao ponto do programa em que estava quando iniciou o atendimento interrupo.
Interrupes de software (traps ou exceptions) so devidas a:
Algum evento gerado pela execuo de uma instruo, como uma diviso por zero, overflow, cdigo de operao in-
vlido, tentativa de acesso a uma rea de memria protegida ou inexistente, etc
A um evento programado.
Traps so sncronas com o programa, enquanto interrupes associadas E/S so assncronas.

Estruturas de endereamento
Os processadores podem acessar a memria de vrios modos diferentes. A flexibilidade em seu acesso garante uma maior
facilidade e performance ao trabalhar com variveis, arrays, registros, ponteiros e outros dados.
Imediato: a instruo contm o prprio operando. Mais rpido, mas a faixa de valores menor.
Direto: instruo contm o endereo de memria com o operando. Ex: mov a, 25h (do incio da mem)
Indireto: instruo contm o endereo de memria com o apontador para o endereo com o operando. Mais lento.
Com registrador: instruo contm o registrador com o operando. Equivalente ao direto. Ex: mov ax, bx
Indexado: instruo contm o (registrador + ndice) que aponta para o endereo de memria com o operando.
Registrador-base: Instruo contm o (reg. base + deslocamento) que aponta para o endereo com o operando.
Com pilha: h um apontador de pilha, e utiliza-se instrues pop/push para obter o operando.

11
Compiladores, Ligadores e Interpretadores.
Existem dois tipos de aplicaes para converter um cdigo em uma linguagem para cdigo de mquina:
Compilador: traduz um programa escrito em uma linguagem de alto nvel em cdigo objeto. Esse cdigo objeto
ento ligado (linked) com os mdulos de biblioteca de outros programas, para produzir um executvel. O arquivo ge-
rado pode ser ento executado por um carregador, que tambm possui a funo de resolver endereamentos e outras
tarefas que dependem do sistema operacional. Exemplo: C, C++, Pascal.
Interpretador: interpreta e executa um cdigo ao mesmo tempo. Ele no produz um arquivo executvel, pois a sua
sada depende do cdigo fonte e dos valores de entrada. Exemplo: BASIC.

12
Sistemas Operacionais
O sistema operacional responsvel por gerenciar todos os recursos de uma mquina, facilitando a inter-face entre o hardwa-
re e o software do computador. Esses recursos incluem o processador (pode ser mais de um), a memria, os dispositivos de
entrada e sada (impressora, monitor, teclado, etc), interfaces de rede, entre outros.
Esse gerenciamento de recursos de uma mquina uma tarefa complexa, que encapsulada pelo sistema. Imagine a tarefa de
alocar um programa na memria. preciso assegurar que h memria disponvel suficiente, e que o local (endereo) onde o
programa ser alocado pode ser utilizado. Alm disso, todas referncias ao programa devem apontar para este mesmo endere-
o, e quando ele terminar, esse espao deve ser liberado. Esta apenas uma das tarefas do sistema operacional (SO).
Seria impraticvel deixar a tarefa do gerenciamento de todos os recursos de um computador (principalmente o disco, proces-
sador e memria) aos programadores. Uma tarefa do sistema operacional fornecer uma interface amigvel para o programa-
dor, que pode utilizar funes de alto nvel, como "Abrir Arquivo" ou "Ler Disquete" ao invs de ser obrigado a lidar com as
interfaces complexas de discos rgidos ou unidades de disquetes.
Tanenbaum cita o exemplo de trs programas tentando imprimir as suas sadas simultaneamente a uma mesma impressora. O
resultado seria catico, pois as linhas de cada programa poderiam sair intercaladas em uma mesma folha. O SO evitaria este
cenrio, imprimindo a sada de cada programa em sua devida ordem.

Conceitos Bsicos
Como j explicado, o Sistema Operacional um programa que atua entre o usurio e o hardware do computador, e proporcio-
na um ambiente para executar programas de forma conveniente e eficiente.
Em resumo, o SO um alocador de recursos e um programa de controle. A sua evoluo dada a seguir:
Sistema em batch: funcionava atravs da leitura
de cartes perfurados, e sua memria possua ape-
nas o SO e um espao para o programa do usurio.
Sistemas multiprogramados: a introduo dos
discos permitiu que os jobs fossem escalonados pelo SO.
Vrios programas podiam residir na memria.
Sistemas de tempo compartilhado: permitiu a interao
de vrios usurios (multitarefa), adicionando o recurso de gerncia de memria e proteo. O PC faz parte desta categoria.
Sistemas paralelos ou multiprocessados: com o objetivo de aumentar o throughput, mais de um processador compartilham
o barramento, clock, memria, etc. Tambm h aumento da confiabilidade (tolerncia falhas). Um sistema multiprocessado
possui uma programao mais complexa (Fortemente Acoplado).
Sistemas de tempo real: sistemas crticos, onde o processamento deve ser feito dentro de um limite de tempo.
Sistemas distribudos: permitem que vrios computadores, que NO compartilham memria ou clock, se comuniquem atra-
vs de uma rede para completar uma tarefa. Um sistema distribudo um conjunto de computadores que age como uma m-
quina nica (Fracamente Acoplado).
A arquitetura dos computadores e sistemas operacionais em geral pode ser classificada quanto sua histria:
Primeira Gerao: vlvulas e painis. Toda a programao era feita em cdigo absoluto.
Segunda Gerao: transistores. Computadores mais confiveis, os sistemas batch j podiam ser implementados, lei-
tura de cartes e linguagens de programao como FORTRAN ou linguagens de montagem.
Terceira Gerao: as tcnicas de SPOOL, tempo compartilhado e multiprogramao foram implementadas. Vrios
terminais em uma mquina.
Quarta Gerao: circuitos integrados, surgindo a noo de computador pessoal. Tais mquinas passaram a se inter-
conectar em rede, tiveram um grande aumento de seu poder de processamento e interatividade (user-friendly).
Quinta Gerao: comeando em 1991, foram implementados sistemas especialistas, multimdia e distribudos, a
simplificao e miniaturizao dos computadores. Os Pentiums da Intel se enquadram nessa categoria.
Prximas Geraes: especulam sobre os computadores qunticos, que sero a "sexta" gerao de computadores.



13
Gerenciamento de Processos
Um programa uma seqncia de instrues que descrevem a execuo de uma tarefa. Um processo um programa em
execuo. O estado de um processo consiste do programa, da prxima instruo a ser executada, os valores das variveis uti-
lizadas, e o status dos dispositivos de entrada e sada.
Para guardar o estado de um processo, criado um vetor de estado, que armazena todas as partes mutveis do processo, ou
seja, todos citados acima, menos o programa, que imutvel (em boas prticas de programao).
Para evitar que um programa acesse a rea de outro, pode ser utilizado um registrador de base e outro de limite, com o espao
de endereamento lgico do programa em execuo. O prprio SO possui um mecanismo para se proteger de processos, que
so os bits de proteo (modo usurio e modo privilegiado / monitor).
Processos precisam de tempo de CPU, memria, arquivos e dispositivos de I/O para realizar a sua tarefa. Estes recursos po-
dem ser alocados durante a sua criao ou a sua execuo. O Sistema Operacional deve:
Criar e excluir processos de usurio e de sistema
Suspender e retomar processos
Dar mecanismo para a sincronizao e comunicao de processos
Tratar deadlocks

O escalonamento de CPU tem origem com a introduo de sistemas multiprogramados. Sempre que um processo precisa
esperar (E/S), outro processo pode assumir o uso da CPU.
O escalonamento desse tipo uma funo fundamental do sistema operacional. Quase todos os recursos do computador so
escalonados antes do uso, e esse escalonamento vital para o projeto do Sistema Operacional.
Diferentes algoritmos de escalonamento de CPU possuem diferentes propriedades e podem favorecer uma classe dos proces-
sos em detrimento de outro. Alguns critrios de escalonamento so:
Ciclo de Burst CPU E/S: Essa ser a medida adotada para caracterizar cada processo em nosso algoritmo. A execuo de
um processo comea com um burst (surto) de CPU, que seguido por um burst de E/S, que por sua vez, seguido por outro
burst de CPU, depois outro burst de E/S, e assim por diante. Por fim, o burst de CPU final termina com uma requisio do
sistema para terminar a execuo.
Turnaround (tempo de retorno): tambm conhecido como tempo de execuo. Do ponto de vista de um processo
especfico, o critrio importante o tempo necessrio para executar esse processo. O intervalo desde o momento da
submisso de um processo at o momento do trmino o turnaround. O turnaround a soma dos perodos gastos es-
perando para entrar na memria, esperando na fila de processos (ready queue), executando na CPU e realizando E/S.
Tempo de espera: a soma dos perodos gastos aguardando na fila de espera. Para sistemas interativos (como de
tempo compartilhado) busca-se uma varincia no tempo de resposta do que minimizar o tempo de resposta mdio.
Alguns algoritmos de escalonamento de processos so:
FCFS (First Come First Served): neste escalonamento, o primeiro processo a chegar na fila o primeiro a ser atendido, o
que maximiza o seu throughput.
Round Robin: no escalonamento RR ou circular, os processos so organizados numa fila segundo sua ordem de chegada,
sendo ento despachados para execuo. No entanto, ao invs de serem executados at o fim (completion), a cada processo
concedido apenas um pequeno intervalo de tempo (time slice ou quantum). Caso o processo no seja finalizado neste interva-
lo de tempo, ocorre sua substituio pelo prximo processo na fila de processos ativos, sendo o processo em execuo inter-
rompido e novamente colocado na fila de processos prontos, mas em seu fim. Isto significa que ao final de seu intervalo de
tempo, isto , de seu quantum, ocorre a preempo do processador, ou seja, o processador designado para outro processo

Gerenciamento de Memria
A memria o local onde os programas e dados so armazenados. A codificao binria (bits) foi escolhida para representar
a informao, pois mais confivel (e no mais eficiente!).
Uma clula de memria a menor unidade enderevel. Cada clula tem um endereo nico, e geralmente ocupam um byte,
uma palavra, ou outra unidade.
14
Para evitar que dados sejam interpretados como instrues, ou vice-versa, um bit extra pode ser usado para cada clula para
indicar o seu contedo. Na verdade vrios bits extras podem existir com vrias finalidades.
O processador central l e grava na memria, assim como a controladora de DMA. Os programas devem ser mapeados para
endereos absolutos, e instrues e dados so acessados. Alm disso, vrios programas ficam ao mesmo tempo na memria.
O sistema operacional responsvel por:
Manter um registro das reas ocupadas da memria (e por quem)
Decidir quais os processos que iro residir na memria
Alocar e desalocar espao na memria, conforme necessrio
A CPU se comunica com a memria atravs dos registradores MAR e MBR, j explicados anteriormente.
A amarrao de endereos lgicos (binding de programas executveis) com fsicos (da memria principal) feita:
em tempo de compilao: usado em arquiteturas antigas, onde o programa era sempre carregado na mesma posio
da memria. S faz sentido com monoprogramao
em tempo de carga: executvel contm mapa de relocao. O programa interpretado, e os endereos corrigidos.
em tempo de execuo: h necessidade de hardware especial. Exemplo: registrador base cujo valor sempre soma-
do a endereo lgico.

Alocao Contgua Simples
A memria principal dividida em duas parties: Sistema Operacional (parte baixa) e Processo do Usurio (restante da me-
mria). O usurio tem controle total da memria, inclusive da rea do SO (Ex.: DOS). A proteo (bits de proteo) foi poste-
riormente includa, assim como registradores de base e limite.
Relocao o processo de designar endereos de carga s vrias partes do programa, ajustando cdigo e dados para refletir os
endereos designados.

Alocao Contgua Particionada
Imposta pela multiprogramao, existem mltiplas parties, e a memria dividida em blocos. Cada partio pode receber
um processo (programa), mas no considera a existncia do Swapping. Para corrigir fragmentao interna nas parties, o seu
tamanho passou a ser dinmico, e no fixo. Mas isso tambm pode gerar fragmentao externa (pedaos livres da memria).
Algoritmos para alocao contgua: First Fit (primeiro espao), Best Fit (menor espao livre) e Worst Fit (maior espao).
Swapping: uma tcnica para evitar a fragmentao externa, e lidar com a falta de espao em memria, j que os processos
precisam estar na memria principal para serem executados. Mas nunca deve ocorrer em processos com E/S pendentes.

Segmentao
espao lgico do programa dividido em unidades que tm sentido para o programa: segmentos
cada segmento pode ser alocado na memria fsica de forma independente

Paginao
Mapeamento entre pginas fsicas (frames) e pginas lgicas (pages)
mapeamento de endereos atravs de uma tabela de pginas
h fragmentao interna
cache da tabela de pginas: TLB (Translation Look-aside buffers). Mas como o seu tamanho limitado (de 8-2048
entradas), h a possibilidade de paginao multinvel, para gerar tabelas de pginas menores
conjunto de trabalho: pginas referenciadas por um programa. desejvel: espao de endereamento fsico > con-
junto de trabalho. Obs.: espao de endereamento virtual > espao de endereamento fsico
15


Controle de espao livre
blocos de tamanho varivel: listas encadeadas
blocos de tamanho fixo: bitmaps

Memria Virtual
Permite que o programa utilize um espao de endereamento virtual maior que a memria fsica total.
parecido com swapping mas muito mais eficiente. Com swapping, o espao de endereamento de cada processo tem
que ser menor que a MP; o que pode ser maior que a MP a soma dos espaos de endereamento de todos os pro-
cessos.
Apenas algumas das pginas virtuais tm um correspondente fsico em cada instante; as demais pginas so marca-
das como invlidas na tabela de pginas.
Quando um programa faz um acesso a uma pgina que no est carregada na MP, a MMU (Memory management
Unit) gera um trap para o sistema operacional, que entra em ao para carregar a pgina requisitada.

Sistemas de Arquivos
O Sistema Operacional fornece uma viso lgica uniforme do armazenamento. O conceito abstrato de arquivo serve para or-
ganizar os dados e seus acessos. O SO responsvel por:
Criar e excluir arquivos ou diretrios
Fornece suporte a primitivas para manipula-los
Mapear arquivos no armazenamento secundrio
Fazer backup de arquivos nos meios estveis (no-volteis)

As informaes so gravadas nos discos em "setores", distribudos ao longo de "trilhas" concntricas marcadas magnetica-
mente como setores circulares no disco, conforme ilustrao a seguir.
O processo de marcao magntica das trilhas e setores em um disco faz parte da "formatao" do disco. Esta formatao
dependente do sistema operacional que usar o disco. O sistema operacional DOS define que cada setor armazena 512 bytes.
Todas as trilhas armazenam o mesmo nmero de bytes; desta forma, os dados na trilha mais interna estaro gravados com
maior densidade, pois o espao fsico menor.
Tempo de Acesso: o tempo de acesso aos dados de um disco definido como o perodo decorrido entre a ordem de acesso e
o final da transferncia dos dados. O tempo de acesso no constante, variando em funo da posio relativa entre o brao
atuador (que posiciona as cabeas de leitura e gravao) e o setor que ser lido e portanto s tem sentido falar em tempo m-
dio de acesso. Os tempos mdios de acesso dos discos atuais so da ordem de 10 ms e resultado das seguintes operaes:
16
TEMPO DE ACESSO = TEMPO DE (SEEK + LATNCIA + TRANSFERNCIA)
Tempo de Seek: seek ou busca o tempo gasto na interpretao da localizao do dado no disco (endereo do dado
no disco) pela unidade de controle e no movimento mecnico do brao que sustenta a cabea magntica, at alcanar
a trilha desejada. Este tempo varivel de acesso para acesso. os tempos tpicos de discos rgidos atuais podem vari-
ar de aproximadamente 0 ms (referente ao acesso a um setor localizado na mesma trilha onde no momento est a ca-
bea de leitura), 3 ms (para acesso a setores em trilhas adjacentes) a at 20 ms (referente ao acesso entre trilhas loca-
lizadas nas extremidades do disco). Este tempo diretamente dependente da qualidade dos mecanismos eletromec-
nicos que comandam os braos atuadores. Discos de menores dimenses tambm tendem a ser mais rpidos.
Tempo de Latncia: tambm chamada latncia rotacional, o tempo gasto entre a chegada da cabea de leitura /
gravao sobre a trilha e a passagem do setor desejado na posio da cabea. Como o disco permanece constante-
mente girando, a cabea magntica s pode ler ou gravar um dado quando o setor endereado est imediatamente
abaixo dela. Portanto, h que aguardar que o disco gire at que o setor endereado fique posicionado abaixo da cabe-
a. Esse tempo depende diretamente da velocidade com que o disco gira (5400, 7200 RPM, etc)
Tempo de Transferncia: o tempo consumido na transmisso dos bits entre computador e disco e vice-versa. Este
tempo depende da interface e do disco, que definem o throughput (taxa de transferncia) do disco. Atualmente, de-
pendendo da interface, o throughput seria da ordem de at 33 Mbytes/s. Como um setor tem 512 bytes, em 1 ms se
poderia transferir cerca de 33 setores e o tempo de transferncia de um setor seria da ordem de 15 ns.
Obs.: Os tempos relativos a unidades (drivers) de disquetes so muito maiores que os acima indicados para discos rgidos.
Drivers de disquete giram a aproximadamente 300 rpm e o throughput da ordem de 500 kbytes/s; os tempos de acesso m-
dios so da ordem de 60 a 100 ms.
Aps a formatao fsica, temos um HD dividido em trilhas, setores e cilindros. Porm, para que este disco possa ser reco-
nhecido e utilizado pelo sistema operacional, necessria uma nova formatao, chamada de formatao lgica. A formata-
o lgica consiste em escrever no disco a estrutura do sistema de arquivos utilizado pelo sistema operacional.
Um sistema de arquivos um conjunto de estruturas lgicas e de rotinas que permitem ao sistema operacional controlar o
acesso ao disco rgido. Diferentes sistemas operacionais usam diferentes sistemas de arquivos. Os principais so:
FAT16 (File Allocation Table): utilizado pelo MS-DOS, Windows 95 e compatvel com Windows 98, permitindo
um mximo de 65526 clusters, que no podem ser maiores que 32 KB. A principal desvantagem desse sistema o
desperdcio de espao para parties maiores que 1 Gb, e o seu tamanho mximo por partio limitativo, de 2 Gb.
VFAT: extenso da FAT16, que ao invs de permitir apenas arquivos com 11 caracteres (8.3), reserva uma rea com
nomes grandes, fazendo com que o MS-DOS interprete os arquivos como "Arquiv~1", "Arquiv~2", etc.
FAT32: utiliza 32 bits de endereamento para cada cluster, de apenas 4 Kb cada. Utilizado pelo Windows 95 e 98, a
maior desvantagem o alto nmero de clusters, diminuindo o desempenho. Tamanho mximo de 2 Terabytes.
NTFS (New Technology File System): sistema de arquivos de 32 bits onde os setores do disco so endereados di-
retamente. Cada unidade de alocao possui apenas 512 bytes, evitando o desperdcio de disco. Utilizado pelo Win-
dows NT em diante. um sistema mais seguro e confivel que o FAT, alm de flexvel e adaptvel.
EXT2: um sistema de arquivo utilizado apenas pelo Linux, que apresenta vrios recursos avanados de segurana
e suporte a parties de at 4 Terabytes. Outros sistemas relacionados so o EXT3, RaiserFS, etc.

Gerenciamento de Dispositivos
O Sistema operacional deve ocultar os detalhes de dispositivos de I/O de usurios. Ele deve:
Fornecer uma interface geral de driver de dispositivos especficos
Fornecer um componente de buffering, armazenamento em cach e spooling.
Para evitar que a CPU fique presa por longos perodos em Entrada e Sada, podem existir processadores especializados de
E/S, de baixo custo.
Alm disso, o sistema operacional guarda uma tabela de status de dispositivos, com o registro de pedidos de I/O simult-
neos.
O DMA utilizado para evitar que transferncias de I/O rpidas (sncronas), como fitas, disco ou rede de comunicao, no
interrompam o CPU a cada byte transferido. O DMA transfere diretamente para a memria, sem interrupo da CPU. Uma
interrupo gerada apenas a cada bloco, para encontrar um buffer e configurar os registradores (com endereos inicial e fi-
17
nal). Como a memria s pode transferir 1 palavra / ciclo, a CPU s vezes concorre com o DMA para realizar operaes de
acesso memria (apenas um barramento).
O cdigo ASCII um mapeamento de bits para caracteres de texto, por exemplo: 0 (47), A (65) e a (97).

Concorrncia
A programao concorrente pode ocorrer de duas formas diferentes:
Processos: ocupam espaos de endereos diferentes, e se comunicam usando pipes oferecidos pelo sistema opera-
cional.
Threads: ocupam o mesmo espao de endereo de uma aplicao, e a comunicao feita por um mecanismo da
linguagem de programao (a JVM do Java oferece um mecanismo multithreading)
Em alguns tipos de aplicaes, threads so essenciais, como no caso de aplicativos com interface grfica, em que o programa
pode esperar interao do usurio enquanto processa alguma tarefa. Outro exemplo so servidores que podem esperar por
requisies de novos clientes enquanto lidam com requisies j enviadas.
Para que dois ou mais processos possam ter acesso a um mesmo recurso compartilhado, existe um mecanismo que controla
este acesso, chamado de mecanismo de sincronizao. Enquanto um processo estiver acessando determinado recurso, todos
os outros que queiram acess-lo devero esperar. Isso se chama Excluso Mtua.
A tentativa de implementar a excluso mtua nos programas traz alguns problema. Os mais freqentes so:
Velocidade de execuo dos processos: quando um processo mais rpido obrigado esperar que um lento use o
recurso e o libere. Um gargalo gerado pela consistncia dos processos onde o mais rpido ficar limitado velocida-
de do mais lento. O sistema todo fica lento como conseqncia
Starvation: o SO determina as prioridades dos processos, de duas formas diferentes: por escolha aleatria ou por
prioridades. Quando a escolha aleatria, existir a probabilidade de um processo nunca ser escolhido, quando for
uma escolha por prioridades, um processo de menor prioridade nunca receber o acesso ao recurso, e ai este proces-
so nunca executar sua rotina.
Sincronizao condicional: quando um recurso no est pronto para ser utilizado, o processo que vai acessar o re-
curso ficar em estado de espera at que o mesmo esteja pronto. Existe o risco deste recurso nunca ficar pronto por
j estar com problemas. Ento todo o sistema fica em espera.
Algumas solues implementadas para lidar com este problema so:
Semforos: um semforo uma varivel associada a um recurso compartilhado, indicando quando este est sendo
acessado por um outro processo. Quando um processo entra ou sai da regio crtica, o seu valor alterado, de forma
que outros processos possam entrar na regio. Existe uma fila de espera associada ao semforo, onde os processos
tero acesso ao recurso na ordem de chegada.
Monitores: so mecanismos de sincronizao compostos de um conjunto de procedimentos, variveis e estrutura de
dados definidos dentro de um mdulo cuja finalidade a implementao automtica da excluso mtua entre seus
procedimentos. A implementao feita pelo compilador
Troca de mensagens: um mecanismo de comunicao e sincronizao entre os processos, implementado pelo sis-
tema operacional atravs de duas rotinas do sistema SEND (envio de mensagem para o processo receptor) e
RECEIVE (recebimento do processo transmissor). No sistema de troca de mensagens, existe a possibilidade da men-
sagem se perder. J o Endereamento Indireto, que o uso de uma rea compartilhada para a troca de mensagens.

Concorrncia: Deadlocks
Um problema da concorrncia quando mtodos sincronizados chamam outros mtodos sincronizados. Isso pode causar de-
adlock, quando uma thread A espera a liberao de um objeto, que est com a thread B. Mas esta s vai liberar o objeto aps
uma alterao de outra thread (A, por exemplo), monopolizando-a. Exemplos:
Cenrio 1 (No ocorre deadlock), saldo do caixa: R$0.00
Cliente 1 atendido (recebe acesso do caixa), deposita 1000 reais e libera o caixa
Cliente 2 atendido (recebe o acesso do caixa), saca 800 reais e libera o caixa.
Cenrio 2: (Ocorre deadlock), cliente 2 chega antes de cliente 1
18
Cliente 2 atendido, tenta sacar 800 reais mas no h saldo. Cliente 2 espera haver saldo.
Cliente 1 quer ser atendido (quer depositar 1000 reais) mas no sua vez na fila. Ele espera a sua vez.
Soluo: Evitar que mtodos sincronizados chamem a outros mtodos sincronizados. Caso no seja possvel, controlar libe-
rao e retorno dos acessos (hierarquia de chaves de acesso).
As quatro condies necessrias para ocorrer deadlocks (todas devem ser verdadeiras) so:
Excluso mtua: existe um recurso no-compartilhado (um processo por vez o usa)
Posse e Espera: um processo mantm um recurso, e espera por outro de outro processo.
No-Preempo: um recurso s pode ser liberado voluntariamente.
Espera Circular: um processo P0 espera por P1, P1 por P2, ..., Pn espera por P0.
19
Redes de Computadores
Os primeiros sistemas de computadores eram grandes e caros. Os seus usurios organizavam as tarefas a serem processadas
em jobs, e o computador fazia o processamento em lote (batch). As tarefas eram executadas uma a uma, organizadas em uma
fila de entrada. Na dcada de 80 surgiram os terminais remotos, que permitiram que os usurios pudessem acessar os compu-
tadores atravs de linhas de comunicao. Nesta mesma poca surgiu o conceito de tempo compartilhado (time sharing), para
otimizar o uso de mainframes. Os terminais passaram a ser ligados ao computador central por cabos e novos recursos surgi-
ram utilizando esta interconexo.
As redes modernas tm razes nos primeiros sistemas de telefones e telgrafos. Para lidar com o aumento no nmero de usu-
rios, foi preciso criar novos meios de distribuir o processamento e utilizao dos outros recursos pelas redes, criando o con-
ceito de multi-processamento e sistemas de processamento distribudos. Na dcada de 60, o governo dos EUA iniciou o proje-
to ARPA (Advanced Research Project Agency).
Uma rede de computadores um conjunto de mdulos processadores capazes de trocar informaes. Seus objetivos so:
Compartilhamento de recursos: Permite que programas, dados, rea de armazenamento, perifricos, entre outros
recursos, estejam disponveis para qualquer um na rede, independente de sua localizao fsica. Este a principal
motivao para o uso de redes de computadores.
Aumento na Confiabilidade: Considerando que passa a existir redundncia dos recursos compartilhados pela rede,
a confiana de um sistema projetado para ter tolerncia falhas aumenta.
Reduo de Custos: O custo benefcio de um microcomputador em relao ao seu processamento muito mais bai-
xo que o de um mainframe, logo a fragmentao do processamento desejvel.
Escalabilidade: A possibilidade de aumentar o processamento do sistema gradualmente, a medida que cresce o vo-
lume do trabalho, adicionando novos mdulos processadores, permite adiar custos.
Cooperao: Pessoas distantes geograficamente podem trabalhar e cooperar de forma conjunta.

Comunicao de dados
A comunicao de dados em nvel global tornou-se uma realidade do nosso tempo. O desafio que a comunicao de voz re-
presentou para as geraes passadas volta atualmente, sob a forma de aplicaes de telemtica, em vrias modalidades de
troca de informao entre computadores heterogneos situados em ambientes remotos, interconectados atravs dos sofistica-
dos meios oferecidos pela engenharia de telecomunicaes.
A Comunicao de Dados diz respeito ao modo como os dados so manipulados, transformados e transportados entre pontos
quaisquer. Exemplos disso so os modos simplex (unidirecional), half-duplex (uma direo de cada vez) e full-duplex de co-
municao, as bandas passantes, as modulaes de sinais e a criptografia.
As Redes de Computadores so mecanismos que utilizam a comunicao de dados e existem para prover: comunicao entre
pontos, compartilhamento de recursos e confiabilidade da integridade dos dados transferidos.

Meios de transmisso
Basicamente existem dois tipos de tecnologias de meios de transmisso:
Redes em Difuso: Apenas um canal de transmisso compartilhado por todas as mquinas.
Redes Ponto-a-Ponto: Existem vrias conexes entre pares individuais de estaes.
A transmisso de dados, quando realizada nos dois sentidos denominada duplex. No caso em que ela se realiza alternada-
mente, ou seja, ora num sentido, ora no outro, ela se denomina half-duplex. No caso em que ela se realiza simultaneamente
nos dois sentidos, esta ser denominada full-duplex.
Os bits podem ser transmitidos de forma paralela, onde so simultaneamente transportados por vrias linhas (mais adequado
comunicao entre equipamentos prximos), ou serial, onde os bits so encaminhados atravs de uma nica linha de comu-
nicao (ideal para equipamentos muito distantes). A forma de delimitar os bits pode levar em conta duas diferentes filosofias
a transmisso serial sncrona e a serial assncrona.
Transmisso sncrona: os bits de dados so transmitidos segundo uma cadncia pr-definida, obedecendo a um si-
nal de temporizao (clock). O receptor, conhecendo os intervalos de tempo permitindo delimitar um bit, poder i-
dentificar a seqncia dos bits fazendo uma amostragem do sinal recebido
20
Transmisso assncrona: a separao entre os bits feita atravs de um sinal especial com durao varivel. Um
caso tpico a transmisso de caracteres; onde a cada grupo de bits constituindo um caractere so adicionados bits
especiais para representar o incio (start bit) e final deste (stop bit).

Redes locais e de longa distncia
As redes so classificadas pela sua escala, que residem basicamente em trs grupos:
LAN Local Area Network ou Rede Local (normalmente uma sala, edifcio ou campus).
MAN Metropolitan Area Network ou Rede Metropolitana (at o tamanho de uma cidade).
WAN Wide Area Network ou Rede Geograficamente Distribuda (ou de Longa Distncia).

Topologias
A topologia de uma rede descreve como o layout do meio atravs do qual ocorre o trfego de informaes e tambm como
os dispositivos esto conectados a ele. Refere-se ao relacionamento fsico e lgico de cada n da rede (cada ponto de conexo
com a rede pode ser chamado de n, independente da funo do equipamento representado por ele), ou seja, a forma como
esto dispostos. Temos aqui ento a diviso
Topologia lgica: descreve como as informaes devem transitar ao longo da rede, o formato dos dados, etc. a
forma como os protocolos operam no meio fsico;
Topologia fsica: refere-se disposio dos cabos e componentes do meio fsico, descrevendo onde cada n da rede
est situado fisicamente em relao aos demais, como feita a distribuio da mdia de conexo (cabeamento de co-
bre, fibra ptica, wireless, etc) e mostra a configurao geral da rede atravs da planta de localizao dos equipamen-
tos.
O ambiente de funcionamento tambm influencia na escolha da topologia de uma rede. Ambientes ruidosos e com problemas
de segurana tm requisitos mais exigentes quanto ao nmero mximo de ns, a separao mxima e mnima entre ns e a
taxa mxima de informao trans-
mitida. Alguns protocolos, por e-
xemplo, levam em conta a distncia
mxima entre os ns da rede para
seu perfeito funcionamento.
Ao lado esto relacionadas as topo-
logias de redes ponto-a-ponto.
O envio de mensagens feito de
forma indireta, de forma que cada
estao recebe o contedo integral
da mensagem at ela alcanar o seu
destinatrio.



Tipos de
Topologias
Ponto Positivos Pontos Negativos
Topologia Estrela
mais tolerante a falhas
Fcil de instalar usurios
Monitoramento centralizado
Custo de Instalao maior porque
recebe mais cabos
Topologia Anel
(Token Ring)
Razoavelmente fcil de instalar
Requer menos cabos
Desempenho uniforme
Se uma estao para todas param
Os problemas so difceis de isolar.
Topologia Barra-
Simples e fcil de instalar
Requer menos cabos
A rede fica mais lenta em perodos
de uso intenso.

21
mento Fcil de entender Os problemas so difceis de isolar.

As redes em difuso, por outro lado, possuem apenas um barramento, sendo
utilizadas em redes locais (curta distncia). As mensagens so enviadas para
todas as estaes.
Um campo de endereo identifica a mensagem, e as estaes que no so as
destinatrias ignoram a mensagem. Uma caracterstica deste tipo de rede o
broadcasting, ou a possibilidade de enviar uma mesma mensagem a vrias
estaes, atravs de um cdigo especial no campo de destinatrio.
Outro exemplo de redes de difuso a transmisso por satlites.

Servios de comunicao
Define-se por servio o conjunto de operaes que uma camada capaz de oferecer camada superior. Ela define o que uma
camada capaz de executar sem se preocupar com a maneira como so executadas.
As camadas de uma arquitetura de rede podem oferecer diferentes classes de servios s camadas superiores. Estes servios
podem ser orientados a conexo ou no (sem conexo).
Com conexo: Anlogo ao servio telefnico, precisa iniciar uma conexo, para enviar a mensagem, e caracterizar
trmino da conexo. Ela funciona como um canal virtual na realizao do servio.
Sem conexo: Anlogo ao sistema postal, cada mensagem contm o endereo do destinatrio e pode ser encaminha-
da ao sistema independente de outras. O princpio bsico apenas enviar a mensagem.
Uma diferena nestes dois tipos de servios, que quando ele orientado a conexo, as mensagens so sempre recebidas pelo
destinatrio na ordem de envio, o que pode no acontecer no servio sem conexo.
Os servios sem conexo so denominados servios de datagrama (ex: correio eletrnico). Um datagrama um pacote de
informao que contm os dados do usurio, permitindo sua transferncia numa rede de pacotes.
Outra caracterstica de servios de comunicao a sua qualidade de servio, podendo ser classificados em:
Confivel: Os dados no so perdidos jamais (utilizam algum mecanismo de recuperao).
No confivel: Dados podem eventualmente se perderem e no recuperados pela camada em questo.
A implementao de servios confiveis geralmente utiliza mensagens de reconhecimento no destinatrio, ou seja, uma con-
firmao que a mensagem foi recebida, o que nem sempre desejvel (performance, etc).
Um servio definido atravs de um conjunto de primitivas aos usurios, divididas em quatro classes:
Request: Pedido enviado por uma entidade (um processo de uma camada) que solicita um servio
Indication: A entidade par informada de uma solicitao de servio
Response: A entidade par responde ao pedido de servio
Confirm: A entidade solicitante informada do resultado do servio
Em pedidos no confirmados, apenas as duas primeiras primitivas so utilizadas (o pedido e a indicao). Ex:
1. Voc disca o nmero do telefone de outra pessoa (CONNECT.request)
2. O telefone da outra pessoa toca (CONNECT.indication)
3. Ela atende dizendo al (CONNECT.response)
4. Voc ouve o al da outra pessoa (CONNECT.confirm)
5. Voc solicita uma informao( DATA.request)
6. A pessoa ouve a solicitao (DATA.indication)
7. Ela informa o que voc solicitou (DATA.request)
8. Voc ouve a informao (DATA.indication)

22
9. Voc desliga seu telefone( DISCONNECT.request)
10. A pessoa ouve o sinal desconexo e faz o mesmo (DISCONNECT.indication)

Protocolos
O protocolo define um conjunto de regras que permitem especificar aspectos da realizao do servio. Basicamente indica o
significado dos quadros, pacotes ou mensagens trocadas entres as entidades de cada camada. Existe um desacoplamento entre
o conceito de protocolo e servio, entre duas camadas.
Muitos protocolos conhecidos fazem parte do conjunto TCP/IP (Internet Protocol Sute), como os seguintes:
IP: Protocolo no orientado a conexo e no confivel, define o datagrama e endereamento IP.
ICMP: Utilizado para a verificao da rede, atravs de comandos PING, por exemplo.
IGMP (Internet Group Message Prococol): Utilizado para a formao de grupos multicast em uma rede IP.
ARP (Adress Resolution Protocol): Protocolo de resoluo de endereos, associa endereos fsicos com a numera-
o do IP. O RARP (Reverse ARP) faz o contrrio, requisito o endereo IP de uma mquina a partir de um endereo
fsico MAC (Media Access Control).
TCP (Transmission Control Protocol): Protocolo orientado a conexo e confivel,, possui informao de origem e
destino (camada de transporte). Sua transmisso se d atravs de segmentos.
UDP (User Datagram Protocol): No orientado a conexo e nem confivel, mas muito leve.
Telnet: Servio de terminal virtual que permite sesses remotas sobre a rede (porta default 23).
FTP (File Transfer Protocol): Servio de transferncia de arquivos (porta default 20 e 21).
DNS (Domain Name Service): Servio de traduo de nomes de hosts em endereos IP.
DHCP (Dynamic Host Configuration Protocol): Controla e disponibiliza endereos IP para os clientes de rede que
o requisitam. A vantagem que o endereo IP no precisa ser fixo.
NFS (Network File System): Sistema de arquivos remotamente acessvel.
NNTP (Network News Transfer Protocol): protocolo utilizado por programas clientes de notcias (que expiram).
SMTP (Simple Mail Transfer Protocol): Protocolo para o envio de e-mails mais utilizado.
SNMP (Simple Network Management Protocol): Gerencia redes conectadas em um nico ponto.
POP3 (Post Office Protocol 3): Protocolo para o recebimento de e-mails mais utilizado.
HTTP (HyperText Transfer Protocol): Para transmisso de pginas Web (porta default 80).

Equipamentos
Um sistema de rede de computadores possui vrios equipamentos (componentes) a sua disponibilidade:
(FIS) Mutiplexadores: um dispositivo cuja funo permitir que mltiplas estaes de trabalho possam comparti-
lhar uma linha de comunicao, pois a linha tem capacidade suficiente (banda) para suportar seu uso compartilhado.
Com isso, multiplexadores reduzem o nmero de linhas de comunicao necessrios, conseguindo uma reduo nos
custos pois diminuem o cabeamento necessrio.
(FIS) Repetidores: utilizados para estender a rea de ao de uma rede, reforando e regenerando os sinais fsicos.
So dispositivos bidirecionais, sem inteligncia, e introduzem um atraso na propagao.
Hubs e Switches: so dispositivos que provem uma conexo central para as estaes de trabalho, servidores e peri-
fricos. Atuam como guardas de trfego de dados, evitando colises e congestionamentos. Estes dispositivos per-
mitem que a rede cresa em nmero de equipamentos, at um limite aceitvel de colises, que depende do tipo de
cabeamento e topologia da rede. Eles se encarregam de distribuir os sinais eltricos entre os vrios equipamentos que
compem a rede, isolando os problemas de cada uma das estaes e garantindo mais segurana e confiabilidade.
o (FIS) Hubs ou Concentradores, trabalham com arquitetura de meio fsico compartilhado. Hubs so multi-
plexadores inteligentes, possuem processador e um buffer onde armazenam os dados oriundos dos terminais
23
para envio posterior ao servidor (aonde enviada a identificao do terminal), o que altera a velocidade de
transmisso de dados. Os concentradores incluem um software de controle, com isso um grande nmero de
linhas de baixa velocidade podem compartilhar um pequeno nmero de linhas de alta velocidade.
o (ENL) Switches ou Comutadores, diferentemente dos hubs (barramento compartilhado), oferecem uma "li-
nha comutada dedicada" a cada uma das suas conexes. Um hub que dispe 10 Mbps, compartilha esta ve-
locidade com todas as conexes, j o switch permitiria que cada conexo se comunicasse a velocidade total
da LAN. Com isso os switches permitem comunicaes paralelas, onde duas estaes podem enviar seus
dados em um mesmo intervalo de tempo sem riscos de colises. Com isso evita retransmisso e aumenta o
rendimento da rede. O protocolo SNMP usado pelo switch como uma das tarefas de gerenciamento.
(ENL) Bridges: equipamentos que tm como finalidade segmentar uma rede local em vrias sub-redes, e com isto
conseguem diminuir o fluxo de dados. Os Bridges tambm podem converter padres, como por exemplo de Ethernet
para Token-Ring. Eles manipulam pacotes, no retransmitindo rudos, erros, e pacotes mal formados. Fazem parte
do nvel de ligao lgico (MAC). So suas funes:
o ler o endereo do pacote e retransmit-lo;
o filtrar as mensagens, de modo que pacotes com erros no seja retransmitidos;
o armazenam os pacotes quando o trfego for muito grande;
o memorizar os endereos lgicos dos dispositivos, e gerar lista dos dispositivos ligados a cada porta;
o deve-se evitar loops ativos (envio de um pacote a dois bridges, que retransmitem vrios frames repetidos).
(RED) Roteador: existem duas atividades que so bsicas a um roteador. So elas: a determinao das melhores ro-
tas e o transporte dos pacotes. Determinar a melhor rota definir por qual enlace uma determinada mensagem deve
ser enviada para chegar ao seu destino de forma segura e eficiente. Para realizar esta funo, o roteador utiliza dois
conceitos muito importantes: o conceito de mtrica e o conceito de tabelas de roteadores. Transportar os pacotes pela
rede uma funo relativamente simples realizada pelos roteadores. Consiste em verificar o endereo de rede para
quem a mensagem est destinada, determinar se conhece este endereo. E, por fim, traduzir para um novo endereo
fsico e enviar pacote.
(TRA) Gateways: so equipamentos utilizados para se fazer a comunicao entre duas redes com arquiteturas dife-
rentes. Na comunicao entre arquiteturas diferentes surgem diversos problemas, como por exemplo:
o tamanho mximo de pacotes;
o forma de endereamento;
o tcnicas de roteamento;
o controle de acesso;

Sistemas Distribudos
Um sistema distribudo formado por um conjunto de mdulos processadores interligados por um sistema de comunicao
(rede de computadores). Enquanto uma rede construda para o compartilhamento de recursos, um sistema distribudo possui
como principais metas a obteno de um maior desempenho e confiabilidade.
Normalmente cada rede interligada em um sistema distribudo (intranets) protegida por um firewall, pois o sistema como
um todo pode ter a sua segurana comprometida, j que aumenta o nmero de entradas (e brechas) da rede, principalmente se
existir um acesso Internet.

Segurana
A segurana no universo computacional se divide em segurana lgica e segurana fsica, presente tanto em computadores
standalones (PCs individuais) como em computadores ligados em rede (Internet ou intranets).
A segurana fsica deve atentar para ameaas sempre presentes, como incndios, desabamentos, relmpagos, alagamentos,
problemas na rede eltrica, acesso indevido de pessoas ao CPD, treinamento inadequado de funcionrios, etc. Medidas de
proteo fsica, tais como servios de guarda, uso de no-breaks, alarmes e fechaduras, circuito interno de televiso e sistemas
de escuta so realmente uma parte da segurana de dados. As medidas de proteo fsica so freqentemente citadas como
segurana computacional. O ponto-chave que as tcnicas de proteo de dados no tm serventia nenhuma se a segurana
fsica no for garantida.
24
A segurana lgica requer um estudo maior, pois envolve investimento em softwares de segurana ou elaborao dos mes-
mos. Deve-se estar atento aos problemas causados por vrus, acesso de invasores de rede, programas de backup desatualiza-
dos (ou feito de maneira inadequada), distribuio de senhas de acesso, etc.. Um recurso muito utilizado para se proteger dos
bisbilhoteiros da Internet (administrador de sistemas), a utilizao de um programa de criptografia que embaralha o conte-
do da mensagem, de modo que ela se torna incompreensvel para quem no seja nem o receptor ou provedor da mesma.

Arquitetura OSI da ISO
O modelo OSI foi criado seguindo a filosofia das arquiteturas multicamadas, com os seguintes princpios:
Cada camada corresponde a um nvel de abstrao necessrio no modelo;
Cada camada possui suas funes prprias e bem definidas;
As funes de cada camada foram escolhidas pela definio dos protocolos internacionais;
As fronteiras entre as camadas foram definidas de modo a minimizar o fluxo de dados nas interfaces;
O nmero de camadas deve ser suficientemente grande para que funes distintas no sejam colocadas na mesma
camada, e suficientemente pequeno para que no seja difcil o controle da arquitetura.
Alm disso, o modelo foi projetado para redes geograficamente distribudas (WAN).

Camada Fsica
responsvel pela transferncia de bits num circuito de comunicao. A sua funo garantir que cada bit enviado de um
lado ser recebido do outro lado sem ter alterado o seu valor. Neste nvel resolvem-se:
os modos de representao dos bits 0 e 1 de maneira a evitar ambigidades ou confuses (valor da tenso em volts,
durao de cada sinal representando um bit, a codificao dos sinais, etc.)
os tipos de conectores utilizados nas ligaes (nmero de pinos, funes associadas a cada pino, etc.)
como as conexes se estabelecem para a iniciao de um dilogo e como feita a desconexo ao fim
modo de transmisso adotado (unidirecional, bidirecional)
modo de conexo adotado (ponto-a-ponto, multiponto)
modo de tratamento dos erros (deteco, tratamento, etc).
Em resumo, esta camada relaciona-se s interfaces eltricas e mecnicas, preocupando-se com o transporte de dados (repre-
sentados por bits) entre dois equipamentos terminais, via um suporte de transmisso. Alguns protocolos padres so: IEEE
25
802, ISO 2110, etc. O Ethernet um dos padres mais populares para a conexo fsica de uma LAN. Utiliza um procedimen-
to de compartilhamento de cabos denominado de CSMA/CD e trata das colises de dados que podem ocorrer quando diferen-
tes ns da rede tentam enviar dados simultaneamente. chamada de topologia baseada em competio, pois as estaes de
trabalho competem pela banda passante do canal, representa um meio econmico de obter transmisso de alta velocidade (10
ou 100 Mbps), e surporta diversas configuraes de cabeamento, sendo fcil de instalar.
Repetidores, multiplexadores e Hubs utilizam esta camada.

Camada de Enlace de Dados
Tem por funo principal a transformao do meio de comunicao "bruto" em uma linha livre de erros de transmisso para a
camada de Rede. Ela efetua esta funo atravs do fracionamento das mensagens recebidas do emissor em unidades de dados
denominadas quadros, que correspondem a algumas centenas de bytes. Estes quadros so transmitidos seqencialmente e vo
gerar quadros de reconhecimento enviados pelo receptor. Nesta camada, as unidades de dados so enriquecidas com um con-
junto de bits adicional (no incio e fim de cada quadro) de modo a permitir o reconhecimento destes.
Uma outra funo desta camada evitar uma alta taxa de envio de dados da parte do emissor no caso do sistema emissor no
ter capacidade de absorver a informao mesma taxa. Ela est dividida convencionalmente em duas subcamadas:
Controle de Acesso Mdia (Media Access Control - MAC): controla os meios pelos quais vrios dispositivos
compartilham o mesmo canal de transmisso.
Controle de Link Lgico (Logical Link Control - LLC): estabelece e mantm links (enlaces) entre dispositivos
em comunicao.
Com o objetivo de permitir um controle de erro eficiente, a camada de enlace decompe as mensagens em pores menores
denominadas quadros (frames), onde so adicionados cdigos especiais de controle de erro. O controle de erros de transmis-
so uma das funes mais importantes asseguradas pela camada de enlace. As responsabilidades desta camada so:
a forma como os bits provenientes da camada Fsica sero agrupados em quadros (frames)
os mecanismos de deteco e correo de erros implantados, uma vez que as informaes trocadas atravs da cama-
da fsica no so isentas de erros de transmisso, pelos fatores que j foram levantados
mecanismos de controle de fluxo para limitar o volume de informao trocados entre fonte e destino
a gesto das ligaes entre as entidades de Rede
mapeamento do endereamento MAC, gravado na ROM do adaptador de rede (48 bits)
Alguns dos componentes desta camada so o Bridge, Switch, o ISDN Router, etc.

Camada de Rede
A camada de rede responsvel da gesto de sub-redes. A principal funo da camada de rede efetuar o encaminhamento
dos pacotes trocados entre duas entidades oferecendo uma comunicao fim-a-fim.
Os caminhos a serem utilizados podem ser definidos em funo de tabelas estticas ou determinados dinamicamente no mo-
mento de cada dilogo em funo das condies de trfego, devendo ainda efetuar a gesto dos problemas de congestiona-
mento pela presena de uma quantidade excessiva de pacotes de dados na rede.
A camada de rede a camada mais baixa que trata a transmisso fim-a-fim. As duas funes essenciais da camada de rede
so roteamento e controle de congestionamento. Alm dessas, tambm responsvel por:
multiplexao, endereamento e seqenciao
mapeamento entre endereos de rede e endereos de enlace
estabelecimento e liberao de conexes do servio de rede
transmisso de unidades de dados do servio de rede (pacotes)
segmentao e blocagem de SDUs/PDUs
deteco e recuperao de erros
Os servios da camada de rede foram projetados para serem independentes da tecnologia de sub-rede. Alguns de seus compo-
nentes so o Roteador, o ATM Switch, Switch nvel 3, entre outros.
26

Camada de Transporte
Esta camada cria normalmente uma conexo de rede para cada conexo de transporte requerida pela camada de sesso, e de-
termina tambm o tipo de servio oferecida esta. Ela implementa um verdadeiro dilogo fim-a-fim, ou seja, o programa
executando no sistema fonte dialoga com o programa executando na mquina destino atravs dos cabealhos e informaes
de controle contidas nas mensagens deste nvel.
Dado que esta camada responsvel do estabelecimento e trmino das conexes de rede, ela deve definir um mecanismo de
endereamento que permita a um sistema indicar com qual sistema ele deseja dialogar. Finalmente, ela deve implementar um
mecanismo de controle de fluxo fim-a-fim para evitar que o sistema fonte envie mensagens numa taxa superior quela com a
qual o sistema destino pode consumi-las.
De maneira similar camada de Rede, a de Transporte pode fornecer dois tipos de servio: sem conexo e orientados cone-
xo. Ela tambm permite um "isolamento" em relao s camadas superiores, pois o ltimo dos nveis que seriam mais ori-
entados a transporte efetivo das informaes (e no aplicaes).
A camada de transporte supre as deficincias entre a qualidade de servio (QOS) que a camada de sesso necessita e aquilo
que a camada de rede pode oferecer. Alguns parmetros so: o retardo (e probabilidade de falha) no estabelecimento de uma
conexo, o desempenho (thoughput), retardo de trnsito, taxa de erros residuais, proteo, prioridade e resilincia (probabili-
dade de finalizar uma conexo espontaneamente).
Um componente usado a partir desta camada o Gateway, e os protocolos usados so: TCP, ARP, RARP, etc.

Camada de Sesso
A principal funo desta camada oferecer aos seus usurios meios para o estabelecimento das conexes (sesses), de modo
que estes possam trocar dados. Uma sesso utilizada para permitir a conexo distncia a um computador (atravs de ter-
minais, para uma transferncia de arquivo, para o carregamento de programas, etc).
A camada de sesso responsvel dos estabelecimentos de sesses de dilogo para os usurios da rede. Alm disso define a
gesto do dilogo (se deve ser efetuado em modo uni ou bidirecional).
importante notar aqui que a camada de Sesso oferece unicamente as ferramentas para a soluo dos problemas de erros e
incoerncia por sincronizao / resincronizao. Na realidade, quem ativa estas ferramentas quando da ocorrncia de um pro-
blema so as entidades das camadas superiores.

Camada de Apresentao
A Camada de Apresentao utiliza algumas funes freqentemente necessrias de modo a poupar o usurio deste trabalho.
Esta camada assume particularmente as funes associadas sintaxe e semntica dos dados transmitidos. Um exemplo tpi-
co das funes efetuadas por esta camada a codificao da informao num padro bem definido (ASCII, EBCDIC, etc.).
Esta camada pode ainda suprir outras funes associadas compreenso dos dados, se utilizando do conhecimento do signifi-
cado da informao para reduzir a quantidade de informao enviada, inclusive para implementar funes de confidencialida-
de e de autenticao.

Camada de Aplicao
A camada de Aplicao tem por funo o gerenciamento dos programas de usurio (programas de aplicao) que executam
em mquinas conectadas e utilizam o sistema de comunicao para a troca de informaes.
Esta camada implementa um conjunto de protocolos diversificado e orientado a aplicaes bem definidas. Exemplos so o
protocolo de terminal virtual e de transferncia de arquivo. Ela mantm o contato direto com os usurios da arquitetura de
comunicao, abrindo caminho para os servios oferecidos pelas camadas inferiores.

TCP/IP
Nos anos 70, o DoD (US Department of Defense), diante de um inventrio de diferentes computadores que no podiam inte-
ragir, foi o pioneiro no desenvolvimento de protocolos de software para redes, que poderiam funcionar em mais de uma mar-
27
ca e modelo de computador. O principal conjunto estabelecido pelo DoD o Transmission Control Protocol/Internet Proto-
col (TCP/IP). Estes protocolos so acordos sobre como devem ocorrer as transmisses nas redes.
A arquitetura Internet tambm organizada em camadas, e composta por dois protocolos principais, o TCP (transporte fim-a-
fim confivel) e o IP (encaminhamento de pacotes de dados atravs de vrias sub-redes.
O conjunto TCP/IP pode oferecer um servio relativamente confivel. Ao utilizar o protocolo TCP/IP, caso um datagrama
TCP enviado por um Host (Computador) seja danificado em um segmento entre dois roteadores, antes de chegar ao Host des-
tinatrio, o computador remetente reenvia o datagrama porque no recebe uma confirmao de recebimento pelo destinatrio.
O sucesso e a popularidade do protocolo no se deve apenas imposio das agncias militares americanas, mas tambm ao
fato der ter sido o primeiro protocolo a atingir a importante meta da comunicao de dados com abrangncia mundial:
TCP/IP um protocolo aberto, pblico e independente de equipamentos e de sistemas operacionais;
TCP/IP no define protocolos para o nvel fsico, possibilitando sua implementao sobre uma grande variedade de
protocolos j existentes, tais como: Ethernet, Token Ring e X.25;
O esquema de endereamento do TCP/IP permite designar univocamente qualquer mquina, mesmo em redes glo-
bais como a Internet;
TCP/IP inclui protocolos do nvel de aplicao que atendem demanda de servios imposta.

Camadas do TCP/IP
No existe uma correspondncia de camadas entre o modelo OSI e o TCP/IP que seja aceita universalmente, pois o TCP/IP
foi criado com o compromisso da funcionalidade, e o OSI foi projetado academicamente.
Da mesma forma que no modelo
de referncia OSI, os dados des-
cem a pilha de protocolos para
chegar a rede e sobem para chegar
s aplicaes. Cada camada da
pilha de protocolos adiciona um
cabealho com informaes de
controle e trata o que recebe da
camada superior como sendo da-
dos.

Camada de Acesso Rede
(ou Camada de Interface)
a mais baixa da hierarquia de
protocolos TCP/IP. Os seus protocolos provem meios para que os dados sejam transmitidos a outros computadores na mes-
ma rede fsica. Esta camada pode abranger as trs primeiras camadas do modelo de referncia OSI: fsica, de enlace e de rede.
Entretanto, a camada de acesso rede do TCP/IP no define propriamente os protocolos para estes trs nveis, mas sim como
utilizar os protocolos j existentes para suportar a transmisso de um datagrama IP. Outros protocolos existem nessa camada,
como o IPX (da Novell), que faz parte do protocolo IPX/SPX. As principais funes da camada de acesso rede so: o en-
capsulamento de datagramas IP em frames para transmisso e a traduo de endereos IP em endereos fsicos de rede. Estas
duas funes apresentam implementaes especficas para cada tipo de rede.

Camada Internet (ou Camada de Inter-Rede)
Fica exatamente sobre a camada de acesso rede. O Internet Protocol (IP), o corao desta camada. Ele prov um servio
bsico de datagrama sobre o qual as redes TCP/IP so implementadas. Todos os protocolos das camadas superiores a esta
fazem uso do protocolo IP.
Outros protocolos da Camada Internet so o ICMP (Internet Message Control Protocol) para a obteno de informaes so-
bre a rede, e o ARP (Address Resolution Protocol) para resoluo de endereos IP.


28
Camada de Transporte
Esta camada fim-a-fim est localizada exatamente sobre a camada Internet na hierarquia TCP/IP. Os principais protocolos
desta camada so: TCP (Transmission Control Protocol), o UDP (User Datagram Protocol)
O TCP um protocolo orientado a conexo com deteco e correo de erros fim-a-fim. O UDP um protocolo no orienta-
do a conexo e no confivel, sendo portanto muito leve. Ambos os protocolos passam dados entre as camadas de aplicao e
Internet. Cada aplicao deve escolher o que melhor se adapta a sua natureza.

Camada de Aplicao
Fica no topo da pilha TCP/IP, incluindo todos os processos que utilizam servios das camadas inferiores para transmitir dados
atravs da rede. Alguns de seus protocolos so: Telnet, FTP, SMTP, DNS, NFS, etc.


Protocolo IP
O IP um protocolo no orientado a conexo, ou seja, no existe negociao prvia de uma conexo para a transmisso de
dados. Isto no impede a existncia de protocolos orientados conexo nas camadas superiores, mas eles devero negociar o
estabelecimento de conexes por si prprios. Alm de ser no orientado conexo, o protocolo IP tambm no confivel,
uma vez que no suporta mecanismos de deteco e recuperao de erros. Em outras palavras, o protocolo IP no verifica se
um datagrama foi recebido corretamente, deixando esta responsabilidade para os protocolos das camadas superiores.
As principais funes do protocolo IP so:
definir o datagrama IP, que a unidade bsica de transmisso de dados da arquitetura TCP/IP;
definir o esquema de endereamento IP;
passar dados da camada de acesso rede camada de transporte;
rotear datagramas IP;
fragmentar e remontar datagramas IP

Protocolo TCP
O protocolo TCP trabalha no mesmo nvel que o protocolo UDP, mas oferece servios mais complexos, que incluem controle
de erros e de fluxo, servio com conexo e envio de fluxo de dados. O TCP utiliza o mesmo conceito de porta do UDP. Para o
TCP, uma conexo formada pelo par (Endereo IP de Origem, Porta de Origem) e (Endereo IP de Destino, Porta de Desti-
no).
O protocolo TCP oferece as seguintes caractersticas:
Controle de Fluxo e Erro fim-a-fim (a comunicao full-duplex fim-a-fim).
29
Servio confivel de transferncia de dados.
A aplicao necessita apenas enviar um fluxo de bytes.
Desassociao entre quantidade de dados enviados pela aplicao e pela camada TCP.
Ordenao de mensagens.
Multiplexao de IP, atravs de vrias portas.
Opo de envio de dados urgentes.

Formato do Pacote IP
Verso: Atualmente IPV4. A IPV6 cogitada.
IP Header Length: tamanho do cabealho
Type-of-Service: Nvel de importncia, etc.
Total Length: tamanho do pacote IP inteiro.
Identification: Nmero, para seqncias.
Flags: Controla fragmentao (3 bits).
Fragment Offset: Posio relativa do dado fragmentado do
datagrama original.
Time-to-Live: Evita loops infinitos ao rotear um pacote ( um
contador que decrementado).
Protocol: Indica o protocolo (sup) a ser usado.
Header Checksum: Integridade do cabealho.
Source Address: indica o n remetente.
Destination Address: indica o n destinatrio
Options: Permite que o IP suporte vrios opes, como segurana.
Data: Contm as informaes para a camada superior, que ser utilizada pelo protocolo especificado.

Classes de Endereos IP
O endereo IP est dividido em 5 classes diferentes, identificadas pelos 4 primeiros bits:
Classe A primeiro octeto inicia com 0xxx, ou 1 ate 126 decimal.
Classe B primeiro octeto inicia com 10xx, ou 128 ate 191 decimal.
Classe C primeiro octeto inicia com 110x, ou 192 ate 223 decimal.
Classe D primeiro octeto inicia com 1110, ou 224 ate 239 decimal. (Classe para Multicast)
Classe E primeiro octeto inicia com 1111, ou 240 ate 254 decimal. (Classe para Research)
O formato da mscara do endereo IP nas trs primeiras classes (N para Network e h para Hosts):
Classe A (Redes grandes) -- NNNNNNNN.hhhhhhhh.hhhhhhhh.hhhhhhhh
Classe B (Redes mdias) -- NNNNNNNN.NNNNNNNN.hhhhhhhh.hhhhhhhh
Classe C (Redes locais) -- NNNNNNNN.NNNNNNNN.NNNNNNNN.hhhhhhhh
Existem alguns endereos especiais, como o Loopback (127.0.0.1), e outros reservados das classes, como o 10.0.0.0/8 da
Classe A (de 10.0.0.0 a 10.255.255.255) e o 192.168.0.0/16 da Classe C (at 192.168.255.255), no roteados para Internet.
Classe A: como exemplo, o endereo 126.1.12.2 pertence classe A. So possveis 126 redes (o primeiro nmero
vai de 1 a 126), e 16.777.214 hosts para a rede (os trs ltimos nmeros, 256 * 256 * 256 2).

30
Classe B: como exemplo, o endereo 128.126.12.34 pertence classe B. So possveis 16.384 redes (os dois primei-
ros nmeros, de 128 a 191), e 65.534 hosts (para os dois ltimos nmeros, 256*256 2).
Classe C: como exemplo, o endereo 192.168.0.34 pertence classe C. Permite a existncia de cerca de 2.097.152
redes (trs primeiros nmeros, variando de 192 at 233) e 254 hosts por rede (256 2).
Segue um exemplo de uma rede local utilizando um endereo IP privado Classe C para acessar a Internet:

Algoritmo de Transmisso de pacotes IP
1. Datagrama pronto para ser transmitido
2. Caso:
Endereo Destino == Endereo Transmissor
Entrega datagrama pela interface loopback (127.0.0.1)
Fim
Endereo de rede do destino == endereo de rede local
Descobre o endereo fsico do destino (ARP)
Transmite datagrama pela interface correta
Fim
Endereo de rede do destino != endereo de rede local
Verifica tabela de rotas
Descobre rota que se encaixa com a rede destino
Descobre o endereo fsico do gateway (ARP)
Transmite o datagrama para o gateway
Fim
3. Fim

Algoritmo de Recepo de pacotes IP
1. Datagrama recebido da camada intra-rede, defragmentado e testado
2. Caso:
End. Destino = End. do Host / outras interfaces do Host / Broadcast
31
Passa datagrama para nveis superiores -> FIM
Caso:
Mquina que recebeu no roteador
Descarta datagrama -> FIM
Mquina roteador (possui mais de uma interface IP)
Caso:
Endereo IP destino = Rede IPcom interface direta
Descobre o endereo fsico do destino (ARP)
Transmite datagrama pela interface respect. -> FIM
Caso Endereo de rede do destino endereo de rede local
Verifica tabela de rotas
Descobre o endereo fsico do gateway (ARP)
Transmite o datagrama para o gateway -> FIM
3. Fim


Windows (2003/XP/2000/98)
A Microsoft (empresa fundada por Bill Gates e Paul Allen) criou e mantm o Windows, um sistema operacional comercial
muito popular, que possui este nome por ter a sua interface baseada em janelas (windows).
As verses iniciais do Windows (at a verso 3.11 inclusive) rodavam em cima do DOS, um sistema operacional de 16 bits.
As verses posteriores (Windows 95, 98, NT, etc.) suportam 32 bits, enquanto verses mais avanadas, como o Windows XP
e o Windows Vista, esto preparadas para 64 bits.

Bibliotecas de ligaes dinmicas
O Windows possui arquivos que contm uma biblioteca de funes e procedimentos designados para serem chamados por
outros programas rodando no sistema operacional. Estes arquivos, com a extenso dll (dynamic linked libraries), quando
compilados, utilizam um mecanismo conhecido como ligao dinmica. A ligao dinmica permite que os procedimentos
includos no arquivo sejam disponibilizados para outras aplicaes.
Ao compilar um programa (por exemplo, em Delphi ou Visual Basic) que acessa um destes procedimentos, a aplicao varre
o cdigo fonte, lista todas as referncias aos procedimentos que no so parte de sua prpria biblioteca de procedimentos, e
encontra as DLLs que os possuem.
Quando o programa for executado, o Windows carregar o arquivo de biblioteca de ligaes dinmicas que contm o proce-
dimento referenciado. Todos os procedimentos pblicos no arquivo DLL tornam-se acessveis e os endereos de memria so
especificados e dinamicamente ligados ao executvel.
A tcnica de ligao dinmica possui vantagens sobre a ligao esttica (onde todo o cdigo fonte dos procedimentos incor-
porado ao executvel). Uma das vantagens a economia de memria, pois a DLL carregada apenas uma vez, mesmo que
vrios programas faam uso de seus procedimentos. Outra vantagem a economia em espao em disco, pelo mesmo motivo.
Porm, estas vantagens podem se tornar um problema, se as DLLs possurem muitos procedimentos no utilizados, pois estes
seriam carregados em memria e ocupariam espao em disco inutilmente.
Outra vantagem que melhorias ou correes s bibliotecas de procedimentos podem ser feitas naturalmente, e os programas
que utilizam os seus procedimentos no precisam ser recompilados.
Como desvantagem, pode ocorrer de um programa utilizar uma DLL desatualizada ou mesmo referenciar uma DLL inexis-
tente no sistema (todas as bibliotecas devem ser copiadas junto com o executvel).

32
Arquitetura Distribuda
Principais conceitos e componentes

Modelo Cliente Servidor
O modelo cliente / servidor foi criado tendo como base a descentralizao dos dados e recursos de processamento, em oposi-
o ao modelo centralizado (mainframe). Neste modelo existem uma ou mais mquinas que atuam como servidores (Servidor
de Arquivos, Banco de Dados, Servidor de Impresso), e fornecem os servios para outras mquinas clientes, atravs de uma
rede de computadores.
Vantagens: Podem ser utilizados equipamentos baratos, h uma diviso mais eficiente do trabalho, diminuio do
trfego da rede, maior versatilidade de sistemas operacionais e plataformas, maior segurana e integridade (forneci-
do por um gerenciador de banco de dados central), entre outras.
Desvantagens: Aumento do custo administrativo de suporte rede e banco de dados, maior dificuldade em encon-
trar pontos problemticos do sistema, custo maior no hardware / software do servidor.

2 camadas
No modelo de 2 camadas toda a lgica do negcio fica no cliente. Em cada mquina cliente deve ser instalado o programa
(desenvolvido em VB, Delphi, etc), que possui todas as regras de acesso a um banco de dados, por exemplo. Naturalmente, a
camada de apresentao tambm fica no cliente..
A desvantagem do modelo de 2 camadas a dificuldade de manuteno, pois as regras de negcio esto sempre mudando
(evoluo do mercado, alteraes na legislao), exigindo alterao em todos os clientes.

3 camadas
O modelo em 3 camadas veio solucionar o problema das 2 camadas, retirando as regras de negcio do cliente e centralizando-
as em um determinado ponto, chamado Servidor de Aplicaes. O acesso ao banco de dados feito atravs das regras conti-
das no Servidor de Aplicao.
Apresentao: Esta camada fica no cliente, fornecendo a interface visual da aplicao. Alteraes ela so mais ra-
ras, mas exigem a atualizao de todos os clientes.
Lgica: So as regras de negcio, centralizadas em um Servidor de Aplicaes, fceis de manter.
Dados: Os dados permanecem em um servidor de Banco de Dados.

N camadas
Outra evoluo aos modelos Cliente / Servidor anteriores o modelo de 4 camadas, que centraliza a camada de apresentao
em nico ponto, normalmente um servidor Web. Assim existe uma camada adicional chamada Cliente, que representa o na-
vegador (browser) utilizado pelos clientes em suas estaes.
A camada de apresentao passa a ser um servidor Web composta de pginas HTML, ASP, JSP ou outras.
So evidentes as vantagens ao dimensionar um sistema em 3 ou mais camadas. Mas preciso levar em conta os custos com
os equipamentos, desempenho, etc. Se os servidores ficarem responsveis por grande parte do processamento e uso de mem-
ria, os seus custos aumentam, e por isso o nmero de usurios, recursos do software, nvel de exigncia de cada usurio, e
outros fatores devem ser considerados.

Chamadas remotas
O mecanismo de chamadas remotas RPC (Remote Procedure Call) integra o protocolo usado para comunicao Cliente /
Servidor com as linguagens de programao convencionais, permitindo clientes comunicar com servidores atravs de chama-
das de procedimentos.
33

A chamada remota segue o modelo da chamada local, sendo que o procedimento chamado executado em um processo dife-
rente, normalmente em um computador diferente. Os passos so:
Cliente chama stub cliente
Stub cliente constri mensagem, e chama SO
SO cliente envia mensagem para SO remoto
SO remoto entrega mensagem p/ stub servidor
Servidor realiza trabalho, retorna para stub
SO servidor envia mensagem para SO cliente
SO cliente entrega mensagem para stub cliente
Stub cliente retorna resultado para o cliente

Sincronismo e filas de mensagens


Conceitos de Internet
Domain Name Service/System (DNS)
O DNS faz a converso do nome do Domnio para o numero de IP e vise-versa.
Quando usamos a Internet estamos acostumados a lembrar dos nomes dos domnios ao contrario dos nmeros dos IPs. Alias a
grande maioria dos usurios nem mesmo sabem que um nome do domnio esta amarrado a pelo menos um numero de IP. Para
facilitar a nossa vida o DNS faz o papel intermediador convertendo do nome do Domain para o numero do IP.
Exemplo: www.google.com aps convertido fica assim - numero IP: 216.239.35.100
Quando o endereo acima digitado no navegador, uma mensagem enviada ao DNS server solicitando a localidade do Do-
main. Se o mesmo existir, o DNS server retornar uma outra mensagem com o exato numero do IP para que o navegador
consiga acessar o domnio desejado.
Os 13 DNS Root Servers so identificados pelas letras A-M, e a maioria est localizada nos Estados Unidos.

Default Gateway
Default Gateway aquele que serve como intermediador entre redes, sempre presentes em redes locais com acesso a Internet.
Quando estamos em uma rede local e queremos acessar um servidor local s necessrio descobrir o IP do servidor em envi-
ar o pacote para o mesmo. J quando queremos acessar a Internet j muda um pouco a figura. Neste caso no sabemos o IP do
servidor que queremos acessar, ento temos que fazer um pedido para o DNS como j estudamos anteriormente. O Default
34
Gateway entra em cena aqui, porque quando se emite um pacote IP que no pertence a rede local algum tem que tomar pro-
videncia e encaminh-lo para a devida rede que ele pertence. O seu papel fazer a transio de uma lado para outro, no nosso
caso ele manda o pacote que foi gerado pela rede interna para a rede externa Internet.
Default Gateway pode ser um roteador, um firewall, um computador etc., tudo isso vai depender do ponto de vista do layout
de rede, certamente em muitos dos casos o roteador e o firewall sero Default Gateway em uma determinada rede. O roteador
sendo Default Gateway da rede externa (ISP) e o firewall sendo Default Gateway da rede interna (rede local).
Exemplo: O usurio na Maquina de IP 192.168.0.24 est acessando o google.com na Internet, e para isso ele teve
que percorrer vrios Default Gateway. O desenho tenta ilustrar o bsico do que acontece quando se tenta acessar um
endereo que esteja fora da rede local. Para que o acesso seja completado, o computador do cliente, firewall e o rote-
ador devem estar com seus respectivos Default Gateway configurados. O desenho no est ilustrando o acesso ao
DNS para adquirir o IP do google.com e nem como obtido os endereos de IP internos do Gateway - ARP request.



Backbone
Backbones so 'portas' de acesso Internet. No Brasil, poucas empresas so realmente proprietrias de backbones de Internet,
como o caso da EMBRATEL, da TELEFNICA e da IMPSAT. Estas empresas vendem a conexo com os backbones para
os provedores de acesso Internet. Estes provedores ento, vendem o acesso discado via linha telefnica aos usurios finais.
O backbone ("espinha dorsal") o trecho de maior capacidade dessa rede, com uma infra-estrutura de alta velocidade e que
proporciona a conexo com vrias redes menores. Localmente, o backbone uma linha ou conjunto de linhas qual as
redes se conectam para formar uma WAN. Na Internet ou em outras WANs, o backbone um conjunto de linhas com as
quais as redes locais ou regionais se comunicam para interligaes de longa distncia.
Cada pas tem uma rede principal para transmitir pacotes da Internet. Geralmente um pas tem poucos backbones ou at mes-
mo um s. Um deles, pelo menos, mantido pelo Estado. Mas existem tambm backbones em empresas particulares. O pri-
meiro backbone da Internet criado no Brasil foi a RNP (Rede Nacional de Pesquisa), comeou atendendo entidades, faculda-
des ou universidades que queriam se conectar rede.

Intranet
As empresas descobriram que podem criar redes como a Internet, porm privadas, as Intranets, que cumprem o papel de co-
nectar entre si filiais, departamentos, fornecedores, clientes, etc, mesclando (com segurana) as suas redes particulares de
informao com a estrutura de comunicaes da Internet.
Basicamente a montagem de uma intranet consiste em usar as estruturas de redes locais existentes na maioria das empresas, e
em instalar um servidor Web. O servidor a mquina que faz o papel de repositrio das informaes contidas na intranet,
onde so buscadas as pginas HTML, e-mails ou outros tipos de arquivos.
35
A Intranet simplifica a interao do usurio, tornando fcil o acesso a aplicaes e a informaes estticas e dinmicas, no
importando onde esteja ou qual a plataforma utilizada. Tambm viabiliza uma publicao em tempo real, com informao
muito mais atual, favorecendo o desempenho dos funcionrios da empresa. E finalmente, auxilia no processo de descentrali-
zao das informaes, da distribuio de dados e do desenvolvimento de aplicaes, alm de permitir maior participao do
usurio final na criao de aplicaes.

Extranet
A rigor uma intranet pode operar apenas como uma rede corporativa dentro dos limites da empresa, porm pode ser vantajoso
a ligao da intranet com a internet, neste caso chamada de extranet. A Extranet a disponibilizao da Intranet (no todo ou
em parte) para ser acessada de fora da empresa.
O usurio domstico que acessa a intranet de uma empresa no percebe que est na intranet. A diferena percebida somente
em termos de velocidade pelos funcionrios, quando estes saem da intranet e acessam a internet do computador de sua seo.
Conectando a intranet Internet: Usa-se um roteador para encaminhar as informaes da internet para a rede cor-
porativa e vice-versa. Para obter esta ligao necessrio a contratao de um canal de dados junto a uma empresa.
Tambm preciso registrar um Domnio e obter um endereo IP.
Protegendo a Intranet: necessrio proteger a Web corporativa contra a invaso de intrusos. Isso feito por um
computador dedicado que serve de porteiro, que supervisiona o trnsito das informaes entre a intranet e a extranet
e vice-versa. Esse computador geralmente roda um firewall.
VPN (Virtual Private Network): uma rede corporativa implementada atravs de redes pblicas (Internet).

Firewall
Firewall pode ser definido como uma barreira de proteo, que controla o trfego de dados entre um computador e a Internet
(ou entre a rede onde o computador est instalado e a Internet). Seu objetivo permitir somente a transmisso e a recepo de
dados autorizados. Existem firewalls baseados na combinao de hardware e software e firewalls baseados somente em soft-
ware. Este ltimo o tipo recomendado ao uso domstico e tambm o mais comum.
H mais de uma forma de funcionamento de um firewall, que varia de acordo com o sistema, aplicao ou do desenvolvedor
do programa. No entanto, existem dois tipos bsicos de conceitos de firewalls:
Filtragem de pacotes: muito utilizado em redes pequenas ou de porte mdio. Por meio de um conjunto de regras
estabelecidas, esse tipo de firewall determina que endereos IPs e dados podem estabelecer comunicao e/ou
transmitir/receber dados. Alguns sistemas ou servios podem ser liberados completamente (por exemplo, o servio
de e-mail da rede), enquanto outros so bloqueados por padro, por terem riscos elevados (como softwares de men-
sagens instantneas, tal como o ICQ). O grande problema desse tipo de firewall, que as regras aplicadas podem ser
muito complexas e causar perda de desempenho da rede ou no serem eficazes o suficiente.
Filtragem de aplicao: (exemplos de aplicao: SMTP, FTP, HTTP, etc) so instalados geralmente em computa-
dores servidores e so conhecidos como proxy. Este tipo no permite comunicao direto entre a rede e a Internet.
Tudo deve passar pelo firewall, que atua como um intermediador. O proxy efetua a comunicao entre ambos os la-
dos por meio da avaliao do nmero da sesso TCP dos pacotes. Este tipo de firewall mais complexo, porm mui-
to seguro, pois todas as aplicaes precisam de um proxy. Permite um acompanhamento mais preciso do trfego.
A seguir so citadas as 3 principais razes para se usar um firewall:
O firewall ajuda a impedir que a rede ou computador seja acessado sem autorizao. Assim, possvel evitar que in-
formaes sejam capturadas ou que sistemas tenham seu funcionamento prejudicado pela ao de hackers;
O firewall um grande aliado no combate a vrus e cavalos-de-tria, uma vez que capaz de bloquear portas que
eventualmente sejam usadas pelas "pragas digitais" ou ento bloquear acesso a programas no autorizados;
Em redes corporativas, possvel evitar que os usurios acessem servios ou sistemas indevidos, alm de ter o con-
trole sobre as aes realizadas na rede, sendo possvel at mesmo descobrir quais usurios as efetuaram.


36
Banco de Dados

Conceitos
Bancos de dados (ou bases de dados) so conjuntos de dados com uma estrutura regular que organizam informao. Essas
estruturas costumam ter a forma de tabelas: cada tabela composta por linhas e colunas. Informaes utilizadas para um
mesmo fim so agrupadas num banco de dados.
Segundo [KORTH], um Banco de Dados pode ser definido como uma coleo de dados inter-relacionados, cujo contedo
informativo representa a qualquer instante, o estado de uma determinada aplicao.
Segundo [Navathe], um Banco de Dados uma coleo de dados interligados por uma semntica comum.

Administrao de Dados
Administrar dados significa envolvimento direto com o negcio. O Administrador de dados deve ser um profissional especia-
lista em tcnicas de modelagem de dados para sistemas OLTP (On-Line Transactional Processing) e sistemas OLAP (On-
Line Analytical Processing), mas tambm, em um caso timo, ser conhecedor das principais regras que regem o negcio da
empresa. Em outras palavras, uma mistura de Analista de Sistemas (especialista em modelagem) e Analista de Negcio. Al-
gumas de suas responsabilidades so:
Criao e manuteno de um modelo de dados corporativo
Auditoria dos modelos de dados para eliminao de falhas de modelagem
Padronizao e completude na dicionarizao dos dados
Modelagem em relao ao escopo do sistema
Integrao do modelo analisado com os demais modelos de dados da corporao.
Em parceria com um DBA, possvel identificar tambm:
Alteraes no modelo de dados segundo a tica de otimizao da utilizao de recursos do sistema gerenciador de
banco de dados (SGBD) utilizado no sistema
Conformidade com o Padro de Banco de Dados (padro para nomes de tabelas, atributos, etc.) adotado pela corpo-
rao, e otimizao do modelo de dados, objetivando aumento de performance

Sistemas Gerenciados de Bancos de Dados (SGBDs)
Em sistemas computacionais, bases de dados so geridas por um sistema gestor de bancos de dados, ou SGBD. A apresenta-
o dos dados pode ser semelhante de uma planilha eletrnica, porm os sistemas de gesto de BDs possuem caractersticas
especiais para o armazenamento, classificao e recuperao dos dados:
Manipulao de Dados: organizar o contedo dos dados inserindo, atualizando, deletando e recuperando dados;
Definio de Dados: estruturar os elementos de dados em esquemas lgicos e fsicos;
Restries de Integridade: garantir a segurana, integridade e concorrncia dos dados.
Administrar um banco , de maneira simplista, instalar, configurar, monitorar e solucionar problemas de um SGBD. Esmiu-
ando este conceito, um Administrador de Banco de Dados tem as seguintes responsabilidades:
Projeto lgico do banco de dados: criao do esquema lgico usando a DDL
Definio de checagem de segurana e integridade
Deciso de como os dados so representados na base de dados armazenada
Projeto fsico da base de dados
Definio de procedimentos de recuperao
Monitorao do desempenho
37
Contato com usurios para averiguao de disponibilidade dos dados por eles requisitados e ajuda na determinao e
resoluo de problemas
Ajustes apropriados medida que ocorram mudanas de requisitos
A administrao deve prever a utilizao do SGBD ao longo de vrios anos, garantindo a ausncia de problemas fsicos futu-
ros que impeam a disponibilidade dos dados.
Segundo [SILBERSCHATZ], o Sistema Gerenciador de Banco de Dados uma coleo de dados inter-relacionados e uma
coleo de programas para acesso a esses dados, proporcionando um ambiente conveniente e eficiente para armazenamento e
recuperao de informaes. A estrutura geral do SGBD dividida nos seguintes componentes funcionais:
Processador de consultas:
o Compilador e pr-compilador da Linguagem de Modelagem de Dados
o Interpretador da Linguagem de Definio de Dados
o Motor de Avaliao de consultas.
Gerenciador de armazenamento:
o Gerenciador de Integridade e Autorizao
o Gerenciador de Transaes
o Gerenciador de Arquivos
o Gerenciador de Buffer
Estruturas de Dados da Implementao do sistema fsico:
o Arquivos de Dados
o Dicionrios de Dados
o ndices
o Dados estatsticos

38
Linguagem de definio de dados e Linguagem de manipulao de dados
Os elementos da DML (Data Manipulation Language - Linguagem de Manipulao de Dados). A DML um subconjunto da
linguagem usada para selecionar, inserir, atualizar e apagar dados. No nvel fsico precisa-se definir algoritmos que permitam
um acesso eficiente aos dados. Nos nveis mais altos de abstrao, dada nfase facilidade de uso, fornecendo uma intera-
o humana eficiente com o sistema.
A DDL (Data Definition Language - Linguagem de Definio de Dados) permite ao usurio definir tabelas novas e elementos
associados. A maioria dos bancos de dados de SQL tem extenses proprietrias no DDL. O resultado da compilao de co-
mandos de uma DDL um conjunto de tabelas que so armazenadas em um arquivo chamado dicionrio de dados. Este di-
cionrio de dados contm "dados sobre dados", e consultado antes que os dados sejam lidos ou modificados no sistema de
banco de dados.

Dicionrio de dados
O Dicionrio de dados armazena os metadados relativos estrutura do banco de dados. Ele muito usado, e portanto grande
nfase dada ao desenvolvimento de um bom projeto com uma implementao eficiente do dicionrio.
Uma notao bastante utilizada para representar o dicionrio de dados sublinhar o atributo identificador (chave), e os tipos
de atributos podem ser T (texto), I (inteiro), S/N (valor lgico), D (data), entre outros.


Arquitetura de banco de dados
So trs os modelos abordados na arquitetura ANSI/X3/SPARC:
Modelo conceitual: definido pelo administrador de dados, e refere a uma viso lgica e global dos dados, ele deve
abordar todos os objetos do sistema de informao da empresa independente da aplicao.
Modelo externo: definido pelo administrador de aplicao. Visa um subconjunto do modelo conceitual para uma a-
plicao especfica da empresa, podendo existir vrias vises externas.
Modelo interno: definido pelo Administrador de Banco de Dados. Se preocupa com a implementao fsica dos da-
dos atravs de um banco de dados.
O Projeto Lgico do Banco de Dados engloba o Modelo conceitual e externo. O Projeto Fsico consiste do Nvel Interno.

Bancos de dados relacionais
Os bancos de dados relacionais so indiscutivelmente os mais utilizados atualmente. Alguns conceitos so:
Tabelas: so as relaes do banco, representadas como uma tabela de dados, composta por colunas.
Colunas: cada coluna na tabela possui um nome nico, e contm um tipo de dados associados. Tambm so deno-
minadas campos ou atributos da tabela.
Linhas: cada linha em uma tabela representa um registro diferente. Por causa do formato tabular, todas elas tm os
mesmos atributos. As linhas tambm so comumente chamadas de registros ou tuplas.
39
Valores: cada linha consiste em um conjunto de valores individuais que correspondem a colunas. Cada valor deve
ter o tipo de dados especificado pela sua coluna.
Chaves: so utilizadas para identificar um registro especfico, geralmente feito atravs de um valor inteiro nico.
Um nmero artificialmente gerado a melhor forma de garantir a unicidade da chave, pois poucas informaes reais
possuem essa propriedade.
Relacionamentos: as chaves estrangeiras representam um relacionamento entre dados em duas tabelas. Existem trs
tipos bsicos de relacionamentos em um banco de dados relacional:
o um para um: significa que h uma de cada coisa no relacionamento.
o um para muitos: uma linha em uma tabela vinculada a muitas linhas na outra tabela.
o muitos para muitos: muitas linhas em uma tabela so vinculadas a muitas linhas de outra tabela. Esse tipo
de relacionamento normalmente obtm uma tabela inteira para si prprio, logo uma terceira tabela que s
contm as chaves das outras tabelas como chaves estrangeiras em pares serve para mostrar quais registros
esto associados.
Metadados: um banco de dados autodescritvel, e contm uma descrio de sua prpria estrutura como parte inte-
grante do mesmo. Metadados so armazenados na forma de tabelas (tabelas do sistema).

Modelagem de Dados

Modelo Entidade-Relacionamento
O Modelo de Dados, tambm conhecido como E-R (Entidade-Relacionamento) uma forma de representao grfica do co-
nhecimento que se tem sobre o ambiente. Mostra uma viso esttica das informaes de interesse (entidades) e dos vnculos
(relacionamentos) entre elas. Serve para comunicar o analista de dados e o usurio. considerado um modelo semntico.

Entidade (Retngulo): algo real ou abstrato, sobre o qual nos interessa armazenar dados. Entidades fracas (que
dependem de outras) so representadas por um retngulo duplo.
Atributo (Elipse): um dos itens de dados que armazenamos sobre uma entidade. Atributos multivalorados so re-
presentados por elipses duplas.
40
Relacionamento (Linhas): Um relacionamento bi-direcional uma relao entre dois tipos de entidades, existindo
tambm o multi-direcional, auto-relacionamento, etc.
Chave de Identificao: Atributo (ou conjunto de) cujo valor individualiza uma ocorrncia da entidade. Por exem-
plo, para identificar a entidade EMPREGADO, o atributo-chave a MATRCULA.
Domnio: So os possveis valores que um atributo pode assumir. Ex.: SEXO = [ M | F ]
Ocorrncia: O nmero de vezes que determinado atributo aparece em outra entidade.
Existem entidade independentes (a chave est em seus atributos), dependente (chave depende de outra) e associativa (a chave
obtida atravs da concatenao das chaves de identificao das entidades que ela associa. Representaes para esses s outras
caractersticas do banco surgiram em um modelo estendido (Teorey).

Modelo Relacional
Um banco de dados relacional consiste em uma coleo de tabelas, cada uma das quais com um nome nico. Uma linha em
uma tabela representa um relacionamento entre um conjunto de valores. Uma vez que essa tabela uma coleo de tais rela-
cionamentos, h uma estreita correspondncia entre o conceito de tabela e o conceito matemtico de relao, a partir do qual
se origina o nome desse modelo de dados. Logo o Modelo Relacional est formalmente baseado na lgebra Relacional.
Seguindo a terminologia do modelo relacional, tratamos os nomes dessas colunas como atributos. Para cada atributo h um
conjunto de valores permitido, chamado domnio do atributo em questo. Como as tabelas em essncia so relaes, podemos
usar os termos matemticos relao e tupla no lugar de tabelas e linhas.
Trs objetivos bsicos motivaram fortemente as pesquisas que resultaram no modelo relacional:
Independncia dos dados: definio clara e precisa dos limites entre os aspectos fsicos e lgicos de um gerencia-
dor de banco de dados.
Comunicabilidade: permitir um modelo estrutural simples de forma que usurios de vrias categorias tivessem um
entendimento comum dos dados e pudessem se comunicar atravs do banco de dados.
Linguagem de alto nvel: existncia de uma linguagem que permitisse a manipulao de um conjunto de dados a-
travs de apenas um simples comando.
Atualmente esses objetivos j se encontram incorporados ao cotidiano do ambiente de desenvolvimento de sistemas. J passa
despercebido, por exemplo, o conceito de independncia dos dados, pois todos os bancos de dados possuem essa caractersti-
ca. Mas alm destas existem as 12 regras de Codd.

12 Regras de Codd
Um banco de dados, para que seja considerado "totalmente relacional", deve atender as 12 regras definidas por E. F. Codd, o
criador do modelo relacional para banco de dados.
As doze regras de Codd esto baseadas na regra zero, que determina o seguinte: "Qualquer sistema considerado, ou que dese-
ja ser, um sistema gerenciador de banco de dados relacionam deve ser capaz de gerenciar, por completo, bases de dados atra-
vs de sua capacidade relacional". Essa regra determina que um SGBDR no permite excees quanto ao modelo relacional
de gerenciamento de bases de dados. As 12 so as seguintes:
Regra 1 - Representao de valores em tabelas: Todas informaes do BD relacional so representadas de forma
explcita no nvel lgico e exatamente em apenas uma forma - por valores em tabelas.
Regra 2 Acesso Garantido: Cada um e qualquer valor atmico (datum) em um banco de dados relacionam possui
a garantia de ser logicamente acessado pela combinao do nome da tabela, do valor da chave primria e do nome da
coluna.
Regra 3 Tratamento sistemtico de nulos: Valores nulos devem ser suportados de forma sistemtica e indepen-
dente do tipo de dado para representar informaes inexistentes e / ou inaplicveis.
Regra 4 Dicionrio de dados ativo baseado no modelo relacional: A descrio do banco de dados representa-
da no nvel lgico da mesma forma que os dados ordinrios, permitindo que usurios autorizados utilizem a mesma
linguagem relacional aplicada aos dados regulares.
Regra 5 Linguagem Detalhada: Um sistema relacional pode suportar vrias linguagens e vrias formas de recu-
perao de informaes. Entretanto, deve haver pelo menos uma linguagem, com uma sintaxe bem definida e ex-
41
pressa por conjuntos de caracteres, que suporte de forma compreensiva todos os seguintes itens: definio de dados,
definio de views, manipulao de dados (interativa e embutida em programas), restries de integridade, autoriza-
es e limites de transaes.
Regra 6 Atualizao de Views: Todas as vises ("views") que so teoricamente atualizveis devem tambm ser
atualizveis pelo sistema.
Regra 7 Atualizao de alto nvel: A capacidade de manipular um conjunto de dados (relao) por de um simples
comando deve-se estender s operaes de incluso, alterao ou excluso de dados.
Regra 8 Independncia Fsica: Programas de aplicao permanecem logicamente inalterados quando ocorrem
mudanas no mtodo de acesso ou na forma de armazenamento fsico.
Regra 9 Independncia Lgica: Mudanas nas relaes e nas views provocam pouco ou nenhum impacto nas a-
plicaes.
Regra 10 Independncia de Integridade: As aplicaes no so afetadas quando ocorrem mudanas nas restri-
es de integridade.
Regra 11 Independncia de Distribuio: As aplicaes no so logicamente afetadas quando ocorrem mudan-
as geogrficas dos dados. Devem permanecer inalterados quando so distribudos em meios ou mquinas diferen-
tes.
Regra 12 No Subverso: Se um sistema possui uma linguagem de baixo nvel, essa linguagem no pode ser usa-
da para subverter as regras de integridades e restries definidas no nvel mais alto.
Alm dessas doze regras bsicas, o modelo relacional tambm define nove regras estruturais que tratam da definio de cha-
ves primrias, chaves estrangeiras, views, tabelas etc.; dezoito regras de manipulao que definem as operaes de "join",
"union", "division" etc.; e trs regras de integridade: integridade de entidade, integridade referencial e a capacidade de definir
outras regras de integridade sem introduzir dependncia estrutural. A integridade de entidade define que uma chave primria
no pode ter valores duplicados ou nulos.
A integridade referencial determina que o valor de uma chave estrangeira deve ter obrigatoriamente correspondncia em uma
chave primria de uma outra relao.

lgebra Relacional
A lgebra relacional uma linguagem de consultas procedural, que consiste em um conjunto de operaes tendo como entra-
da uma ou duas relaes e produzindo, como resultado, uma nova relao.
Seleo ( ): seleciona tuplas que satisfaam uma determinada condio. O resultado uma relao com a mesma
estrutura da tabela original, e que contm as linhas que satisfazem condio.
Projeo ( ): retorna uma relao apenas com os atributos selecionados. Duplicatas so eliminadas.
Unio ( ): une dois conjuntos de relaes. Ex:
nome
(tab_clientes)
nome_cliente
(tab_devedor)
Interseo ( ): encontra as tuplas que esto tanto em uma relao quanto em outra.
Diferena (-): encontra as tuplas que esto em uma relao, mas no em outra.
Produto Cartesiano (x): combina as informaes de duas relaes, contendo todos os pares de tuplas possveis. O
nmero de tuplas resultante ser o produto entre o nmero de tuplas de cada relao.
Juno ( ): esta operao fundamental une duas relaes atravs de uma coluna em comum entre elas, efetivando
os relacionamentos entre as entidades de um banco de dados.
Diviso ( ): usada quando a consulta emprega a frase "para todos", pois responde perguntas do tipo "quais forne-
cedores fornecem todas as peas?". til em relacionamentos "muitos para muitos".

Normalizao
Normalizao uma tcnica de projeto amplamente utilizada no desenho de bancos de dados relacionais.
A teoria da normalizao baseada no conceito de formas normais. Uma tabela relacional dita estar numa determinada
forma se ela satisfaz um certo conjunto especfico de restries.
42
Normalizao o processo de remoo de dados redundantes de tabelas relacionais, atravs de sua decomposio em tabelas
menores. O objetivo da normalizao criar um conjunto de tabelas relacionais livres de dados redundantes e que pode ser
modificada de forma consistente e correta.

Dependncia Funcional
Um atributo Y funcionalmente dependente de um atributo X se cada valor de X tenha associado a ele precisamente um va-
lor de Y. Quando o atributo X uma chave primria, ento todos ao atributos so, por definio, dependentes de X, pois no
podem existir dois registros com o mesmo valor para X.
Notao: R.x R.y (l-se a coluna x da tabela relacional R funcionalmente determina (identifica) a coluna y.
A dependncia funcional pode ser classificada em:
Total: um atributo totalmente dependente de outro se ele for funcionalmente dependente do outro e no dependen-
te de um subconjunto de outro
Parcial: um atributo parcialmente dependente de outro se ele for funcionalmente dependente de um subconjunto
de outro
Considere a tabela abaixo, onde a chave primria formada pelos atributos cdigo-func + cdigo-curso. O atributo avaliao
dependente total da chave composta. J o atributo descrio-curso tem dependncia parcial com relao esta chave, pois
depende somente de parte dela, ou seja, de cdigo-curso.

cdigo-func cdigo-curso descrio-curso avaliao data-concluso
00001 ENG01 ENG. CIVIL A 01/01/2005

Primeira Forma Normal
Definio: Uma tabela relacional est na primeira forma normal se todos os valores das colunas so atmicos, ou seja, assu-
mem apenas um nico valor.
Elimine atributos multivalorados criando tan-
tos conjuntos de entidades quantos forem os
atributos multivalorados
A tabela ao lado anteriormente possua valores multi-
valorados para Cdigo-Pea (P1,P2,P3,P4,P5) e Quan-
tidade (300,200,400,200,100). Agora est na forma
1FN.
Entretanto, ela ainda contm dados redundantes, pois a
informao da CIDADE e STATUS CIDADE precisa
ser repetida para todas as peas.
No possvel cadastrar um certo fornecedor para uma
cidade at que ele fornea uma pea. Isso no dese-
jvel.



Segunda Forma Normal
Definio: Uma tabela relacional est na segunda forma normal se est na primeira forma normal e todas as colunas no-
chave so totalmente dependentes da chave primria inteira.
Crie tabelas separadas para conjuntos de valores que se referem a ml-
tiplos registros e relacione essas tabelas atravs de uma chave estran-
geira


43
As informaes CIDADE e STATUS CIDADE no so totalmente dependentes da chave primria total, por isso foi criada a
tabela FORNECEDOR para guardar esses dados, tendo como chave primria o Cdigo Fornecedor.
Note que ainda h o problema de se relacionar o Status com a Cidade, pois deve existir obrigatoriamente um fornecedor nela.

Terceira Forma Normal
Definio: Uma tabela relacional est na terceira forma normal se est na segunda forma normal e todas as colunas no-chave
so funcionalmente dependentes apenas da chave primria.
Crie tabelas separadas para colunas que no dependem da chave primria.
Foi criada a tabela CIDADE com o nome da cidade como chave primria. Desta forma, a tabela
FORNECEDOR s precisa guarda o Cdigo Fornecedor (chave) e o valor da Cidade, que se rela-
ciona com esta tabela.
Um esquema de dados nessa situao pode facilmente lidar com o projeto de um banco de dados
para uma empresa inteira.

Outras Formas Normais
Em um relacionamento muitos-para-muitos, entidades independentes no podem ser armazenadas na mesma tabela. A quarta
forma normal (4FN) lida com este problema, criando tabelas de relacionamentos apenas com chaves primrias e estrangeiras,
removendo entradas duplicadas em outras tabelas.
A quinta forma normal (5FN) afirma que deve ser possvel reconstruir a tabela original a partir das tabelas em que ela foi
dividida. O benefcio de aplicar esta regra assegurar que nenhuma coluna estranha ao contexto foi criada e que todas as ta-
belas criadas so to grandes quanto necessariamente precisam ser.
uma boa prtica aplicar estas regras, mas, a menos que voc esteja trabalhando num esquema de dados muito grande, voc
provavelmente no precisar delas.

Ambiente Operacional
Conceito de transao
um conjunto de procedimentos que executado num banco de dados, que para o usurio visto como uma nica ao. A
integridade de uma transao depende de 4 propriedades, conhecidas como ACID.
Atomicidade: Uma transao no pode ser executada pela metade, isto , ou se executa ela por inteiro, ou se retorna
para o estado anterior a transao, onde nada foi executado.
Consistncia: Uma transao deve ser efetuada como um programa que preserva a consistncia do BD. Sendo as-
sim, ela de responsabilidade do programador que codifica a transao. Ela s executa se o estado do Banco de Da-
dos permanecer consistente aps seu fim.
Isolamento: Sua necessidade surge em execues concorrentes, as diversas transaes que ocorrem simultaneamen-
te, no podem ser intercaladas de forma a gerar um estado inconsistente.
Durabilidade: Quando ocorre
falha no banco de dados, apos
a execuo com sucesso de
uma transao, a durabilidade
garante por algum mecanismo
a recuperao das informaes
perdidas.

Concorrncia
Controle de concorrncia um mtodo
usado para garantir que as transaes


44
so executadas de uma forma segura e segue as regras ACID. Os SGBD tm de ser capazes de assegurar que nenhuma ao
de transaes submetidas (committed transactions) sero perdidas ao desfazer transaes abortadas (rollback). Uma transao
uma unidade que preserva consistncia.
Deadlocks acontecem quando duas diferentes aplicaes tentam e alteram os mesmos dados na mesma hora. Neste ponto,
ambas as sesses so bloqueadas, pois cada uma est aguardando a outra para serem liberadas. Os SGBDS atuais tratam o
deadlock atravs da sua deteco, encerrando uma das sesses (com rollback), e informando o erro por de uma mensagem.
Outros problemas que podem ocorrer com um banco de dados, devido concorrncia de transaes so:
Problema da Atualizao Perdida: quando duas transaes acessam os mesmos itens em operaes intercaladas, e
tornam o valor de um dos itens de forma incorreta.
Problema da Atualizao Temporria: uma transao atualiza um item, que acessado por outra transao, mas a
atualizao no item falha por alguma razo, e volta ao seu valor.
Problema do Sumrio Incorreto: ocorre quando uma transao aplica uma funo agregada (estatstica, como con-
tagem ou mdia) para um grupo de registros, enquanto outras transaes fazem atualizaes no grupo.
Existem tcnicas para impedir que esses problemas ocorram:
Bloqueio em 2 fases: consiste de aplicar bloqueios em operaes de atualizao ou consulta, sendo do tipo:
o Bloqueio Compartilhado (Shared): permite que outras transaes leiam o item
o Bloqueio Exclusivo (Exclusive): controlado por uma transao nica
Ordenao por Timestamp: o timestamp um identificador nico para a transao, criado pelo SGBD.

Recuperao
a capacidade de recuperao automtica no caso de falhas e de ferramentas de restaurao do banco de dados. Aplicativos
de importao e exportao de dados (tabelas, outros objetos) devem estar disponveis.
As falhas so classificadas como:
Transao: erros de lgica, diviso por zero, overflow, parmetros invlidos, etc.
Sistema: erros que afetam o sistema como um todo, como crash do sistema, falta de energia, deadlocks...
Mdia: normalmente relacionado ao hardware, como falha ao gravar na memria principal, problemas de disco...
Para se recuperar de falhas que afetam as transaes, o sistema mantm um log, mantido em disco.

Segurana
a existncia de mecanismos de bloqueio a acessos no autorizados. Algumas funcionalidades:
Controlar o acesso ao banco de dados
Conceder acesso a objetos especficos no banco de dados.
Confirmar privilgios concedidos e recebidos com o dicionrio de dados
Criar sinnimos para os objetos de banco de dados

Independncia dos Dados
As aplicaes no devero sofrer alterao em funo de mudanas fsicas no banco de dados. Tambm devero ser imunes a
reestruturaes lgicas do banco.
A habilidade de modificar a definio de um esquema em um nvel sem afetar a definio de esquema num nvel mais alto
chamada de independncia de dados. Existem dois nveis:
Independncia fsica de dados: habilidade de modificar o esquema fsico (interno) sem a necessidade de reescrever
os programas aplicativos. As modificaes no nvel fsico melhoram o desempenho.
45
Independncia lgica de dados: habilidade de modificar o esquema conceitual sem a necessidade de reescrever os
programas aplicativos. As modificaes neste nvel so necessrias quando a estrutura lgica do banco alterada.

Integridade
a capacidade do banco de garantir em qualquer instante a consistncia do banco de dados, atravs de integridade referenci-
al, integridade de domnio e integridade de entidade.

Procedimentos (Stored Procedures)
Procedimento armazenado ou Stored Procedure uma coleo de comandos em SQL para gerenciamento de Banco de dados.
Encapsula tarefas repetitivas, aceita parmetros de entrada e retorna um valor de status (para indicar aceitao ou falha na
execuo). O procedimento armazenado pode reduzir o trfego na rede, melhorar a performance, criar mecanismos de segu-
rana, etc.
Exemplo: (MS-SQL Server):
Create procedure busca
@nomedebusca varchar (50)
as select nome1, nome2
from nome_da_tabela
where nome = @nomedebusca

Vises (views)
Uma viso (view) uma tabela lgica ou virtual composta pelo resultado de um conjunto de queries pr-compiladas. Diferen-
te de tabelas normais em um banco de dados relacional, uma view no faz parte do esquema fsico, mas sim uma tabela din-
mica e virtual, computada ou coletada de dados do banco. Alterar os dados em uma viso altera os dados do banco, embora o
SGBD possa ter meios de impedir isso (read only views).

Gatilhos (Triggers)
Gatilho ou trigger um recurso de programao presente na maioria dos sistema de gerenciamento de banco de dados, utili-
zado para associar um procedimento armazenado a um evento do banco de dados (leitura, incluso, excluso, atualizao de
registro, por exemplo) de modo que o procedimento armazenado seja executado automaticamente sempre que o evento asso-
ciado ocorrer.

ndices e otimizao de acesso
O ndice um arquivo auxiliar associado a uma tabela. Sua funo acelerar o tempo de acesso s linhas de uma tabela, cri-
ando ponteiros para os dados armazenados em colunas especificas. O banco de dados usa o ndice de maneira semelhante ao
ndice remissivo de um livro, verificando um determinado assunto no ndice e depois localizando a sua posio em uma de-
terminada pgina.

Bancos de Dados Distribudos
Os Bancos de Dados Distribudos surgiram com a fuso das tecnologias de banco de dados e de rede de comunicao de da-
dos. Um BDD pode ser entendido como uma coleo de mltiplos bancos de dados, logicamente inter-relacionados, distribu-
dos por uma rede de computadores. Um Sistema Gerenciador de Banco de Dados Distribudo um sistema de software que
gerencia um Banco de Dados Distribudos enquanto torna a distribuio transparente para o usurio.

46
Caractersticas
Um sistema de banco de dados distribudos consiste em uma coleo de ns, cada qual podendo participar na execuo de
transaes que fazem acesso a dados em um ou diversos ns. A diferena principal entre sistemas de bancos de dados centra-
lizados e distribudos que no primeiro os dados esto localizados em um nico local, enquanto no ltimo os dados residem
em diversos locais, e h a necessidade de comunicao entre eles.
Uma vantagem que se um n falhar em um sistema distribudo, os ns remanescentes podem ser capazes de continuar ope-
rando. Em particular, se itens de dados so duplicados em diversos ns, uma transao que necessita de um item de dado par-
ticular pode ach-lo em diversos ns. Assim, a falha de um n no implica necessariamente no desligamento do sistema.
A principal desvantagem do sistema de banco de dados distribudos a complexidade adicional requerida para assegurar a
prpria coordenao entre os ns. Uma vez que os ns que formam o sistema distribudo operam em paralelo, mais difcil
assegurar que os algoritmos esto corretos, e h um grande potencial para defeitos. Pode existir tambm sobrecarga de pro-
cessamento, j que h troca de mensagens entre os ns.
Transparncia na distribuio, replicao e fragmentao
Melhora na confiabilidade, disponibilidade e desempenho
Fcil de expandir (extensibilidade)
Complexidade no controle
Os BDDs podem implementar operaes adicionais que se aproveitam da distribuio dos ns para melhorar algum aspecto
do banco. Uma dessas operaes a Semi-juno, que visa reduzir o nmero de tuplas em uma relao antes de transferi-la
para outro site. Outra questo no processamento de consultas onde execut-las: no cliente ou no servidor:
Query Shipping: transporte da consulta do cliente para o servidor, para ser executada. Vantajosa quando o servidor
possui grande capacidade de armazenamento.
Data Shipping: transporte da consulta do servidor para o cliente, para ser executada pelo cliente. vantajosa quan-
do h disponibilidade de processamento nos clientes, porm h um alto custo de comunicao na rede (sem cache).
Hybrid Shipping: uma combinao das anteriores, com o objetivo de reduzir ao mximo o custo da execuo.

Fragmentao e Replicao
"Qual site deve ser usado para armazenar quais partes do Banco de Dados?", supondo que no haja replicao.
Fragmentao Horizontal: bancos armazenam um subconjunto de tuplas (ex: onde DNO < 5)
Fragmentao Vertical: bancos armazenam um subconjunto de colunas
Fragmentao Mista: ou hbrida, combinao das anteriores
A replicao de dados entre os bancos de dados distribudos implica na sua redundncia entre os sites, sendo til na melhoria
da disponibilidade dos dados, pois se um site ficar fora, o dado pode ser buscado em outro. Isso ainda mais forte na arquite-
tura completamente replicada, que possui alta disponibilidade e capacidade de recuperao. O desempenho das consultas au-
menta, j que no necessrio navegar pela rede para buscar um dado replicado. Mas o desempenho em atualizaes diminui.

Banco de Dados de Objetos
Os Banco de Dados de Objetos (BDOs) so projetados de modo que possam ser diretamente integrados com os softwares que
esto sendo desenvolvidos, e que utilizam linguagens de programao orientadas a objetos.
Um objeto possui dois componentes: o seu estado (valor) e o seu comportamento (operaes). Ao converter um modelo
relacional para um outro orientado a objetos, alguns itens podem ser mapeados diretamente, como os atributos para variveis
de instncia, e os relacionamentos entre objetos so representados por referncias inversas (OIDs, integridade referencial).
Um BDOO fornece uma identidade nica (OID) para cada objeto armazenado.
O estado de um objeto pode ser formado por outros objetos, pelo uso de alguns construtores de tipo. Alguns deles so:
Atmico: nmeros inteiros, nmeros reais, cadeia de caracteres, booleanos.
Tupla (tuple): um tipo estruturado, agregando informaes afins. Corresponde ao struct do C++.
47
Conjunto (set): nesse tipo de dado no pode haver dois elementos com o mesmo valor (na bag isso possvel).
List, Bag e Array: so do tipo "coleo". O tipo List e Array so ordenados, enquanto o Bag desordenado.
Outros conceitos que devem ser levados em conta em BDOs so:
Encapsulamento de Operaes
Compatibilidade com linguagens de programao
Hierarquias de tipo e Herana (aumenta a reusabilidade e diminui a quantidade de cdigo escrito).
Suporte a objetos complexos
Polimorfismo e sobrecarga de operador
Criao de verses (suporte para vrias verses do mesmo objeto)
ODL (Linguagem de Definio de Objetos) e OQL (Linguagem de Consulta de Objetos, similar ao SQL)

SQL (ANSI)
SQL (Structured Query Language) uma linguagem de pesquisa declarativa de banco de dados, utilizada para manipulao
de dados e criao ou manuteno de bancos relacionais. SQL foi criada originalmente pela IBM, e foi adotada como um
padro pela ANSI em 1986 e pela ISO no ano seguinte.
A maioria dos bancos de dados relacionais utilizam o SQL como linguagem padro. Apesar disso, o SQL no pode ser consi-
dervel portvel entre os vrios bancos de dados, pois muitos bancos de dados implementam extenses do SQL (como o
PL/SQL da Oracle e o Transact-SQL da Microsoft), e muitos tambm omitem ou modificam algumas implementaes de
certos comandos ou tipos de dados.
A linguagem SQL baseada na lgebra Relacional, com algumas modificaes e extenses.

Principais instrues de manipulao de dados
SELECT o comumente mais usado do DML, comanda e permite ao usurio especificar uma query como uma descrio do
resultado desejado. A questo no especifica como os resultados deveriam ser localizados.
INSERT usada para adicionar uma linha (formalmente uma tupla) a uma tabela existente.
UPDATE para mudar os valores de dados em uma tupla de tabela existente.
DELETE permite remover tuplas existentes de uma tabela.
BEGIN WORK (ou START TRANSACTION, dependendo do dialeto SQL) pode ser usado para marcar o comeo de uma
transao de banco de dados que pode ser completada ou no.
COMMIT envia todos os dados das mudanas permanentemente.
ROLLBACK descarta as mudanas nos dados existentes desde o ltimo COMMIT ou ROLLBACK.
COMMIT e ROLLBACK interagem com reas de controle como transao e locao. Ambos terminam qualquer transao
aberta e liberam qualquer cadeado ligado a dados. Na ausncia de um BEGIN WORK ou uma declarao semelhante, a se-
mntica de SQL dependente da implementao.

Uso do Join
Uma juno (join) uma query que combina linhas de vrias tabelas ou vises. Sempre que so especificadas mais de uma
tabela na clusula FROM, uma juno feita.
A juno natural baseada em todas as colunas com o mesmo nome em ambas as tabelas.
SELECT location_id, city, department_name
FROM locations NATURAL [INNER] JOIN departments;

48
A juno cartesiana (ou cross join) acontece quando todas as combinaes linha a linha so geradas.
SELECT a, b FROM cont CROSS JOIN dept

As junes externas (ou outer joins) podem ser direita, esquerda, ou completas, e so usadas para retornar linhas
baseadas em uma condio, assim como as linhas que no atendem condio da tabela direita, ou esquerda, ou
de ambas.
-- Mostra todos os pases, independente da existncia das localida-
des
SELECT country_name, city
FROM locations NATURAL RIGHT OUTER JOIN countries

SELECT e.emp_id, e.emp_name, d.dept_id, d.dept_name
FROM emp e FULL OUTER JOIN dept d ON e.dept_id = d.dept_id;

Subconsultas
Subconsultas (ou subqueries) so queries dentro de outras queries. A query mais interna processada primeiro, e retorna um
conjunto de resultados para a query externa.
Subconsultas utilizadas na clusula FROM geram o que chamado de uma inline view.
Subconsultas utilizadas na clusula WHERE so chamadas de subconsultas aninhadas.
Exemplos:
SELECT last_name, first_name, salary FROM emp
WHERE salary = (SELECT MAX(salary) FROM emp);

SELECT name FROM city
WHERE (cnt_code, st_code) IN
(SELECT cnt_code, st_code FROM state
WHERE st_name = 'TEXAS');

Elaborao de consultas SQL
Outros operadores utilizados em SQL ANSI so os operadores de conjuntos:
UNION: retorna todas as linhas nicas selecionadas por qualquer uma das queries.
UNION ALL: retorna todas as linhas (incluindo duplicatas) retornadas por qualquer uma das queries.
INTERSECT: retorna linhas selecionadas de ambas as queries (linhas em comum).
MINUS: retorna linhas nicas selecionadas da primeira query, que no estejam presente na segunda.
A operao de diviso uma das consultas mais difceis utilizando o SQL.

-- S a tabela (A B E) e R a tabela (A B).
-- Diviso de S por R
SELECT S.E FROM S WHERE NOT EXISTS
(SELECT * FROM R WHERE NOT EXISTS
(SELECT * FROM S WHERE R.A = S.A AND R.B = S.B
49

50
Solues de Suporte Deciso
Apoio Decises a entrega de informaes a usurios finais que precisam de dados para tomar as suas decises de negcio.
Para fornecer esta funcionalidade, os dados de mltiplos sistemas transacionais so integrados em um nico sistema, e anali-
sados na forma de uma informao de apoio decises. Este sistema chamado SAD (Sistema de Apoio Decises).
Para garantir um suporte eficiente s organizaes, o SAD foi desenvolvido em diferentes fases. Originalmente, companhias
criaram os relatrios de gerenciamento, que eram entregues em papel. Porm, ficou bvio que este mtodo de gerenciamento
de informaes para usurios era ineficiente. Eles eram difceis de manter, e possuem uma acessibilidade limitada, alm de
ser suscetvel a erros humanos.
Para sobrepor esta limitao, relatrios passaram a ser gerados em um ambiente de linguagem de terceira gerao (3GL), on-
de o programador precisaria coletar e entender os dados desejados pelo usurio, e ento definir o formato apropriado (como
cabealhos, rodaps e quebras de controle). Aps projetar o relatrio, o programador precisava codific-lo e test-lo. A chan-
ce de erros humanos diminuiu, porm o processo todo consumia bastante tempo, alm de no suportar relatrios customiz-
veis pelos requerimentos de vrios usurios (como o departamento de marketing, vendas, etc). O cdigo para obter dados de
vrios sistemas era muito complexo.
Para superar os problemas dos ambientes 3GL, algumas organizaes criaram sistemas de informaes executivas (EISs), que
foram projetados para fornecer um alto gerenciamento, com suporte automatizado decises. Estes sistemas foram teis para
autoridades na empresa, como executivos seniores. Os empregados de nvel mais baixo, como o pessoal de produo, no
tinha acesso esses sistemas. Alm disso, o custo, complexidade e inflexibilidade destes sistemas reduziu a sua eficincia.
Com o advento da tecnologia cliente / servidor (1980), novas ferramentas foram desenvolvidas para permitir aos clientes cria-
rem seus prprios relatrios, embora ainda no fossem amigveis. O usurio precisaria conhecer as estruturas de dados arma-
zenadas nos bancos, s vezes gerando queries de baixa performance (com vrios joins), pois esses bancos no foram projeta-
dos visando o suporte decises.
Desta forma foram criados bancos de dados especializados, projetados para a anlise das informaes. Esses bancos foram
conhecidos como Data Warehouse, que utilizavam processamento on-line analtico (OLAP) para produzir os resultados da
anlise dos dados.
Os DAS atuais so projetados para ajudar uma organizao responder seis tipos de perguntas para suportar suas decises:
Quem?, O Qu?, Quando?, Onde?, Por qu? e Como? Alguns exemplos: "Quem o cliente?", "O qu eles compram da nossa
empresa?", "Por qu eles compram de nossos concorrentes?". Responder a essas perguntas ajuda os gerentes a entender as
necessidades de seus clientes e da sua prpria organizao.

Conceitos de Data Warehouse e Aplicaes
O termo Data Warehouse (DW) utilizado para nomear um banco de dados histrico, separado do ambiente de produo da
empresa e projetado para apoio deciso. Um DW uma coleo de dados integrados, orientados por assunto, no-volteis
e variveis em relao ao tempo, de apoio s tomadas de deciso gerenciais.
Nos ltimos dez anos, alguns projetos de DW fracassaram, e o que observamos hoje a presena de uma manobra mercado-
lgica tentando vender o mesmo produto com nome diferente. Um DW deve:
Tornar as informaes de uma organizao acessveis: o contedo de um DW deve ser compreensvel e navegvel e
o acesso aos dados deve ser feito com bom desempenho.
Tornar as informaes de uma organizao consistentes: as informaes oriundas de diferentes reas da organizao
devem ter garantidas a integridade semntica, ou seja, combinadas sem problemas de nomes iguais para coisas dife-
rentes, ou nomes diferentes para a mesma coisa.
Ser uma fonte de informaes flexvel e adaptvel: um DW deve suportar contnuas modificaes estruturais para
insero de novos dados sem comprometer a estrutura j existente.
Ser o alicerce para a tomada de deciso: o DW deve conter os dados certos na forma certa para suportar a tomada de
deciso. S h uma verdadeira sada de um DW: as decises que forem tomadas aps o DW apresentar as evidn-
cias. O DW antes de tudo um SAD (Sistema de Apoio Decises).
Um termo relacionado o BI, abreviao para Business Intelligence, ou Inteligncia Aplicada aos Negcios. Podemos dizer
que BI um conjunto de tecnologias que permitem a anlise do desempenho de um negcio.
51
Ferramentas de BI sempre existiram e fizeram parte de um projeto de DW. Veremos que a maioria das solues de BI apre-
sentadas precisam de um banco de dados histrico e
separado do ambiente de produo (DWs setoriais ou
Data Marts). Para analisar o desempenho do negcio
com eficincia, deve-se usar um banco de dados his-
trico separado das bases operacionais. A maioria
dos produtos existentes no mercado sempre montam
um DW para esse tipo de anlise.
Para implantar ferramentas de BI com bom desempe-
nho, como um pacote CRM (Customer Relationship
Management), por exemplo, necessria a imple-
mentao de um DW, que a base para aplicaes de
BI.
A arquitetura de um ambiente de data warehouse abrange estruturas de armazenamento, mecanismos de integrao, comuni-
cao, processamento e apresentao da informao para o usurio final. composta de:
Arquitetura de Dados: descreve o contedo do data warehouse os dados que so importantes para o negcio, as
estruturas de armazenamento que compem o ambiente do DW e as fontes que as alimentam, os modelos de dados
lgicos e fsicos, agregaes e hierarquias, tudo baseado nos requisitos levantados. Define a granularidade dos da-
dos, o volume e a distribuio dos dados no ambiente.
Arquitetura Tcnica: abrange os processos e as ferramentas que atuam sobre os dados. ela que se preocupa com
a forma com a qual os dados sero extrados da fonte, como sero tratados de modo a atender os requisitos do neg-
cio, e como fazer para que eles se tornem acessveis para o usurio. responsvel pelo gerenciamento das atividades
que criam e mantm as informaes do DW.
Administrao e Gerenciamento: responsvel por toda a infra-estrutura do ambiente de data warehouse (hardwa-
re, rede, etc.) e pelo gerenciamento dos servios que contribuem para manter o data warehouse atualizado e consis-
tente. Atividades: segurana, monitoramento da performance, dimensionamento do hardware, backup e recuperao,
checagem da qualidade de dados, etc.
Metadados: consistem em informaes sobre dados que compem o data warehouse. Eles so extremamente impor-
tantes dentro do ambiente, pois representam uma viso integrada das bases de dados que fazem parte deste ambiente.
Eles so utilizados para construir, manter, gerenciar e utilizar o DW.

Estruturas de armazenamento para Data Warehouse
Para habilitar a tomada de decises orientada a negcios em uma organizao, os usurios precisam de acesso facilitado aos
dados de negcio relevantes. As caractersticas de um data warehouse permitem isso.
Um data warehouse definido como uma coleo de dados orientados por assunto, integrados, que variam com o tempo e
no volteis, que suportam as capacidades de tomada de deciso dos usurios do negcio. Em um modelo relacional, um sis-
tema de faturamento possui incluses, delees e atualizaes de dados diariamente. J no Warehouse, acontecem somente
cargas de dados e consultas, ou seja, falando tecnicamente, h somente SELECTs e INSERTs, e no h UPDATEs.
Orientado a assuntos: implica que os dados relevantes dos maiores assuntos de uma organizao, como clientes,
produtos e contas, so recolhidos juntos, em nico lugar. Por exemplo, em um sistema bancrio OLTP, aplicaes
independentes so mantidas para as diferentes transaes do cliente (depsitos, emprstimos, etc). Para criar um re-
latrio financeiro para um cliente, precisaramos acessar cada sistema OLTP separadamente. Porm, um data ware-
house pode coletar os dados independentes para fornecer esta informao para o cliente. Como o DW organizado
por temas (assuntos), os dados so menos agrupveis por joins.
Varivel com o tempo: a dimenso do tempo um tema comum onde os dados do DW so construdos. Tempo
um dos critrios primrios para filtragem de vrias atividades. Por exemplo, um analista pode gerar uma query, em
uma dada semana, um dado ms ou ano. Podem ser comparadas as vendas dos primeiros meses com anos anteriores.
Pode responder a pergunta "Vale pena lanar essa campanha no inverno?". A causa de uma subida ou declnio nas
vendas pode ser analisada, assim como outros dados histricos.
Integrado: os dados so carregados de vrias fontes, e antes de serem lidos pelo DW, necessitam ser convertidos em
um formato que seja preciso, significativo e consistente. Exemplo: trs sistemas (vendas, catlogo e vendas especi-
ais), cada sistema identifica um produto de forma diferente (letras, nmeros). Para que a informao sobre os produ-
tos seja carregada pelos trs sistemas de forma significativa, eles devem ser convertidos para um cdigo em comum.

52
No-Voltil: implica que os dados no so alterados aps o seu carregamento pelo DW. Porm, esses dados devem
ser precisos e atualizados, pois so o alvo de queries para a busca de informaes. Considere o exemplo de uma ca-
deia de lojas alimentcias. A movimentao de um produto entre as lojas monitorado e atualizado por um sistema
OLTP. O status desta movimentao muda em cada estgio. O status do produto voltil at ele ser encaminhado
para o depsito de uma loja, quando o seu status se torna completo, e pode ser armazenado no DW.

Data Marts
Acessar dados do DW pode consumir bastante tempo, por causa do grande nmero de usurios e volume de dados. Para lidar
com esse problema, utilizam-se Data Marts.
Um data mart uma implementao de uma estratgia de particionamento de dados, que permite os usurios acessar dados
por departamento. Podem existir DW que possuem informaes de todos os departamentos de uma organizao, mas tambm
um data mart que contm dados apenas do dept. financeiro. Os data marts podem ser o ponto de incio de um DW.
Se um data mart referenciado por um data warehouse, ento ele chamado de dependente. Caso seja carregado diretamente
de sistemas OLTP, ento chamado de independente.
Com o aparecimento de data mart ou warehouse departamental, a abordagem descentralizada passou a ser uma das opes de
arquitetura data warehouse.Os data marts podem surgir de duas maneiras. A primeira top-down e a outra a botton-up.
Top-down: quando a empresa cria um DW e depois parte para a segmentao, ou seja, divide o DW em reas me-
nores gerando assim pequenos bancos orientados por assuntos departamentalizados.
Botton-up: quando a situao inversa. A empresa, por desconhecer a tecnologia, prefere primeiro criar um banco
de dados para somente uma rea. Com isso os custos so bem inferiores de um projeto de DW completo. A partir da
visualizao dos primeiros resultados parte para outra rea e assim sucessivamente at resultar num DW.
Implementar um data mart traz alguns benefcios, como a localizao (geogrfica), fazendo que seja especfico para uma
determinada regio, alm de ser menor e mais fcil de gerenciar que o DW organizacional. Outro benefcio de implementar
um data mart que ele reduz a demanda de dados no DW.
A tecnologia usada tanto no DW como no Data Mart a mesma, sendo a principal diferena a de que os Data Marts so
voltados somente para uma determinada rea, j o DW voltado para os assuntos da empresa toda. Portanto, cabe a cada em-
presa avaliar a sua demanda e optar pela melhor soluo. Como um data mart possui uma quantidade significativamente me-
nor de dados que um DW, o nmero de usurios que o acessam tambm menor, reduzindo o trfico na rede.

Metadados no ambiente de inteligncia de negcios.
Metadado definido como um dado sobre um dado. Ele importante para todos os aspectos do desenvolvimento, operao e
uso de um data warehouse. Um metadado de um DW contm:
Regras de transformao e extrao de dados antes de serem carregados para o DW.
Descrio detalhada da estrutura, contedo, chaves primrias e ndices dos dados do DW.
Informao sobre a localizao e significado do dado. Ajuda usurios a navegar pelos dados do DW.
Informao utilizada para mapear dados entre os sistemas de origem e o data warehouse.
Um guia para os algoritmos utilizados ao sumarizar os dados.
Os metadados devem estar sempre atualizados, para garantir que o DW funcione com eficincia.

Ferramentas de front-end: principais recursos e aplicaes
o conjunto de produtos para acesso e anlise de dados do DW. Permitem ao usurio navegar entre os dados, resumi-los,
compar-los, etc. So ferramentas projetadas para trabalhar de acordo com o modelo de dados implementado. Portanto, a es-
colha do modelo de dados do DW fator crtico para o front-end.
So trs as principais ferramentas de desenvolvimento de DW disponveis no mercado: Data Mart Suite (Oracle), Impromptu
e PowerPlay (Cognos), e SQL Server 7.0 (Microsoft)

53
Processo de construo de um Data Warehouse
Exemplo de Caso: Cinemas. Acompanhar a evoluo do pblico e valor arrecadado em nvel de regio do pas, estado e ci-
dade, classificados por gnero de filme e sala de cinema. Avaliar a evoluo de filmes por ator participante, diretor, etc.
Necessidades Executivas: Quais diretores atraem maior pblico e em que gnero est esse pblico? Quais perodos do ano
possuem maior pblico por gnero, ator/diretor, e geograficamente?
Como comear?: Analisar o modelo atual do sistema transacional e, a partir deste, construir o esquema estrela. Modelar o
Data Mart a partir das informaes colhidas de acordo com suas necessidades.
Construindo o Esquema Estrela: Para construir um modelo dimensional, inicialmente, necessria total independncia do
modelo transacional. Analisar cada solicitao cuidadosamente para identificar fatos.
Identificando o Fato: O que nos d idia de ao nas solicitaes? O que medido? Quais indicadores de negcios? Respos-
ta: A evoluo de pblico e valor arrecadado. Logo, analisando as solicitaes, temos que Exibio de Filmes nosso fato.
Pois: Quem tem pblico para ser acompanhada a evoluo? Quem tem valor arrecadado? O fato que tem os indicadores de
negcio exibio de filmes.
Identificando as Dimenses: Onde acontece o fato? Quando acontece o fato? Quem realiza o fato? O que acontece no fato?
Dimenses:
Onde: est sendo solicitada a evoluo de medidas de exibio de filmes por regio, estado e cidade.
O Qu: Gnero do Filme o O QUE do fato. Resumindo: o que deve ser acompanhado. Saber se cresce ou no o
pblico de determinado tipo de filme em determinada regio. Exemplo: ser que filmes com linguagem escrachada
so bem aceitos no Sul do Brasil?
Quem: A Sala de Exibio o QUEM do nosso problema. Pois Quem exibe uma sesso de cinema.
Quando: A granularidade desta dimenso est bem disposta nos requisitos: MENSALMENTE. Porm, se temos
MS, podemos facilmente estruturar nossa Dimenso Tempo como: Ano e Ms. Porm quando analisamos os requi-
sitos com mais detalhes, podemos ver que ser necessria uma anlise de PERODO DE FRIAS. Este tipo de anli-
se no pode ser feita com o gro MS. Para Contornar este problema modelaremos nossa dimenso TEMPO como:
Trimestre, Ms, Data, Ano
Como Tratar Hierarquia no Modelo Dimensional: membros da hierarquia so atributos da mesma dimenso. Criar uma
entidade dimenso para cada nvel hierrquico (SnowFlake).
Definio de Chaves: chaves utilizadas em cada entidade dimenso no devem ser as mesmas do modelo transacional, pois
para o Data Mart importante manter o histrico dos dados. Cada dimenso deve ter uma chave exclusiva nesse ambiente.
Validao do Modelo: para validar este modelo s resta estruturar tabelas com simulao de dados. Por meio de observao
poderemos confirmar se possvel obter resultados que satisfaam as necessidades.

OLAP (On-line Analytical Processing)
A natureza multidimensional dos problemas de negcios resultaram em uma evoluo na tecnologia OLAP. Ela permite a
anlise de dados histricos para a tomada de decises. So vrios os seus benefcios:
Fornece um meio de acessar, visualizar e analisar dados, com grande flexibilidade.
Permite lidar com queries multidimensionais, que so mais complexas.
Apresenta dados aos usurios finais de forma natural e intuitiva, navegando pelos modelos de dados de forma efeti-
va, entendendo a informao. A organizao reconhece o valor dos seus dados.
Acelera a entrega da informao para usurios finais, pois os valores computados so preparados na fase de projeto.
OLAP garante a segurana dos dados, enquanto vrios usurios compartilham dados confidenciais.
As ferramentas OLAP so as aplicaes que nossos usurios finais tm acesso para extrarem os dados de suas bases com os
quais gera relatrios capazes de responder as suas questes gerenciais. Elas surgiram juntamente com os sistemas de apoio a
deciso para fazerem a extrao e anlise dos dados contidos nos Data Warehouses e Data Marts. Algumas caractersticas:
Consultas ad-hoc: so consultas com acesso casual nico e tratamento dos dados segundo parmetros nunca antes
utilizados, geralmente executado de forma iterativa e heurstica. O prprio usurio gera consultas de acordo com su-
as necessidades de cruzar as informaes de uma forma no vista e com mtodos que o levem aquilo que procura.
54
Slice-and-Dice: essa caracterstica de extrema importncia. Permite analisar as informaes de diferentes prismas
limitados somente pela nossa imaginao. Utilizando esta tecnologia conseguimos ver a informao sobre ngulos
que anteriormente inexistiam sem a confeco de um DW e a utilizao de uma ferramenta OLAP.
Drill Down/Up: consiste em fazer uma explorao em diferentes nveis de detalhe das informaes. Com o Drill
Down voc pode subir ou descer dentro do detalhamento do dado, como por exemplo analisar uma informao
tanto diariamente quanto anualmente, partindo da mesma base de dados.
Gerao de Queries: a gerao de queries no OLAP se d de uma maneira simples, amigvel e transparente para o
usurio final, o qual precisa ter um conhecimento mnimo de informtica para obter as informaes que deseja.
Cada uma destas tecnologias e tcnicas tem seu lugar no mercado de Suporte Deciso e apia diferentes tipos de anlises.
importante lembrar que as exigncias do usurio devem ditar que tipo de Data Mart voc est construindo. Como sempre, a
tecnologia e tcnicas devem estar bem fundamentadas para atenderem da melhor maneira possvel essas exigncias.

Arquiteturas OLAP
Para suportar os requerimentos analticos, existem quatro tipos de arquiteturas OLAP que podem ser implementadas, a multi-
dimensional (MOLAP), relacional (ROLAP), desktop (DOLAP) ou hbrida (HOLAP).
DOLAP: ferramentas que disparam uma instruo SQL, de um cliente qualquer, para o servidor e recebem o micro-
cubo de informaes de volta para ser analisado na workstation. O ganho com essa arquitetura o pouco trfego que
se d na rede, visto que todo o processamento OLAP acontece na mquina cliente, e a maior agilidade de anlise, a-
lm do servidor de banco de dados no ficar sobrecarregado, sem incorrer em problemas de escalabilidade. A des-
vantagem que o tamanho do micro-cubo no pode ser muito grande, caso contrrio a anlise passa a ser demorada
e/ou a mquina do cliente pode no suportar em funo de sua configurao.
ROLAP: possuem uma engenharia de acesso aos dados e anlise OLAP com uma arquitetura um pouco diferente.
Nesse caso a consulta enviada ao servidor de banco de dados relacional e processada no mesmo, mantendo o cubo
no servidor. O que podemos notar nesse caso que o processamento OLAP se dar somente no servidor. A principal
vantagem dessa arquitetura que ela permite analisar enormes volumes de dados, em contra partida uma grande
quantidade de usurios acessando simultaneamente poder causar srios problemas de performance no servidor cau-
sando, inclusive, o travamento do mesmo.
MOLAP: processa-se da seguinte forma: com um servidor multidimensional o acesso aos dados ocorre diretamente
no banco, ou seja, o usurio trabalha, monta e manipula os dados do cubo diretamente no servidor. Isso traz grandes
benefcios aos usurios no que diz respeito performance, mas tem problemas com escalibilidade alm de ter um
custo alto para aquisio.
HOLAP: essa nova forma de acessar os dados nada mais do que uma mistura de tecnologias onde h uma combi-
nao entre ROLAP e MOLAP. A vantagem que com a mistura de tecnologias pode-se extrair o que h de melhor
de cada uma, ou seja, a alta performance do MOLAP com a escalibilidade melhor do ROLAP.

Conceitos de modelagem dimensional
A tcnica antiga de se criar bancos de dados simples e compreensvel foi aperfeioada para o surgimento da modelagem di-
mensional. A capacidade de poder observar um banco de dados no formato de um cubo, contendo duas, trs, ou mais dimen-
ses, permite aos usurios analisar seu negcio atravs de uma forma concreta e compreensvel, pois os conjuntos de dados
abstratos se tornam reais.
Sobre o cubo (ou hipercubo) gerado, so definidas as seguintes operaes:
Slice and Dice: ou fatiamento do cubo, a restrio das coordenadas nas dimenses de acordo com critrios defini-
do em cima de atributos das dimenses. Por exemplo: visualizar somente os dados dos mercados de pequeno porte.
Agregao: permite reduzir a dimensionalidade de um cubo ou de uma fatia de cubo. Ex: ao visualizar a receita total
de cada mercado por ms estamos agregando os dados de receita na dimenso produto, eliminando-a do cubo.
Drill-up/Drill-down: a navegao entre nveis de agregao, de acordo com hierarquias existentes nas dimenses.
Ex: o usurio pode comear visualizando dados totais de receita para os mercados e fazer um drill-up para visualizar
os dados totais por bairro, agregando os mercados prximos. A modelagem dimensional proporciona um ganho de
tempo na consulta, melhor organizao do sistema e a sua utilizao se d de forma intuitiva para o usurio.
Um modelo dimensional definido em termos de suas dimenses e suas medidas (ou fatos):
55
Dimenses: Representam as possveis formas de visualizar os dados. So as entradas para as consultas (tempo, regi-
o, cliente, etc). So os atributos e hierarquias das dimenses que permitem realizar as operaes descritas anterior-
mente, por isso a sua descoberta um fator crtico para o sucesso do DW.
Fatos: a tabela central que interliga as dimenses e tem os indicadores de anlise ou mtricas (quantidade, valo-
res,etc). A tabela fato dever possuir, no mnimo, as trs primeiras dimenses. Os fatos so as medies do negcio,
e geralmente so dados numricos e aditivos, podendo ser agregados por somas, mdias, etc. Exemplos de fatos so:
valor total da venda, quantidade vendida, etc.
No existe uma notao grfica amplamente adotada para modelos dimensionais. Uma das representaes lgicas mais co-
mumente utilizada o esquema estrela (star schema), que utiliza a abordagem relacional e os seus componentes, com algu-
mas restries (entidades, relacionamentos, chaves, cardinalidade, etc:

Existe uma variao deste sistema, o floco-de-neve (snowflake schema), que faz a normalizao das tabelas de dimenso,
evitando a redundncia. Mas em geral normalizar uma dimenso no traz muito benefcio para o modelo, piorando a compre-
ensibilidade e diminuindo a performance, em troca da economia de espao.

Desenho de modelos dimensionais a partir de modelos transacionais normalizados
Diagrama Entidade Relacionamento referente ao modelo transacional de um estudo de caso de determinado servio de defesa
do consumidor:


56

Foi identificado o fato ocorrncia. O gro do fato ser o nmero de ocorrncias registradas de uma empresa, em um dia, a-
companhada por um advogado e por um funcionrio do servio de defesa do consumidor:


EIS - Enterprise Information System
Um EIS geralmente qualquer tipo de sistema de computao de "classe enterprise", ou seja, que oferea alta qualidade de
servio (QoS) e lide com uma grande quantidade de dados suportando grandes organizaes. Tipicamente:
Operado por Administradores de Sistemas profissionais
Implantado em servidores dedicados
Oferece conectividade de rede
Fornece servios que suporta as operaes da organizao

ECM - Enterprise Content Management
ECM uma tecnologia de software que permite as organizaes criarem, capturarem, gerenciarem, armazenarem, publicar,
distribuir, buscar e personalizar contedo digital, como imagens, textos, relatrios, vdeo, cdigo, entre outros. Os sistemas
ECM focam principalmente no ciclo de vida das informaes (criao, armazenamento, disseminao, destruio).
Os sistemas ECM podem ser vistos de trs formas: como servios independentes, como um middleware integrado (e dessa
forma fazendo bastante uso das tecnologias de EAI e SOA) ou como um repositrio uniforme para todas as informaes.
Os componentes de um sistema ECM so:
Captura: so funcionalidades e componentes para gerar, capturar, preparar e processar informao eletrnica ou a-
nalgica. Alguns exemplos so as ferramentas OCR (Optical Character Recognition), HCR (Handprint Character
Recognition), processamento de formulrios, ndices e classificao automtica.
Gerenciamento: lidam com o processamento e uso da informao, envolvendo banco de dados para consultas e ad-
ministrao, e sistemas de autorizao de acesso. Ferramentas de controle de verses (Chekin-Chekout), busca e na-
vegao, colaborao e workflow esto includas nessa categoria.
57
Armazenamento: dividido em duas categorias, Store (para armazenamento temporrio) e Preserve (armazenamento
de longo prazo), sendo componentes da infra-estrutura responsveis por guardar a informao, como banco de da-
dos, repositrios, data warehouses, servios de biblioteca e os prprios dispositivos de armazenamento (disco, etc).
Entrega (Deliver): o componente que apresenta a informao para os demais, contendo funes para a introduo
de novas informaes no sistema, personalizao, publicao e distribuio, envolvendo o formato (XML, PDF,
TIF), as tecnologias de segurana, portais para Internet, extranet e intranet, e outras mdias (e-mail, papel, TV, etc).

Data Mining
Knowledge Discovery in Databases (KDD) o processo de extrao de padres (conhecimentos) embutidos nos dados. Alm
disso, os padres extrados devem ser vlidos, novos (previamente desconhecidos), potencialmente teis e compreensveis.
Data Mining um conjunto de tcnicas e ferramentas usadas para identificar padres embutidos em grandes massas de dados.
Data Mining tambm conhecido como "arqueologia" da informao, o processo de extrair inteligentemente tendncias e
informaes escondidas em banco de dados ou outros repositrios de informao. Data mining utiliza-se nas reas de enge-
nharia, cincia, medicina, negcios, educao, etc. um campo interdisciplinar que liga reas como sistema de banco de
dados, estatstica, aprendizado computacional, visualizao de dados, recuperao de informao e computao de alto de-
sempenho. Duas tcnicas de Data Mining so: Descoberta de Regras de Associao e Clustering.
Qualquer sistema de Data Warehouse (DW) s funciona e pode ser utilizado plenamente, com boas ferramentas de explora-
o. Com o surgimento do DW, a tecnologia de Data Mining (minerao de dados) tambm ganhou a ateno do mercado.
Como o DW, possui bases de dados bem organizadas e consolidadas, as ferramentas de Data Mining ganharam grande impor-
tncia e utilidade. Essa tcnica, orientada a minerao de dados, oferece uma poderosa alternativa para as empresas descobri-
rem novas oportunidades de negcio e acima de tudo, traarem novas estratgias para o futuro.
O propsito da anlise de dados descobrir previamente caractersticas dos dados, sejam relacionamentos, dependncias ou
tendncias desconhecidas. Tais descobertas tornam-se parte da estrutura informacional em que decises so formadas. Uma
tpica ferramenta de anlise de dados ajuda os usurios finais na definio do problema, na seleo de dados e a iniciar uma
apropriada anlise para gerao da informao, que ajudar a resolver problemas descobertos por eles. Em outras palavras, o
usurio final reage a um estmulo externo, a descoberta do problema por ele mesmo. Se o usurio falhar na deteco do pro-
blema, nenhuma ao tomada.
A premissa do Data Mining uma argumentao ativa, isto , em vez do usurio definir o problema, selecionar os dados e as
ferramentas para analisar tais dados, as ferramentas do Data Mining pesquisam automaticamente os mesmos a procura de
anomalias e possveis relacionamentos, identificando assim problemas que no tinham sido identificados pelo usurio. Em
outras palavras, as ferramentas de Data Mining analisam os dados, descobrem problemas ou oportunidades escondidas nos
relacionamentos dos dados, e ento diagnosticam o comportamento dos negcios, requerendo a mnima interveno do usu-
rio, assim ele se dedicar somente a ir em busca do conhecimento e produzir mais vantagens competitivas.
As ferramentas de Data Mining, baseadas em algoritmos que forma a construo de blocos de inteligncia artificial, redes
neurais, regras de induo, e lgica de predicados, somente facilitam e auxiliam o trabalho dos analistas de negcio das em-
presas, ajudando as mesmas a conseguirem serem mais competitivas e maximizarem seus lucros.

58
Anlise e Projeto de Sistemas

Anlise e Projeto Estruturado de Sistemas
um assunto abordado por DeMarco, Yourdon e Constantine.
A anlise estruturada a metodologia front-end que permite usurios ou analistas de sistemas converter um problema do
mundo real em um diagrama pictrico ou outra representao lgica que pode ser utilizada subseqentemente pelos desen-
volvedores e programadores para projetar um sistema de informao.
O projeto estruturado se preocupa com o projeto fsico baseado na anlise estruturada, ou seja, a transformao das informa-
es lgicas obtidas no passo anterior para um sistema de informao fsico.
A anlise e projeto estruturado pode ser a metodologia de anlise e projeto mais conhecida. Uma de suas caractersticas a
anlise top-down (hierrquica), que tende a gerar sistemas bem organizados. O seu enfoque passo a passo simplifica o geren-
ciamento do projeto, do risco e de recursos.
Manter a grande quantidade de dados gerados por esta metodologia pode consumir tempo. Alm disso, o seu passo a passo
inflexvel, e comparado com outras metodologias no muito amigvel.
Ferramentas relevantes incluem: Dicionrios de Dados, DFD para a representao das funes do sistema, o modelo E-R para
os relacionamentos entre os dados e o DTE para o comportamento dependente do tempo.

Modelagem de dados
Modelagem de dados olhar os dados do sistema das trs maneiras possveis (dados, funes e comportamento) em mtodos
de anlise ou projeto estruturados. O diagrama de modelagem de dados mais utilizado o Diagrama de Entidade Relaciona-
mento (MER). Eles so construdos de forma que as suas estruturas de dados sejam normalizadas de uma vez. O modelo
criado gradualmente: comeando com as entidades maiores, adicionando os relacionamentos, depois as chaves e os atributos,
para depois adicionar novas entidades.
Em modelagem de dados, os atributos de objetos de dados podem ser usados para nomear uma instncia do objeto de dados,
descrever a instncia ou fazer referncia a outra instncia de outra tabela.

Modelagem Funcional
Na modelagem funcional, o sistema em considerao modelado como uma caixa preta, com um conjunto de entradas e sa-
das. O analista da modelagem est preocupado apenas com o seu funcionamento, e no com os seus detalhes mais internos. A
frase chave aqui "Dada esta entrada, qual a sada do sistema?"
A principal vantagem desta metodologia a sua simplicidade e a sua habilidade de
combinar modelos menores para obter um modelo de sistemas maiores.
A modelagem funcional no apropriada quando os objetos so fortemente conec-
tados (de uma maneira no direcional), como redes eltricas analgicas. Redes lgi-
cas (digitais) no so um problema, pois a direcionalidade especificada no projeto.
A modelagem funcional pode ser classificada em duas maneiras: function-based
approach e variable-based approach.
No modelo baseado em funes existem funes de transferncia, que so os blocos
de construo do sistema, que fazem a conexo entre cada uma de suas partes, indi-
cando a direo do fluxo de dados por setas. No modelo baseado em variveis, o foco dado s variveis afetadas pelas fun-
es. A modelagem funcional suportada pelos diagramas de componente e de execuo.

O Dicionrio de Dados
O dicionrio de dados uma listagem organizada de todos os elementos de dados que so pertinentes ao sistema, com defini-
es precisas e rigorosas, de forma que tanto o usurio como o analista de sistemas tenham uma compreenso comum das
entradas, das sadas, dos componentes dos depsitos de dados. [PRESSMAN]

59
O DFD representa apenas o fluxo de informao do sistema, e o dicionrio de dados completa a especificao do sistema.
uma ferramenta importante durante a anlise detalhada do DFD, e tambm na fase de projeto que segue a anlise. uma tare-
fa tediosa, mas necessria para a preciso e organizao sistemtica dos termos.
Um dicionrio de dados (papel ou automtico), deve ser mantido em
cada estado da criao do DFD. importante descrever no dicionrio
de dados: o significado dos dados, a composio de pacotes de dados,
especificao dos valores e unidades relevantes, e o relacionamento
entre esses dados.
Para definir um dicionrio de dados completo, o significado, a com-
posio e os valores legais de um elemento de dado deve ser descrito
por comentrios:
Peso_atual = *Peso ao entrar no Hospital*
*unidade: quilos; faixa de valores: 1-400*

Exemplo de utilizao:
name = courtesy-title + first-name + (middle-name) + last-name
courtesy-title = [Mr. | Miss | Mrs. | Ms. | Dr. | Prof. ]
first-name = {legal-character}
middle-name = {legal-character}
last-name = {legal-character}
legal-character = [A-Z|a-z|0-9|'|-| | ]

DFD e Modelagem de Fluxo de Dados
Um DFD ou Diagrama de Fluxo de Dados (ou Modelo Funcional ou de Processos) uma tcnica grfica que mostra o fluxo
da informao dos dados de maneira a mostrar as transformaes de suas entradas e sadas. O modelo simples e intuitivo,
encapsulando os detalhes e mostrando a estrutura como um todo. Segue um exemplo de DFD (depsitos atravs de elipses):




= composto de
+ e
( ) opcional (pode estar presente ou ausente)
{ } iterao
[ ] seleciona alguma das vrias alternativas
** comentrio
@ identificador (campo chave)
| separa alternativas na construo [ ]
60
necessrio que as entradas e sadas de um fluxo de
dados de um DFD multi-nvel seja consistente entre
todos os nveis. Esta regra s pode ser relaxada quan-
do uma entrada ou sada de um processo for a combi-
nao de dois ou mais fluxos de dados relacionados.
Em resumo, o DFD utilizado para analisar e projetar
as entradas, sadas, processos, armazenamentos e
controles de uma informao do sistema. Existem
DFDs lgicos (fase de anlise) e fsicos (fase de proje-
to), e o ltimo possui de informaes da implementa-
o do sistema.
A Figura 1 mostra o Diagrama de Contexto, onde
todo o sistema representado por um nico crculo
(um nico Processo). Pode ser utilizado para construir
o DFD nvel 0 (Figura 2), com mais detalhes e subdi-
vises. Note a consistncia de entradas e sadas!
Os fluxos de dados so representados por uma seta
(que entra ou sai de um processo).
Os depsitos so representados por duas linhas parale-
las ou elipses, e so os dados armazenados (repouso),
internos ao sistema. Os retngulos so os terminado-
res, que so as entidades externas com as quais o sis-
tema se comunica, pode ser uma pessoa ou sistema.
Ao elaborar um DFD, deve-se evitar processos (crcu-
los) com entradas mas sem sadas, e tambm dar no-
mes significativos aos seus componentes. No ligue
setas entre processos!
Outros nveis podem ser criados para especificar mais
o sistema (subdividir em detalhes). Lembre de Nume-
rar os processos. Tambm evite criar DFDs muito
complexos.









Mtodos Funcionais x Mtodos OO
Os mtodos a serem aplicados, no mbito das metodologias de desenvolvimento, correspondem a conjuntos de atividades que
organizam a execuo de determinadas fases do ciclo de vida do sistema.
Mtodos Funcionais
Os mtodos funcionais baseiam-se fundamentalmente na modelao do fluxo de dados, recomendando, o processo de especi-
ficao, que se inicie o desenvolvimento do sistema pela anlise dos dados. Esta anlise inicia-se com a caracterizao do
ambiente do sistema, bem como das suas entradas e sadas, o que leva definio de um diagrama de contexto do sistema.
As atividades internas ao sistema so decompostas por refinamentos sucessivos de DFDs at que cada atividade acaba por ser
especificada num formato textual.


61
Uma vez que os DFDs no se adequam especificao do comportamento temporal das atividades, podem ser adicionados
STDs (Diagramas de Transio de Estados) aos DFDs para possibilitar a especificao dos estados de todas as atividades.
No que diz respeito concepo, os mtodos funcionais suportam a obteno da arquitetura conceitual do sistema e a imple-
mentao baseada na transformao dos modelos em programas, codificada luz do paradigma da programao estruturada
A abordagem dos mtodos funcionais tem, no entanto, duas grandes desvantagens:
as decises mais crticas relacionadas com a estrutura global do sistema tm que ser efetuadas muito cedo, no pro-
cesso de desenvolvimento, numa altura em que o problema ainda no est bem percebido
uma vez que a decomposio efetuada principalmente no domnio funcional, as estruturas de dados mais importan-
tes tendem a ser globais a todo o sistema, o que coloca problemas significativos fase de manuteno, quando as re-
presentaes dos dados tm que ser alteradas (devido novos requisitos)

Mtodos OO (orientados por objetos)
Os mtodos OO exploram uma abordagem (completamente diferente dos mtodos funcionais) inerentemente baseada no en-
capsulamento da informao e na abstrao dos tipos de dados.
A principal caracterstica dos mtodos OO que a estruturao conceitual das representaes, podendo ser realizada segundo
uma abordagem bottom-up, deve modelar a estrutura do mundo real, no qual se baseia o problema em causa.
Cada objeto uma abstrao de uma entidade do mundo real, com um estado interno e com uma interface (a nica parte do
objeto visvel externamente) que recebe os estmulos do exterior e que responde segundo a dinmica interna do objeto.
Desta forma, uma rede de objetos cooperantes conceitualiza um modelo natural do problema, estando todas as caractersticas
dos objetos reais encapsuladas nos seus modelos computacionais.
Assim, qualquer alterao no ambiente s tem conseqncias locais no interior de objetos particulares, no existindo a propa-
gao para fora das fronteiras dos objetos em causa. Algumas vantagens so:
a fase de concepo permite obter modelos arquiteturais menos dependentes da tecnologia de implementao, sendo
esta baseada no paradigma da programao orientada por objetos
os vrios mtodos orientados a objetos desenvolvidos por Rumbaugh, Jacobson e Booch geraram uma notao ni-
ca, a UML, que pode ser utilizada por qualquer mtodo OO.
A orientao a objetos uma tcnica para modelao de sistemas que relativamente simples de se pensar, pois as pessoas
lidam no dia-a-dia com objetos que interagem entre si.

Anlise Essencial
A anlise essencial comea a especificao de um sistema pela identificao dos eventos que o afetam. Divide-se em:
Modelo Essencial: apresenta o sistema num grau de abstrao independente de restries tecnolgicas.
o Modelo Ambiental: define a fronteira entre o sistema e o resto do mundo. representado pelos diagramas:
Declarao de Objetivos, Diagrama de Contexto, Lista de Eventos (evento orientado a fluxo, temporal e
temporal relativo) e Dicionrio de Dados Preliminar (opcional).
o Modelo Comportamental: define o comportamento das partes internas do sistema necessrio para interagir
com o ambiente. representado pelos diagramas: Diagrama de Fluxo de Dados, Mini-Especificao, Dia-
grama de Transio de Estado e Diagrama Entidade Relacionamento.
Modelo de Implementao: apresenta o sistema num grau de abstrao completamente dependente de restries
tecnolgicas. derivado do modelo essencial. Diz respeito a implementao do sistema. Envolve a construo do
Modelo Lgico de Dados, as caractersticas de processamento das funes / processos e a interface homem-mquina.

A anlise essencial tambm utiliza os mtodos Modelagem de Dados e Modelagem Funcional.
62
As atividades essenciais so todas as tarefas que o sistema teria que executar se fosse implementado com tecnologia perfeita:
Atividades fundamentais: executam tarefas que so parte dos objetivos do sistema.
Atividades custodiais: mantm a memria essencial.
Atividades Essenciais compostas: ambas.

Anlise Essencial x Anlise Estruturada
A Anlise Essencial comea pelo modelo essencial, o que equivale, na Anlise Estruturada, comear diretamente pelo modelo
lgico proposto. A Anlise Estruturada aborda duas perspectivas do sistema - funo e dados - ao passo que a Anlise Essen-
cial aborda trs perspectivas - funo, dados e controle.
Alm disso, na Anlise Estruturada o particionamento feito atravs da abordagem top-down, enquanto na Anlise Essencial,
o particionamento por eventos.
Anlise Estruturada: modelo fsico atual => modelo lgico atual => modelo lgico proposto => modelo fsico proposto
Anlise Essencial: modelo essencial => modelo de implementao

Anlise e projeto orientado a objetos
A identificao de objetos inicia-se ao examinar a declarao do problema ou ao executar uma "anlise gramatical" da narra-
tiva de processamento do sistema a ser construdo. Os objetos podem ser: Entidades Externas (outros sistemas, dispositivos,
pessoas), Coisas (relatrios, displays, cartas, cartazes), Ocorrncias ou eventos (uma transferncia de propriedade ou a con-
cluso de uma srie de movimentos de rob), Papis (gerente, engenheiro, vendedor), Unidades Organizacionais (diviso,
grupo, equipe), Lugares (piso de fbrica ou rea de descarga) ou Estruturas (sensores, veculos de quatro rodas ou compu-
tadores).
Critrios de seleo que se usam ao examinar cada objeto em potencial para incluso no modelo de anlise:
Informao Repetida: o objeto em potencial ser til durante a anlise somente se a informao sobre ele precisar
ser lembrada de forma que o sistema possa funcionar.
Servios Necessrios: o objeto em potencial deve ter um conjunto de operaes identificveis que podem mudar o
valor de seus atributos de alguma forma.
Mltiplos Atributos: um objeto com um nico atributo pode, de fato, ser til durante a fase de projeto, mas prova-
velmente ele ser mais bem representado como um atributo de um outro objeto.
Atributos Comuns: um conjunto de atributos pode ser definido para o objeto em potencial, e esses atributos apli-
cam-se a todas as ocorrncias do objeto.
Operaes Comuns: um conjunto de operaes pode ser definido para o objeto em potencial, e essas operaes a-
plicam-se a todas as ocorrncias do objeto.
Requisitos Essenciais: entidades externas que aparecem no espao problema e produzem ou consomem informa-
es que so essenciais operao de qualquer soluo para o sistema quase sempre sero definidas como objetos no
modelo de requisitos.

Modelagem Dinmica
A modelagem dinmica do sistema se resume s associaes de comunicao (dinmicas) includas no modelo de objetos.
Em OMT, a modelagem das classes isoladamente composta por um Diagrama de Transio de Estados para a classe, e um
fluxograma para cada mtodo. Tambm utiliza os Diagramas de Eventos, como ferramenta de identificao do comportamen-
to dinmico, e o Diagrama de Fluxo de Eventos. O DFD tambm descreve o comportamento do sistema.
A modelagem dinmica se refere a dois aspectos: descrio comportamental, que se preocupa com o fluxo de controle do
sistema (seqncias de procedimentos), e descrio funcional, que se preocupa em descrever os fluxos de dados e suas trans-
formaes. Esto baseados nos conceitos de evento e estado. Em Anlise Orientada a Objetos, eventos representam estmulos
externos, e os estados representam os valores dos objetos.
Engloba os sistemas que reproduzem o comportamento de elementos do mundo real, como simuladores e jogos, sistemas de
tempo real (controle de processos, comunicaes).
63

UML
UML significa Linguagem de Modelagem Unificada (Unified Modeling Language), e um sistema de notao orientada a
objetos criada por Grady Booch, James Rumbaugh e Ivar Jacobson, em conjunto com a Rational Software Corporation, atra-
vs da fuso de diversas tecnologias de modelagens de sistemas.
Atualmente a UML aceita pela OMG (Object Management Group) como o padro para modelagem de programas orienta-
dos a objetos, e sua especificao est disponvel no site da organizao (verso UML 1.5).

Diagrama de casos de uso
Diagramas de caso de uso so utilizados para modelar a funcionalidade do sistema durante a sua operao, atravs de atores e
casos de uso. importante lembrar que este diagrama no adequado para representar o sistema de forma detalhada, pois no
pode descrever os seus mecanismos internos, sendo mais utilizados para facilitar a interao entre os usurios do sistema e os
projetistas.
Atores (actors): so representaes de qualquer entidade que interage com o sistema. No precisa ser necessaria-
mente uma pessoa, podendo ser tambm uma mquina, um outro sistema, etc. Atores no fazem parte do sistema,
apenas representam os papis que o usurio desempenha. Este papel pode ser ativo ou passivo (ator envia ou recebe
informao do sistema).
Casos de uso (use cases): so uma seqncia de aes ou eventos que influenciam o sistema. Cada caso de uso des-
creve uma caracterstica, e o diagrama com todos os casos de uso deve representar todas as situaes possveis de u-
tilizao do sistema. Normalmente os diagramas so acompanhados por uma descrio de cada caso de uso narra-
tivas de texto do caso de uso em que devem ser ressaltados vrios atributos (como nome, atores relacionados, obje-
tivo, fluxo de eventos, pr e ps condies, etc).


O diagrama de classes representa a estrutura interna (atributos e mtodos) e as relaes entre um conjunto de classes. Tais
relaes definiro principalmente a forma em que os objetos sero implementados. Por exemplo, Molde_Injeo e Compo-
nente_Plstico so tipos de Produto e herdam os atributos e mtodos de tal classe.

64


Existem trs perspectivas quando projeta-se diagramas de classes:
Conceitual: A perspectiva conceitual, projeta um diagrama que representa os conceitos no domnio que est sendo
estudado. Estes conceitos sero naturalmente relacionados s classes que vo execut-los, mas freqentemente no
existe um mapeamento direto. Um modelo conceitual deve ser projetado com pouca ou nenhuma preocupao com o
software que poder implement-lo, portanto ele pode ser considerado independente de linguagem. (Cook e Daniels
chamam isso de perspectiva essencial).
Especificao: examinamos o software, estamos analisando as suas interfaces, no a sua implementao. O desen-
volvimento orientado a objeto pe muita nfase na diferena entre interface e implementao, mas isto freqente-
mente negligenciado na prtica porque a noo de classe em uma linguagem OO combina interface com implemen-
tao, o que um erro, pois a chave para uma programao OO eficaz programar para uma interface de classe em
vez de faz-lo para sua implementao. Ouve-se com freqncia a palavra tipo para falar sobre uma interface de
uma classe; um tipo pode ter muitas classes que o implementam e uma classe pode implementar muitos tipos.
Implementao: Nesta viso, realmente, temos classes e estamos pondo implementao s claras. Esta a perspec-
tiva usada com mais freqncia, mas, de vrias formas, a perspectiva de especificao a melhor para ser utilizada.
Como a modelagem de classes utilizada tanto na anlise quanto no projeto das aplicaes orientadas a objeto, o processo de
modelagem compreende passos que envolvem caractersticas tanto de anlise quanto de projeto. Na maioria das vezes, os
passos que envolvem identificar esto relacionados com a anlise, e aqueles que requerem a ao definir dizem respeito
ao projeto. Os passos a serem observados durante a modelagem de classes so os seguintes.

1. Identificar as classes;
2. Identificar os atributos das classes (sem levar em considerao suas visibilidades ou tipos);
3. Analisar os atributos das classes, identificando que alguns deles so na realidade relacionamentos;
4. Identificar os mtodos;
5. Identificar os relacionamentos entre os objetos;
6. Definir a herana;
7. Definir as colaboraes;
8. Definir a agregao.

Agregao x composio
A associao tem duas formas particulares: a agregao e a composio. As duas so muito parecidas, elas relacionam um
objeto composto com suas partes. Por exemplo, a associao entre uma universidade e seus departamentos uma agregao,
a associao entre um carro e suas partes uma composio. A diferena entre os dois que a composio mais ``fsica'':
uma parte no pode pertencer a dois objetos compostos ao mesmo tempo (um motor no pode pertencer a dois carros ao
mesmo tempo), e uma parte no pode existir sem o objeto composto (mas o composto pode ``sobreviver'' s suas partes).
65
A diferena entre os dois no sempre clara. Por exemplo, a associao entre uma casa e os suas paredes uma composio,
mas entre uma pea da casa e um parede, uma agregao (a parede pertence s duas peas e no desaparece com a destrui-
o de uma das duas peas). Na dvida, melhor usar a agregao que menos restrita, ou at uma associao simples.
Agregao e composio aceitam multiplicidade, s do lado das partes para a composio (um carro composto de quatro
rodas) e dos dois lados com a agregao (uma palavra pode pertencer a vrias frases e uma frase possui vrias palavras).
Geralmente, a composio implica uma forma de propagao de algumas propriedades. Por exemplo, quando o objeto com-
posto morrer, as partes morrem tambm (definio da composio), ou quando um carro se mover, as partes se movem tam-
bm. Todas as propriedades no so propagadas, por exemplo, um carro pode ser vermelho e o motor no. O tempo de vida
do membro depende do tempo de vida do objeto composto.
Agregao e composio so representadas com associaes acrescentadas de um losango do lado do objeto composto: lo-
sango vazio para a agregao e losango preto para a composio. A composio pode tambm ser representada com uma
classe com as partes dentro do retngulo.

Diagrama de estados
Representam o comportamento interno de uma classe durante sua vida, mostrando como especficos eventos (mtodos) po-
dem mudar as fases da vida de mesma. Por exemplo, aps uma avaliao, uma Soluo_de_Projeto poder tornar-se Aceita
ou Rejeitada.


Diagrama de seqncia
Capturam e representam a colaborao necessria entre classes, ou Categorias, atravs de seus mtodos. Basicamente, os as-
pectos comportamentais dos objetos so focalizados, mostrando quais mtodos so necessrios para satisfazer um Use Case
especfico. O Use Case avalie_Solues_Projeto mostra como as categorias Funes e Solues_de_Projeto colaboram
para atender uma funcionalidade especfica do sistema.


66
Diagrama de atividades
Representa o conjunto de passos a serem executados por um mtodo, mostrando como uma operao pode(ria) ser implemen-
tada. So compostos por atividades (retngulos arredondados), transies (setas), barras de sincronizao, decises (losango)
e marcadores de incio e fim.


Diagrama de colaborao/comunicao
O diagrama de colaborao, que a partir da UML 2.0 passou a se chamar diagrama de comunicao, possui uma funo simi-
lar ao diagrama de seqncia. Mas ao contrrio deste, o seu foco no no tempo, e sim na organizao dos objetos. Por isso,
esse diagrama mostra explicitamente as conexes entre os objetos (o que o de seqncia no faz), enquanto ele deve acrescen-
tar nmeros de seqncia s mensagens para indicar a ordem de chamada. Outra diferena que esse diagrama NO mostra
explicitamente o retorno das chamadas.



67

Diagrama de implementao
O diagrama de implantao (ou distribuio) usado para sistema distribudos. Ele permite apresentar a topologia de uma
rede de "mquinas'' e qual processo (um componente executvel) cada "mquina'' vai rodar.
As "maquinas'' so chamadas de ns. Um n apresenta uma fonte computacional, sendo normalmente um processador com
alguma memria. Um n representado por um cubo. Alguns de seus objetivos modelar um sistema embarcado, sistemas
distribudos ou sistemas cliente / servidor.



Diagrama de componentes
O diagrama de componentes mostra a organizao entre arquivos de cdigo fonte, bibliotecas, tabelas de banco de dados, etc.
A relao a mais usada a de dependncia, mostrando como um arquivo de cdigo fonte depende de um outro que ele inclu,
o como um executvel depende de uma biblioteca por exemplo.
Um componente um parte fsica do sistema. Muitas vezes um componente mostra um arquivo especfico do sistema. A
UML reconhece: executveis (na figura), bibliotecas (ver diagrama de implementao), tabelas (uma tabela de um banco),
documentos (textos livres, ajuda) e arquivos (scripts).
68


Utilizao dos diagramas
Os Diagramas de Casos de Uso so utilizados para modelar o contexto (os requisitos) do sistema.
Os Diagramas de Classes modelam as classes, interfaces e seus relacionamentos. Modelam os aspectos estticos do sistema.
J os Diagramas de Objetos mostram o conjunto de objetos e seus relacionamentos, existentes em um determinado momento
Os Diagramas de Interao mostram as interaes existentes entre um conjunto de objetos e seus relacionamentos, incluin-
do as mensagens trocadas. Podem ser de dois tipos: Seqncia: enfatiza a ordenao das mensagens ao longo do tempo e
Colaborao: enfatiza a organizao dos objetos que participam de uma interao. Ambos descrevem o comportamento de
VRIOS objetos em um NICO caso de uso.
Os Diagramas de Estado descrevem um comportamento de UM objeto, atravs de VRIOS de casos de uso. Seu compor-
tamento caracterizado pela sua resposta a eventos externos ao seu contexto.
Os Diagramas de Atividades apresentam uma seqncia geral de aes para VRIOS objetos e casos de uso. Mostra o fluxo
de execuo das atividades, os aspectos dinmicos do sistema
O Diagrama de Componentes modela os aspectos fsicos do sistema, mostra a organizao e dependncias entre um conjun-
to de componentes.
O Diagrama de Implantao mostra a configurao do sistema (unidades de processamento e os componentes que rodam
nele) em tempo de execuo.
Na verso UML 2.0 existem tambm os Diagramas de Viso Geral e o Diagrama Temporal. O primeiro uma variao do
diagrama de atividades que mostra de uma forma geral o fluxo de controle dentro de um sistema ou processo de negcios.
Cada n ou atividade dentro do diagrama pode representar outro diagrama de interao. J o Diagrama Temporal mostra a
mudana de estado de um objeto numa passagem de tempo, o que muito til para sistemas de tempo real.
A arquitetura de sistemas em camadas, aplicada aos sistemas desenvolvidos sobre a orientao a objetos, determina a dis-
tribuio das classes por trs camadas.
A primeira camada identificada como camada de apresentao abrange as classes que so responsveis pela intera-
o dos usurios com o sistema.
A segunda camada identificada como camada de negcios controla as regras de negcio da aplicao. As classes de
negcio armazenam os requisitos que determinam como calcular, como processar, o que persistir e o que recuperar.
A terceira camada identificada como camada de persistncia controla a persistncia dos dados. Os dados vivem
temporariamente nas instncias da segunda camada, mas devem ser mantidos ao trmino da aplicao. Para isso,
necessrio armazen-lo em um meio fsico permanente. Assim, esta camada trata como os dados so persistidos em
simples arquivos ou em bancos de dados.
69

Padres de Projetos (Design Patterns)
Patterns so solues genricas e reutilizveis, aplicveis em classes de problemas bem conhecidos. Padres so definidos
como a soluo de problemas recorrentes. Qualquer linguagem orientada a objetos pode aplicar um padro de desenvolvi-
mento a uma aplicao, permitindo a comunicao do seu problema, estratgias e boas prticas de programao, alm da so-
luo para o problema proposto.
Estas solues foram experimentadas por vrios desenvolvedores experientes, e por isso podem ser reusadas de forma confi-
vel. Para identificar um padro, necessrio detectar o problema que ocorre com um projeto, dadas as suas caractersticas. Os
padres costumam incluir implementaes de alto nvel, recomendadas para compor uma determinada soluo.
Estrutura do Pattern: Nome, Problema, Soluo e Conseqncias. Organizados pelo seu escopo e propsito:
Abstract Factory: Prov uma interface para criao de famlias de objetos relacionados ou interdependentes. Remove a de-
pendncia entre o cliente, que usa os objetos, e a classe dos objetos produzidos.
Adapter: Converte a interface de uma classe em outra, esperada pelo cliente. O Adapter permite que classes que antes no
poderiam trabalhar juntas, por incompatibilidade de interfaces, possam agora faz-lo.
Bridge: Separa uma abstrao de sua implementao, de modo que ambas possam variar independentemente.
Builder: Prov uma interface genrica para a construo incremental de agregaes. Um Builder esconde os detalhes de co-
mo os componentes so criados, representados e compostos.
Chain of Responsibility: Encadeia os objetos receptores e transporta a mensagem atravs da corrente at que um dos objetos
a responda. Assim, separa (prov loose coupling) objetos transmissores dos receptores, dando a chance de mais de um objeto
poder tratar a mensagem.
Command: Encapsula uma mensagem como um objeto, de modo que se possa parametrizar clientes com diferentes mensa-
gens. Separa, ento, o criador da mensagem do executor da mesma.
Composite: Compe objetos em rvores de agregao (relacionamento parte-todo). O Composite permite que objetos agre-
gados sejam tratados como um nico objeto.
Decorator: Anexa responsabilidades adicionais a um objeto dinamicamente. Prov uma alternativa flexvel para extenso de
funcionalidade, sem ter que usar Herana.
Facade: Prov uma interface unificada para um conjunto de interfaces em um subsistema. O Facade define uma interface alto
nvel para facilitar o uso deste subsistema.
Factory Method: Define uma interface para criao de um objeto, permitindo que as suas subclasses decidam qual classe
instanciar. O Factory Method deixa a responsabilidade de instanciao para as subclasses.
Flyweight: Usa o compartilhamento para dar suporte eficiente a um grande nmero de objetos com alto nvel de granularida-
de.
Interpreter: Usado para definio de linguagem. Define representaes para gramticas e abstraes para anlise sinttica.
Iterator: Prov um modo de acesso a elementos de um agregado de objetos, seqencialmente, sem exposio de estruturas
internas.
Mediator: Desacopla e gerencia as colaboraes entre um grupo de objetos. Define um objeto que encapsula as interaes
dentre desse grupo.
Memento: Captura e externaliza o estado interno de um objeto (captura um "snapshot"). O Memento no viola o encapsula-
mento.
Observer: Prov sincronizao, coordenao e consistncia entre objetos relacionados.
Prototype: Especifica os tipos de objetos a serem criados num sistema, usando uma instncia prottipo. Cria novos objetos
copiando este prottipo.
Proxy: Prov Design para um controlador de acesso a um objeto.
Singleton: Assegura que uma classe tenha apenas uma instncia e prov um ponto global de acesso a ela.
State: Deixa um objeto mudar seu comportamento quando seu estado interno muda, mudando, efetivamente, a classe do obje-
to.
Strategy: Define uma famlia de algoritmos, encapsula cada um deles, e torna a escolha de qual usar flexvel. O Strategy de-
sacopla os algoritmos dos clientes que os usa.
70
Template Method: Define o esqueleto de um algoritmo em uma operao. O Template Method permite que subclasses com-
ponham o algoritmo e tenham a possibilidade de redefinir certos passos a serem tomados no processo, sem contudo mud-lo.
Visitor: Representa uma operao a ser realizada sobre elementos da estrutura de um objeto. O Visitor permite que se crie
um nova operao sem que se mude a classe dos elementos sobre as quais ela opera.

Uso/conceitos de ferramentas de suporte anlise e projetos orientados a objetos
De um ambiente de desenvolvimento de software (ADS) espera-se mais do apoio implementao, como ocorre com um
ambiente de desenvolvimento de programas. Espera-se apoio aos demais ciclos de vida do software, a partir de editores diri-
gidos sintaxe (inclusive grficos), mecanismos de validao, entre outros.
Este tipo de ambiente de desenvolvimento de software recebe a denominao genrica CASE (Computer-Aided Software En-
gineering), pois apia a evoluo do software em cada etapa do seu ciclo de vida.
Em linhas gerais, ferramentas CASE apiam a execuo de atividades do desenvolvimento do software de forma automatiza-
da. Em alguns casos, implementam um ambiente relativamente refinado no qual vrias atividades de especificao ou codifi-
cao so apoiadas por recursos computacionais.
Dependendo da atividade suportada podem ser classificados em Lower CASE, provendo suporte codificao, teste, depura-
o e manuteno do cdigo ou Upper CASE, suportando tarefas de anlise e projeto de sistemas.
Algumas ferramentas CASE tpicas so geradores de cdigo, editores UML, ferramentas de Refatorao (refactoring) e fer-
ramentas de gerenciamento de configurao, como softwares de controle de verses.
Por exemplo, ao se utilizar ferramentas CASE para um produto de software de banco de dados, deve-se:
Modelar processos de negcio e do mundo real, e o fluxo de dados
Desenvolver Modelos de Dados na forma de diagramas E-R
Desenvolver a descrio dos processos e funes
Produzir scripts SQL de criao de bancos e Stored Procedures
Algumas ferramentas CASE conhecidas so:
ArgoUML
Eclipse (com plugins)
Oracle Designer
Rational Rose da IBM
Visual Paradigm for UML




71
Engenharia de Software

Princpios de Engenharia de Software
A Engenharia de Software (ES) surgiu em meados dos anos 70 numa tentativa de contornar a crise do software e dar um tra-
tamento mais sistemtico e controlado ao desenvolvimento de sistemas de software complexos.
A engenharia de software envolve o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar,
implementar e manter sistemas de software, avaliando e garantido suas qualidades. Alm disto, a engenharia de software deve
oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento
A tarefa fundamental na execuo de um processo de planejamento definir e agrupar os pacotes de trabalho, com as respec-
tivas entregas de cada pacote. Um Baseline (ou linha bsica) o marco de referncia no desenvolvimento, que se caracteriza
pela entrega e aprovao de um ou mais itens de configurao.

Engenharia de sistemas
A engenharia de sistemas preocupa-se com os aspectos do desenvolvimento de sistemas baseados em computador (hardware,
software, engenharia de processos). A engenharia de software faz parte deste processo.
Os engenheiros de sistema esto envolvidos na especificao, projeto arquitetural, integrao e desenvolvimento de sistemas
de informao.

Ciclo de Vida
O desenvolvimento de um produto de software foi modelado de acordo com a engenharia convencional. Para PRESSMAN, o
ciclo de vida do software dividido em seis partes, descritas a seguir:
Avaliao: a fase correspondente engenharia de sistemas, iniciando com os requisitos.
Anlise: Processo de coleta dos requisitos intensificado e concentrado no software.
Projeto: Processo de mltiplos passos, concentra-se na estrutura de dados, arquitetura de software, detalhes proce-
dimentais e caracterizao da interface. A qualidade pode ser avaliada nesta etapa.
Implementao: Etapa de codificao que transforma o projeto em uma forma computacional.
Teste: Concentra-se em testar os aspectos lgicos do sistema, e tambm nos aspectos funcionais, descobrindo erros e
que os resultados reais concordem com os resultados exigidos pelo sistema.
Manuteno: Responsvel por adaptar e evoluir o software de acordo com exigncias futuras.
O ciclo de qualidade PDCA (Plan, Do, Check, Act) pode ser relacionado com o ciclo do desenvolvimento, sendo a etapa Plan
equivalente s trs primeiras (Avaliao, Anlise e Projeto), e as demais em seguida.

Processos de Software
Um processo de software um conjunto de prticas, estruturas organizacionais, tecnologias, procedimentos e artefatos que
so necessrios para conceber, desenvolver, implantar e manter um produto de software.
Enxergar o desenvolvimento de um software como um processo ajuda a identificar as diferentes dimenses da tarefa (tecno-
logia, organizao, marketing, economia), evitar problemas e estabelecer prticas efetivas.
As atividades genricas em todos os processos de software so:
Especificao: O que o sistema deve fazer e as restries aplicadas ao seu desenvolvimento.
Desenvolvimento: A produo do sistema de software.
Validao: Verifica se o sistema atende s especificaes do cliente.
Evoluo: Modificar o software em resposta a necessidades de alterao.
72

Anlise
Na fase de anlise, tambm denominada anlise de requisitos, so estabelecidos os requisitos do sistema a ser desenvolvido.
Nesta fase, o engenheiro de software necessita compreender o domnio do problema no qual est trabalhando. Os requisitos e
a modelagem conceitual do sistema so documentados e revisados.
A anlise de requisitos comea ao se reconhecer que um problema necessita da tecnologia de informao como soluo ou ao
surgir uma idia de um novo negcio ou de um novo sistema na empresa. Esta fase concluda ao se ter uma descrio com-
pleta do comportamento do software a ser construdo, documentado na Especificao de Requisitos. Aqui so feitas: a anlise
do problema, descrio do produto e avaliao da especificao.

Projeto (design) e Codificao
O projeto do software , na realidade, um processo de mltiplos passos que refora quatro atributos importantes: estrutura de
dados, arquitetura do software, detalhe procedural e projeto da interface. A fase de projeto tem por objetivo traduzir os requi-
sitos definidos em uma representao de software com detalhes suficientes para que possa ser implementado. Como os requi-
sitos, o projeto documentado (Especificao de Projeto), sendo este realizado com base na Especificao de Requisitos.
Pode-se verificar que quanto mais refinado (detalhado) for a fase de projeto, mais clara ser a fase de construo.
Na fase de construo, os programas so codificados, as bases de dados criadas e os mdulos do software integrados.

Verificao x Validao
Uma vez que o cdigo foi gerado, segue-se a fase de avaliao da qualidade do software. Esta avaliao deve ser realizada
atravs de certificao utilizando inspeo, walkthrough, prova formal ou testes.
As inspees formais so uma tcnica de reviso sistemtica do software ou de alguns de seus componentes, executada, sis-
tematicamente, ao final de cada fase do projeto, com o objetivo nico de encontrar erros. Todo o material gerado lido, os
erros anotados e uma estatstica dos erros encontrados mantida, para fins de posterior estudo da eficcia do procedimento.
uma tcnica preventiva, barata, que depende da experincia do inspetor e pouco eficaz para fatores operacionais.
Verificao: Estamos construindo certo o produto?, ou seja, o software deve estar de acordo com a sua especificao.
Validao: Estamos construindo o produto certo?, ou seja, o software deve atender s necessidades dos usurios.

Testes
Os testes concentram-se em validar os procedimentos lgicos internos do programa, garantindo que todos os comandos foram
testados e que o comportamento funcional externo do sistema produz os resultados esperados para determinadas entradas de
dados. Pressman afirma que a atividade de teste de software um elemento crtico da garantia de qualidade de software e
representa a ltima reviso de especificao, projeto e codificao. A inteno da realizao de testes achar erros, e neces-
srio que estes sejam planejados com seus objetivos claramente definidos. Na anlise dos resultados deve-se procurar identi-
ficar a falha que causou o erro evidenciado pelo teste. Testar exaustivamente um software nem sempre possvel, por isso os
testes no podem assegurar a correo total de um sistema. Entretanto, a utilizao de testes combinados com algumas tcni-
cas de controle da qualidade contribui para se obter um nvel aceitvel de confiabilidade.
Algumas dificuldades que podem ser encontradas durante o ciclo dos testes so:
Deteco de falhas se d atravs da ocorrncia de defeitos
necessria a presena de uma especificao completa e no ambgua
Falhas nos requisitos podem no ser detectadas
Certas tarefas de testes no podem ser automatizadas, dificultando os testes exaustivos
Veredictos de testes dependem das sadas esperadas, mas produzi-las pode ser difcil ou impossvel
Note que os testes so apenas uma das maneiras de encontrar erros no sistema. Inspees e revises tcnicas tambm devem
ser executadas continuamente aps a codificao com o objetivo de monitorar a qualidade.
A atividade de teste no prova a ausncia de erros, apenas a existncia dos mesmos;
73
Bons casos de teste so aqueles que encontram falhas no sistema at ento no descobertas;
Bons casos de teste so projetados levando em conta os requisitos do projeto;
Um critrio utilizado para determinao do esforo a ser gasto na atividade de teste de software verificar qual o
grau de severidade das conseqncias advindas do seu mau funcionamento;
A probabilidade de encontrar um erro numa determinada parte do sistema proporcional ao nmero de erros j en-
contrados nesta parte;

Garantia da qualidade
As atividades de garantia de qualidade esto focadas na utilizao de processos, para gerenciar, produzir e entregar a soluo,
podendo ser realizadas pelo Sistema de Informao Gerencial, pelo patrocinador do projeto ou por uma terceira pessoa que
revise estas atividades.
A Garantia da Qualidade no se refere diretamente as deliverables especficas. Esta refere-se ao processo usado na criao
das deliverables. Em geral a atividade de garantia da qualidade esta focada no processo de gerenciamento e de entrega da
soluo, e poder ser realizada por um gestor, por um cliente ou por uma terceira parte revisora. Por exemplo, um revisor
independente de projeto talvez no esteja habilitado em dizer se o contedo de uma deliverable em particular aceitvel ou
no. Entretanto, eles devero estar habilitados a dizer, baseado no processo utilizado para criao da deliverable, se est pare-
ce ser aceitvel ou no.
O Controle de Qualidade uma atividade separada da garantia de qualidade, mas que tambm faz parte do gerenciamento
da qualidade. As atividades de controle de qualidade so realizadas continuamente no andamento do projeto para verificar se
o gerenciamento do projeto e as deliverables so de alta qualidade.

Manuteno
Alm da fase de Desenvolvimento e da Validao, o terceiro processo de desenvolvimento de software envolve a manuteno
do sistema, onde o software sofre correes, adaptaes e ampliaes para corrigir erros encontrados aps a entrega do produ-
to, atender os novos requisitos do usurio e mudanas na tecnologia.
O gerenciamento de risco nesta fase fundamental, dado que 70% dos custos de um sistema de software correspondem ma-
nuteno de um sistema. Por isso importante controlar a manutenibilidade durante o desenvolvimento, atravs de mtricas e
modelos. Os tipos de aes tomadas durante a fase de manuteno so:
Preventiva: previne falhas e defeitos que no geraram falhas, implementada para eliminar as causas de uma poss-
vel no-conformidade, defeito ou outra situao indesejvel, a fim de prevenir sua ocorrncia.
Corretiva: problemas decorrentes de defeitos, implementada para eliminar as causas de uma no-conformidade,
de um defeito ou de outra situao indesejvel existente, a fim de prevenir sua repetio.
Adaptativa: aps mudana no ambiente, software ou hardware
Perfectiva: melhorar algum aspecto do sistema (ex: refactoring)

Modelos de ciclo de vida
Modelos de ciclo de vida descrevem as etapas do processo de desenvolvimento de sistemas e as atividades a serem realizadas
em cada etapa. A definio dessas etapas
e atividades possibilita prover marcos e
pontos de controle para avaliao da
qualidade e gerncia do projeto.

Modelo Clssico ou Cascata
A primeira proposta deu origem ao mo-
delo tradicional ou cascata. Nesse mode-
lo as fases so executadas sistematica-
mente em seqncia.
Anlise
Projeto
Construo
Avaliao
Manuteno

74
O sistema entregue ao usurio aps se chegar a um resultado satisfatrio na fase de avaliao, com um certo grau de confi-
ana. claro que o sistema ainda passar por alteraes, devido principalmente a erros observados pelo usurio, ou por mu-
danas necessrias para melhor adaptao ao ambiente do usurio, ou por problemas de desempenho.
Existem diversas variaes deste modelo, e uma das suas caractersticas esgotar cada uma das fases antes de passar para a
fase seguinte, o que evita desperdcios de esforos, facilita o planejamento (e cronogramas). As desvantagens: a dificuldade
em acomodar alteraes aps o seu incio, e a demora para comear a construo.

Modelo orientado a reuso
Reutilizao de software o processo de desenvolvimento de software cujo objetivo utilizar a experincia adquirida e os
produtos obtidos anteriormente, para o desenvolvimento de novos produtos, podendo ser aplicada nas fases de Anlise, Proje-
to, Construo ou Avaliao. Assim sendo, a reutilizao utiliza: cdigo j testado anteriormente, projetos validados, especi-
ficaes de requisitos, e / ou planos para testes.
A expresso "reutilizao de software" indica uma atividade particular no desenvolvimento do software. O modelo bem
parecido com o tradicional, mas conta com um repositrio, que guarda as informaes adquiridas em fases anteriores.



Modelo Evolucionrio ou Prototipagem
O modelo de ciclo de vida evolucionrio surgiu propondo um desenvolvimento que expandisse o sistema gradativamente,
permitindo que se obtivessem modelos do comportamento do software antecipadamente, os denominados prottipos. A proto-
tipagem uma forma de desenvolvimento incremental e contm quatro tipos diferentes: ilustrativo (telas), simulado (acesso
ao banco de dados simulado), funcional (subconjunto limitado) e evolucionrio (aumenta gradualmente). Os trs primeiros
tipos so construdos para se atingir objetivos propostos a
priori, sendo considerados descartveis. Ao final o prottipo
se tornar um produto operacional.
Tal como o processo de desenvolvimento convencional de
software (modelo cascata), a prototipagem se inicia com a
etapa de definio dos requisitos. Todos os objetivos a serem
atingidos pelo software so definidos, sendo identificadas as
reas que merecem uma definio mais refinada.
A partir dos requisitos levantados na fase de definio, um
projeto inicial construdo e apresentado ao usurio, refle-
tindo os aspectos visveis do software. Este projeto rpido
leva construo de um prottipo.
Um benefcio que o desenvolvedor do software pode com-
preender melhor o domnio sobre o qual est trabalhando, a
partir das questes levantadas pelo usurio. Alm disso par-
tes do prottipo podem ser aproveitadas. Porm o custo
normalmente mais alto, e a construo do prottipo acaba
atrasando o incio da implementao final.


Tcnicas de quarta gerao
No so um modelo especificamente dito, mas um termo amplo, cujo significado abrange ferramentas que possibilitam o de-
senvolvedor de software a especificar determinadas caractersticas do software num nvel elevado, e o cdigo executvel seja
gerado a partir dessas especificaes automaticamente.
Algumas caractersticas: Linguagens no procedimentais de acesso a Bancos de Dados, gerao de relatrios, definio e
manipulao de telas, capacidade grfica de alto nvel, gerao de cdigo, etc.
Defensores reivindicam uma drstica reduo no tempo de desenvolvimento de software em funo de uma maior produtivi-
dade. Opositores afirmam que as ferramentas no so to mais fceis de usar do que ferramentas mais convencionais e que o

75
cdigo gerado ineficiente. O domnio de aplicaes para as quais estas tcnicas esto mais desenvolvidas so as aplicaes
comerciais, geralmente ligadas a grandes bancos de dados.
Existe um certo ganho de tempo de desenvolvimento das aplicaes, especialmente as pequenas.

Modelo em Espiral
O modelo em espiral proposto por Boehm fornece uma estrutura de trabalho para a produo de software baseada em proces-
so e nveis de risco permitindo a anlise dos riscos em vrias etapas do desenvolvimento. Esse modelo pode ser considerado
um meta-modelo pois pode abranger diferentes outros modelos, desde o modelo cascata at os vrios tipos de prottipos.
um modelo cclico.
A anlise dos modelos de ciclo de vida pode ser feita considerando-se a identificao monoltica ou incremental do processo
de desenvolvimento. Na estrutura de trabalho monoltica, os detalhes de cada fase so completados em sua totalidade, antes
do incio da etapa seguinte. Sendo assim, o comportamento do software s pode ser avaliado no final do desenvolvimento. Na
estrutura incremental, os detalhes podem ser retardados com o benefcio de se produzir antecipadamente um prottipo mos-
trando o funcionamento do produto.
As vantagens: o foco nas opes de reuso e eliminao precoce de erros (qualidade desde o incio), alm de integrar a fase de
desenvolvimento e manuteno. Alguns dos problemas a dificuldade de controlar todo o processo, requerendo experincia
em avaliao de risco, e precisa de refinamento para uso geral.























RAD - Desenvolvimento rpido de aplicaes
A tcnica de desenvolvimento rpido de aplicaes (RAD) um bom ponto de partida para a elaborao do projeto de inter-
faces. Usando de forma embutida a orientao a objetos, essa tcnica fundamenta-se nos seguintes conceitos:

76
projeto centrado no usurio
prototipao rpida
particionamento de processos em clientes e servidores
modelagem de objetos
O Delphi, por exemplo, conta com vrias ferramentas RAD que auxiliam o desenvolvimento, para a reduo do tempo de
desenvolvimento e manutenes improvveis. Adicionando, uma arquitetura aonde possvel a separao da GUI (Graphic
Unit Interface), das regras de negcio lgicas e do desenho do banco de dados.
O desenho do banco de dados, a construo das metodologias de negcio e o desenho e a criao das janelas de entrada so
efetivados dentro da aplicao. O desenvolvimento, ento paralelamente, resultar em uma maior rapidez. O processo de co-
dificao reduz drasticamente ao herdas as janelas de entrada, mdulos, etc.

Testes
De acordo com [PRESSMAN], a atividade de teste pode ser conduzida em quatro fases:
Teste de Unidade: concentra-se no esforo de verificao da menor unidade de projeto de software chamado de u-
nidade ou mdulo.
Teste de Integrao: uma tcnica sistemtica para a construo da estrutura de programa, ao mesmo tempo sendo
realizados testes para descobrir erros associados a interfaces.
Teste de Validao: o software est completamente montado como um pacote, e a validao definida como bem-
sucedida quando ele funciona de uma maneira razoavelmente esperada pelo cliente.
Teste de Sistema: uma srie de diferentes testes, cujo principal propsito pr o sistema completamente prova,
verificados quanto sua integrao adequada e funes atribudas.
Nenhuma das tcnicas de teste completa, ou seja, suficiente para garantir a qualidade da atividade de teste.

Tipos de Testes
Podemos classificar os mtodos de teste de acordo com suas caractersticas bsicas:
Testes estticos ou testes humanos: no so feitos atravs da execuo real do programa, mas sim atravs da exe-
cuo conceitual do mesmo. Mtodos classificados como estticos so o de walkthrough, inspees e peer rating.
So utilizados principalmente para validar as primeiras etapas do projeto.
Testes dinmicos: seguem o modelo tradicional de teste de programa, no qual o programa executado com alguns
casos de teste e os resultados so examinados para verificar se o programa operou de acordo com o esperado. Usados
na validao do cdigo em mdulos e na integrao do sistema.
Testes funcionais: o teste exaustivo, no entanto o domnio de um programa muito grande e so criadas formas
de derivar um conjunto de dados de teste representativo que consiga exercitar completamente a estrutura do sistema.
So mtodos de testes funcionais ou de caixa preta, o particionamento de equivalncia, a anlise de valor limite, a
tcnica de grafo de causa-efeito e testes de comparao.
Testes estruturais: diferentemente dos testes funcionais, que se preocupam com a funo que o programa desempe-
nha sem se preocupar com como a funo foi implementada, o teste estrutural enfoca a implementao e a estrutura
da funo. Geralmente usado durante a fase de codificao. A inteno encontrar dados de teste que tero cobertu-
ra de todas estruturas presentes na representao formal.
Testes de unidade: concentra-se no esforo de verificao da menor unidade de projeto de software, o mdulo. Este
teste baseia-se sempre na caixa branca, e so verificados: a interface com o mdulo (fluxo de informaes de dentro
para fora), estrutura de dados local, condies de limite, todos os caminhos independentes so executados pelo me-
nos uma vez, e caminhos de tratamento de erro.
Testes de integrao: uma tcnica sistemtica para a construo da estrutura de programa, que procura descobrir
erros relacionados interface. A partir dos mdulos testados no nvel de unidade, construda a estrutura do pro-
grama que foi determinada pelo projeto. A integrao pode ser incremental (top-down ou bottom-up) ou no-
incremental.
77
Testes de validao: pode ser considerado bem sucedido quando o software funciona da maneira esperada pelo cli-
ente. Verifica-se se o produto certo foi construdo, seguindo a especificao de requisitos do software. A validao
do software, na fase de testes, realizada por meio de uma srie de testes de caixa preta que demonstram a confor-
midade com os requisitos.
Testes alfa e beta: so os testes de aceitao, feitos pelo usurio, que dificilmente opera o sistema da forma previs-
ta, e visam descobrir erros cumulativos que poderiam deteriorar o sistema no decorrer do tempo. Os testes alfa so
conduzidos em ambiente controlado (do desenvolvedor). J o teste beta realizado em uma ou mais instalaes do
cliente pelo usurio final do software.
Teste de segurana: tenta verificar se todos os mecanismos de proteo embutidos em um sistema o protegero de
acessos indevidos. O analista pode tentar adquirir senhas via contatos externos, atacar o sistema com software cus-
tomizado, desarmar o sistema negando servio a outros, etc...
Testes de estresse: feito para confrontar o sistema com situaes anormais. O teste de estresse executa o sistema de
forma que exige recursos em quantidade, freqncia ou volume anormais.
Teste de desempenho: idealizado para testar o desempenho de runtime do software dentro do contexto de um sis-
tema integrado. Algumas vezes so combinados com os de estresse utilizando instrumentao de hardware e de
software (para medio dos recursos com ciclo de processador).

Walkthough
Os objetivos do walkthrough so descobrir erros de funo, lgica ou implementao, e verificar os requisitos, uniformidade
e facilidade de administrao do software. uma tcnica manual, executada em reunies formais com um moderador, e inclui
os desenvolvedores. feita uma leitura do produto, e algumas simulaes so realizadas. O propsito da tcnica de walkt-
hrough estimular a discusso.

Tcnica de prova de corretitude
Em um nvel informal, ela reduz o nmero de passos envolvidos em um walkthrough. Em um nvel mais formal, a lgica ma-
temtica aplicada para dar suporte ao problema de provar que um programa est de acordo com sua especificao. A tcnica
consiste em validar a consistncia de uma sada de acordo com o programa e a entrada.
Quando linguagens de programao so definidas formalmente (sintaxe e semntica formal), pode-se provar matematicamen-
te que um programa est correto em relao especificao formal. Ex.:
{x = 5} Especificao: condio inicial
x: = x + 1
{x = 6} Especificao: condio final

Simulaes
a utilizao de um modelo executvel para representar o comportamento de um objeto. Esta ferramenta de testes bastante
til, contudo mais empregada em sistemas de tempo real onde a interface com o mundo real crtica e a integrao com o
hardware do sistema fundamental.

Testes de caixa preta
Tambm conhecidos como Testes Funcionais, pois os mtodos de teste de caixa preta concentram-se nos requisitos funcio-
nais do software. Ele procura descobrir funes incorretas ou ausentes, erros de interface ou estruturas de dados, erros de de-
sempenho e de inicializao e trmino. Os testes so gerados atravs do estudo de suas entradas e sadas.
Particionamento de Equivalncia (ou Domnio): um mtodo que divide o domnio de entrada de um programa
em classes de dados a partir das quais os casos de teste podem ser derivados:
o Inicialmente determina-se entre entradas vlidas (pertencentes ao domnio) e invlidas para verificar como
o sistema comporta-se com as ltimas.
78
o Para o domnio de dados de entradas vlidas devem ser identificadas parties (classes) para os quais o sis-
tema tenha comportamento semelhante.
o O particionamento de equivalncia procura definir um caso de teste que descubra classes de erros, assim
reduzindo o nmero total de casos de teste que devem ser desenvolvidos.
Anlise de Valor Limite: uma tcnica de projeto de casos de teste que serve como complemento para a tcnica de
particionamento de classes. Ao invs de selecionar qualquer valor de uma classe de equivalncia, a anlise do valor
limite leva seleo de casos de teste nas extremidades da classe. Em vez de se concentrar somente nas condies
de entrada, ela deriva os casos de teste tambm do domnio de sada.
Grafos de Causa-Efeito: uma tcnica de projeto de casos de teste que oferece uma representao concisa das con-
dies lgicas e das aes correspondentes. A tcnica segue quatro passos:
o As causas (condies de entrada) e efeitos (aes) so relacionados para um mdulo e um identificador
atribudo a cada um.
o Em seguida gerado um grafo de causa-efeito.
o O grafo convertido em uma tabela de deciso.
o As regras da tabela so convertidos em casos de teste.

Testes de caixa branca
O teste de caixa branca ou Teste Estrutural visa conhecer o funcionamento interno de um produto e verificar que a sua ope-
rao tem um desempenho de acordo com as especificaes. Razes para a sua execuo so que erros lgicos e pressuposi-
es incorretas ocorrem em casos especiais, e tambm que erros tipogrficos so aleatrios, e ocorrem ao converter cdigo da
fase de projeto.
Teste do Caminho Bsico: possibilita que o projetista do caso de teste derive uma medida da complexidade lgica
de um projeto procedimental e um conjunto bsico de caminhos de execuo. Os casos de teste derivados para exer-
citarem o conjunto bsico tm a garantia de executar cada instruo do programa pelo menos uma vez durante a ati-
vidade de teste. Para determinar esses caminhos, uma tcnica bastante utilizada a Complexidade Ciclomtica:
o Complexidade Ciclomtica: uma medida definida pelos engenheiros de software que tentam captar a
complexidade de cada rotina. A complexidade ciclomtica pode ser calculada das seguinte formas:
Seja n o nmero total de predicados lgicos (comparaes, expresses booleanas) que aparecem
em uma rotina. A complexidade dada ento por n+2.
[SEI] Seja o programa um grafo de fluxo onde cada n representa uma deciso e cada arco um
caminho possvel. A complexidade dada por: nmero de arcos nmero de ns + 2.
Teste de condio: um mtodo de projeto de casos de teste que pe prova as condies lgicas contidas num
mdulo de programa. Este mtodo concentra-se em testar cada condio do programa e prope-se a descobrir as se-
guintes classes de erros: erros de operadores booleanos, relacionais ou aritmticos, quanto sua corretitude, falta ou
excesso.
Teste de fluxo de dados: esse mtodo seleciona caminhos de teste de um programa de acordo com as localizaes
das definies e usos de variveis no programa. Ele til para selecionar caminhos de teste de um programa que
contenha instrues de laos e if aninhadas.
Teste de laos: Os laos so amplamente utilizados na estrutura dos programas. Raros so os programas que no uti-
lizam a estrutura de loop para controle de execuo. As condies de teste so: pular o lao inteiramente, realizar n
passagens e verificao de laos aninhados.

Engenharia de requisitos
A engenharia de requisitos de software uma atividade que engloba a descoberta, documentao e a manuteno do conjunto
de requisitos de um sistema de software. A gerncia de requisitos tem por finalidade estabelecer e manter um acordo com o
cliente com relao aos requisitos a serem observados no projeto de software. Em particular, a gerncia de requisitos controla
a evoluo dos requisitos de um sistema, seja por constatao de novas necessidades ou de deficincias nos requisitos regis-
trados, at o momento.

79
Requisitos
Crosby diz que qualidade a "conformidade com os requisitos", logo v-se a importncia da Engenharia de requisitos. Defi-
ne-se por requisito uma condio ou capacitao necessria a um componente do sistema (ou o prprio sistema) precisa aten-
der, para satisfazer s necessidades do usurio, padro, especificao ou outro.
Os requisitos podem ser classificados como funcionais ou no-funcionais, conforme explicado abaixo:
Funcionais: dizem respeito definio das funes que um sistema deve fazer. Descrevem as transformaes reali-
zadas nas entradas ou componentes de um sistema, a fim de que se produzam sadas.
No-funcionais: dizem respeito a restries, aspectos de desempenho, interfaces com o usurio, confiabilidade, se-
gurana, manutenibilidade, portabilidade, padres (aspectos sociais e polticos), e outras que o sistema deve possuir.
Alguns desses so traduzidos em funes (operacionalizados).
A diferena prtica entre eles que os requisitos funcionais dizem o que o sistema deve fazer, e os requisitos no-funcionais
fixam restries sobre como os requisitos funcionais devem ser implementados.

Processo da Engenharia de Requisitos
Os requisitos devem ser especificados de forma completa e consistente, para que os artefatos resultantes das prximas etapas
(Projeto, Implementao e Testes) possuam a qualidade desejada. As entradas e sadas deste processo ilustram que os fatores
humanos e tcnicos devem ser adequadamente tratados. Confira o modelo:
O processo de engenharia de requisitos composto basicamente pelas seguintes atividades:
Elicitao de requisitos: Inicia-se junto com os usurios, analisando diversos pontos de vista.
Anlise e negociao de requisitos: Os requisitos so analisados em ordem de importncia.
Documentao e Validao de requisitos: permite o rastreamento e validar sua conformidade.
Gerenciamento de requisitos: objetiva-se controlar a evoluo e mudanas dos requisitos.
importante lembrar que os requisitos podem no refletir as necessidades do cliente em relao ao sistema, pois comum
ocorrer interpretao errnea entre as partes, e requisitos incompletos ou inconsistentes.







Elicitao de requisitos
A elicitao de requisitos envolve as atividades de coleta, comunicao e validao de fatos. Esta uma atividade de absor-
o das reais necessidades dos usurios do software, sendo realizada em conjunto com a modelagem do sistema. As tcnicas
mais utilizadas na elicitao de requisitos so as entrevistas, que podem ser realizadas com um ou mais usurios. Para que
estas sejam eficazes elas devem ser planejadas com antecedncia, devendo ser identificados os objetivos de cada uma, seus
participantes e seu contedo.
O uso de perguntas de livre-contexto uma tcnica que facilita as entrevistas. Essas perguntas podem ser divididas em: per-
guntas iniciais, onde o foco est em definir usurios, objetivos gerais e benefcios; perguntas relacionadas ao problema e per-
cepo do usurio sobre o problema; e meta-perguntas onde o desenvolvedor se certifica do andamento da elicitao de requi-
sitos, se est entrevistando a pessoa certa ou se falta algo.
Requisitos
Acordados
Especificao do
Sistema
Modelos do
Sistema
Necessidades de
Stakeholders
Sistemas de
Informao
Existentes
Regulamenta
es
Padres Organi-
zacionais
Domnio da
Informao
Processo de Enge-
nharia de Requisi-
tos
80
A tcnica FAST (Facilitated Application Specification Techniques) utilizada para que a elicitao de requisitos seja realiza-
da com todos os usurios ou com grupos grandes de usurios, aumentando assim a produtividade da tarefa. O foco desta tc-
nica est na reunio que deve ser conduzida por pessoa neutra (facilitador) com participao de usurios e desenvolvedores.
JAD (Joint Application Design) um exemplo de tcnica FAST, e envolve planejamento, preparao e reunio de dinmica
de grupo, estruturada para ser realizada em um perodo fixo (em torno de 3 a 5 dias), obtendo produtos do ciclo de desenvol-
vimento do software. Nesta tcnica fundamental o envolvimento gerencial.

Engenharia de Usabilidade
Usabilidade pode ser vista como a medida de qualidade das experincias dos usurios no momento em que interagem com
algum produto ou sistema.
A ergonomia de Interface Homem-Computador (IHC) oferece bases tericas e metodolgicas para enfrentar o problema da
usabilidade do sistema, pois esta estuda as dificuldades relacionadas entre o homem e a mquina, tendo como objetivo ltimo
o alcance de um equilbrio timo entre conforto, segurana e eficincia do utilizador, face aos produtos e ferramentas.
Usabilidade "a combinao das caractersticas: facilidade de aprender, alta velocidade na execuo de tarefas, baixa taxa de
erros, subjetiva satisfao e reteno do usurio com o tempo (facilidade de lembrar como executar uma tarefa).
Verifica-se que a usabilidade tem assumido um papel importante no design de websites, visto que os usurios tm que assimi-
lar o projeto visual e navegacional do site antes de atingir o seu contedo.
Os critrios e recomendaes do documento da W3C-WAI de Acessibilidade vale tambm para a Usabilidade, pois propicia a
qualquer usurio um acesso mais rpido s informaes na Web.
Alm disso, a ISO 9241 objetiva " Promover a sade e a segurana de usurios de computadores e garantir que eles possam
operar estes equipamentos com eficincia e conforto." Nesta norma ISO, utilizam-se as seguintes definies:
Usabilidade: medida na qual um produto pode ser usado por usurios especficos, para alcanar objetivos
especficos com eficcia, eficincia e satisfao, em um contexto especfico de uso.
Eficcia: acurcia e completude com as quais usurios alcanam objetivos especficos. Ex: Nmero de tarefas con-
cludas. Ex: Nmero de usurios que completaram a tarefa corretamente.
Eficincia: recursos gastos em relao acurcia e abrangncia com as quais usurios atingem objetivos. Ex: N-
mero de toques de tecla para completar a tarefa. Ex: Tempo para completar a tarefa.
Satisfao: ausncia do desconforto e presena de atitudes positivas para com o uso de um produto.
Usurio: pessoa que interage com o produto.
Objetivo: resultado pretendido.
Tarefa: conjunto de aes necessrias para alcanar um objetivo.

Anlise de requisitos de usabilidade
Partindo da hiptese de um sistema interativo de agendas de contato dos telefones, extensvel a outros sistemas, foram identi-
ficados os seguintes requisitos e critrios de usabilidade a adotar:
Consistncia Ao-Efeito: consiste na disponibilidade do sistema para a entrada de dados ou acionamento de fun-
es, e o status das mesmas, informao de ajuda e suas formas de acesso. Ex. Modelos para entrada de dados
(dd/mm/yy); visualizao de unidade de medidas na entrada de nmeros; indicao de status e modo; legendas para
tipos de informaes; existncia de pistas para tamanhos dos campos disponveis; ttulo para as telas; help on-line.
Agrupamento e distino por localizao: relativo organizao visual da informao e relao de um com o
outro, e localizao e forma grfica para indicar relaes. Deve existir uma coerncia da presena de uma funo
em um determinado local com suas classificaes e relaes por proximidade. Ex: Organizao em lista hierrquica;
lgica de organizao: data, nome, tamanho ou tipo; legendas perto de teclas.
Agrupamento e distino por formato: consiste em verificar a forma, cor e tamanho, que ajudam a distinguir ele-
mentos e que indicam se ele pertence a uma determinada classe ou grupo. Ex: Clara distino visual de reas, cam-
pos e legenda que tenham diferentes funes.
81
Feedback: a resposta do sistema para as aes dos usurios. Rapidez e qualidade da resposta so duas caractersti-
cas fundamentais para o feedback. Ex: Toda a entrada de dados deve ser mostrada de forma perceptvel, exceto as re-
lativas segurana; interrupo de processamento da ao do usurio deve ser avisado e retornar ao estado anterior.
Leitura de Cor: significa o emprego correto da cor para permitir um contraste adequado leitura tanto nas teclas
quanto no visor, e o emprego de cores para destacar e alertar determinados eventos no sistema.
Capacidade de Leitura: a qualidade da leitura de texto na tela. (fonte empregada, tamanho da letra, espaos, ta-
manho da linha, etc). Ex.: Ttulos devem ser centralizados, legendas devem ser em caixa-alta, minimizar hifenizao.
Facilitao: critrio que trata dos elementos que ajudam a reduzir a carga perceptiva e cognitiva do usurio, aumen-
tando a eficincia do dilogo. Evitar comear nmeros com zero na frente; abreviar cdigos com muitos caracteres.
Aes Mnimas: diz respeito ateno ao nmero de aes para completar uma tarefa. Ex.: Minimizar o nmero de
passos para seleo no menu; evitar entradas que precisem de pontuao; definir valores padro para campos;
Densidade da Informao: carga de trabalho provinda de um ponto de vista cognitivo ou perceptual que atende a
muitos usurios e no respeita a individualidade daquele presente no momento. Ex.: Prover apenas informao til
para a transao; no encher a tela com informaes desnecessrias; usurios no precisaro memorizar dados.
Controle do Usurio: o usurio deve sempre ter o controle do sistema (poder interromper, cancelar e continuar). As
possibilidade de controle devem ser mostradas ao usurio.
Proteo e Correo de Erro: so mtodos de preveno ou reduo de erros e formas de recuperao quando o-
correrem - preveno do erro. Ex.: Avisos de possveis erros, clareza na mensagem de erro, reversibilidade, etc.
Consistncia: modo pelo qual o design da interface escolhe (cdigo, formato, procedimentos, etc.) e que estes so
mantidos iguais em contextos similares e diferentes em outros contextos. Ex: uso de telas similares.
Compatibilidade: o sistema deve estar de acordo com as caractersticas do usurio (memria, percepo, personali-
zao, habilidade, idade, expectativas, etc). Ex.: A estrutura dos dados deve ser natural ao usurio.

Projeto de interfaces
Descreve como o software dever se comunicar dentro dele mesmo (interfaces internas), com outros sistemas (interfaces ex-
ternas) e com pessoas que o utilizam (interface com o usurio).
A importncia do projeto de interface com o usurio se deve ao fato de que a maioria dos sistemas desenvolvida para ser
utilizada por pessoas. Nesta etapa do projeto, so definidos os formatos de janelas e relatrios, sendo a prototipagem muito
utilizada. A IU capta como um usurio comandar o sistema e como o mesmo apresentar as informaes a ele.
Nesta fase necessrio delinear as tarefas necessrias para obter a funcionalidade do sistema, estabelecer o perfil dos usu-
rios, construir prottipos e avaliar resultados (dados quantitativos e qualitativos).

Concepo, Projeto e Implementao de Interfaces

Processos de Software
Sempre existe a necessidade de software cada vez mais complexo, pois o cliente sempre quer mais, melhor e mais rpido.
Desta forma no suficiente apenas a presena de desenvolvedores altamente treinados, preciso um guia organizacional:
um processo.

ISO 12207
Esta norma descreve um padro que aborda todos os processos do ciclo de vida de um software. Ela estabelece os processos e
atividades que compem o processo de desenvolvimento de software, visando auxiliar os envolvidos na produo de software
a obter um melhor entendimento das atividades que devem ser executadas
82


A arquitetura da ISO 12207 est representada na figura, e segue dois princpios bsicos:
Modularidade: os processos tm alta coeso e baixo acoplamento, de forma que a alterao de um processo impacte
o mnimo na estrutura dos outros processos.
Responsabilidade: cada processo na norma de responsabilidade de uma parte envolvida, que pode ser uma orga-
nizao ou parte dela (ou mesmo de organizaes diferentes).
Os processos que envolvem o ciclo de vida do software so agrupados em trs classes a seguir:
Fundamentais: compreende os processos envolvidos na execuo do desenvolvimento, operao e manuteno do
software durante o ciclo de vida. Eles so: aquisio, fornecimento, desenvolvimento, operao e manuteno. Nes-
tes processos ocorre a atividade de gerenciamento de requisitos.
De apoio: so os processos que auxiliam o sucesso e a qualidade do projeto de software. Compreende os seguintes
processos: documentao, gerncia de configurao, garantia da qualidade, verificao, validao, reviso conjunta,
auditoria e resoluo de problemas.
Organizacionais: so os processos empregados por uma organizao para estabelecer e implementar uma estrutura
constituda pelos processos do ciclo de vida e pelo pessoal envolvido no desenvolvimento de software. So eles: ge-
rncia, infra-estrutura, melhoria e treinamento.

Metodologias geis: Extreme Programming
Programao extrema (Extreme Programming), ou simplesmente XP, uma metodologia gil para equipes pequenas e m-
dias e que iro desenvolver software com requisitos vagos e em constante mudana. Para isso, adota a estratgia de constante
acompanhamento e realizao de vrios pequenos ajustes durante o desenvolvimento de software.
A metodologia XP promove seus cinco valores fundamentais. A partir desses valores, possui como princpios bsicos: feed-
back rpido, assumir simplicidade, mudanas incrementais, abraar mudanas e trabalho de qualidade:
Comunicao: informa os requerimentos do sistema para os desenvolvedores. Em metodologias formais, utiliza-se
documentao. Favorece o uso de designs simples, metforas, colaborao de usurios e comunicao verbal.
Simplicidade: incentiva comear com solues simples e o refactoring. Foco na necessidade imediata (no futura).
Feedback: inclui o feedback do sistema (testes), do cliente (funcionais) e da equipe (estimativas de tempo, etc).
Coragem: conhecer o sistema, saber refator-lo e jogar cdigo fora, capacidade de resolver problemas rapidamente.
Respeito: buscar a qualidade, no gerando erros em outros mdulos, ou atrasando o trabalho de outrem.
Dentre as variveis de controle em projetos (custo, tempo, qualidade e escopo), h um foco explcito em escopo. Para isso,
recomenda a priorizao de funcionalidades que representem maior valor possvel para o negcio. Desta forma, caso seja
necessrio a diminuio de escopo, as funcionalidades menos valiosas sero adiadas ou canceladas.
Da concepo
at a
descontinuidade
processo
processo
processo
Atividade 1
Tarefa

Tarefa

Tarefa

Modularidade e re-
sponsabilidade
Ciclo
PDCA
83
A XP desestimula controlar qualidade como varivel de projeto pois o pequeno ganho de curto prazo na produtividade ao
diminuir qualidade no compensado por perdas (ou at impedimentos) em mdio e longo prazo.
O ciclo de atividades no processo de desenvolvimento de software da metodologia so: Requisitos (listening), Projeto, Co-
dificao e Teste. Para aplicar os valores e princpios durante o desenvolvimento, XP prope uma srie de prticas. H uma
confiana muito grande na sinergia entre elas, os pontos fracos de cada uma so superados pelos pontos fortes de outras.
Jogo de Planejamento (Planning Game): neste jogo as atividades so estimar tarefas e identificar prioridades, sen-
do o cliente essencial neste processo. Com isto cliente sabe o que est acontecendo e o que vai acontecer no projeto.
Pequenas verses: a liberao de pequenas verses funcionais do projeto auxilia muito no processo de aceitao por
parte do cliente, que j pode testar uma parte do sistema que est comprando.
Metfora: busca facilitar a comunicao com o cliente, entendendo a realidade dele. O conceito de rpido para um
cliente de um sistema jurdico diferente para um programador experiente em controlar comunicao em sistemas
de tempo real, como controle de trfego areo. preciso equalizar as palavras do cliente para o significado que ele
espera dentro do projeto.
Projeto Simples: simplicidade um princpio da XP. Por projeto simples significa dizer que caso o cliente tenha
pedido que na primeira verso apenas o usurio "teste" possa entrar no sistema com a senha "123" e assim ter aces-
so a todo o sistema, voc vai fazer o cdigo exato para que esta funcionalidade seja atendida, sem se preocupar em
sistemas de autenticao e restries de acesso.
Time Coeso: a equipe de desenvolvimento formada pelo cliente e o time de desenvolvimento.
Testes de Aceitao (Customer Tests): so testes construdos pelo cliente e conjunto de analistas e testadores, para
aceitar um determinado requisito do sistema.
Ritmo Sustentvel: trabalhar com qualidade, em um ritmo de trabalho saudvel (40 horas/semana, 8 horas/dia), sem
horas extras. Horas extras so permitidas quando forem trazer produtividade para a execuo do projeto.
Reunies em p (Stand-up Meeting): reunies em p para no se perder o foco nos assuntos para deixar as reunies
rpidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.
Posse Coletiva (Collective Ownership): o cdigo fonte no tem dono e ningum precisa ter permisso concedida pa-
ra poder modificar o mesmo. O objetivo com isto fazer a equipe conhecer todas as partes do sistema.
Programao em pares (Pair Programming): a programao em duplas em um nico computador. Geralmente a
dupla criada com algum sendo iniciante na linguagem e a outra pessoa funcionando como um instrutor. O novato
que fica a frente fazendo a codificao, e o instrutor acompanha ajudando a desenvolver suas habilidades, dessa
forma o programa sempre revisado visto por duas pessoas, evitando e diminuindo assim a possibilidade de erros
(bugs). E com isto, se busca sempre a evoluo da equipe, melhorando a qualidade do cdigo fonte gerado.
Padres de Codificao: a equipe de desenvolvimento precisa estabelecer regras para codificar e todos devem se-
guir estas regras. Desta forma parece que todos os cdigos fontes foram editados pela mesma pessoa, mesmo a equi-
pe possuindo 10 ou 1000 componentes.
Desenvolvimento dirigido por testes: primeiro crie os testes unitrios e depois crie o cdigo para que os testes fun-
cionem. Esta abordagem complexa no incio, pois vai contra o processo de desenvolvimento de muitos anos. S
que os testes unitrios so essenciais para que a qualidade do projeto seja mantida.
Refatorao: sempre que puder melhorar uma programao, melhore. O objetivo sempre que possvel refinar o
cdigo construdo, para que ele fique melhor, mais eficiente e mais simples.
Integrao Contnua: sempre que realizar uma nova funcionalidade, nunca esperar uma semana para integrar na
verso atual do sistema. Isto s aumenta a possibilidade de conflitos e a possibilidade de erros no cdigo fonte. Inte-
grar de forma contnua permite saber o status real da programao.

Metodologias geis: FDD
FDD (Feature Driven Development) em um projeto para um grande banco em Singapura, a partir de tcnicas de gerencia-
mento de projetos e de modelagem orientada a objetos.
Utilizando as tcnicas, estratgias e padres, nascia uma metodologia que equilibra as vantagens das metodologias rigorosas
(planejamento e modelagem, por ex.) e das metodologias geis (ciclos curtos, orientao ao cliente, nfase em programao).
Desde ento, a metodologia tem sido testada e os resultados tm comprovado sua eficcia e eficincia, servindo inclusive para
realizar pequenas melhorias ao plano bsico. A melhoria do prprio processo uma de suas premissas naturais.
84
Por suas caractersticas inerentes pode ser utilizada para equipes de tamanhos variados, tendo sido aplicada em projetos com
at 250 integrantes. Sua estrutura bsica compreende 5 processos, sendo que a descrio de cada um bem curta. de fcil
assimilao e prtica, fornecendo resultados rpidos e satisfatrios mesmo com equipes inexperientes.
Desenvolver um Modelo Geral (Develop an Overall Model)
Construir uma Lista de Funcionalidades (Build a Features List)
Planejar por Funcionalidade (Plan By Feature)
Projetar por Funcionalidade (Design By Feature)
Codificar por Funcionalidade (Build By Feature)
Adotando um ciclo iterativo de desenvolvimento, admite mudanas mesmo em meio construo do produto, embora o pro-
cesso de modelagem inicial j fornea um fundamento bsico que pode minimizar a necessidade e/ou o impacto de mudanas.
Uma das maiores atraes da FDD so os relatrios de acompanhamento. Com sua origem em experincias de gerenciamento
de projetos, certamente essa nfase em ver o que acontece durante o desenvolvimento uma caracterstica tpica. E jus-
tamente essa visibilidade que permite tomar decises relativas aos riscos, qualidade, mudanas nos requisitos, utilidade para o
usurio do produto e vrias outras variveis do projeto, em tempo hbil para no prejudic-lo.
Com esses relatrios possvel coletar mtricas para gerao de histricos, que permitiro melhorar as estimativas em prxi-
mos projetos, aumentando a preciso e segurana das decises sobre investimentos, mudanas de prioridades, atendimento de
prazos e custos, etc.
Os desenvolvedores aceitam prontamente e incorporam a metodologia de forma rpida, pois:
no causa interrupes burocrticas para a coleta dos dados sobre o progresso das atividades;
ajuda-os a se organizarem;
possibilita a entrega de produtos teis e com qualidade, repetidamente;
fortalece o sentimento de equipe, enquanto valoriza o talento individual;
facilita a difuso do conhecimento do negcio pela organizao, diminuindo as barreiras na comunicao.
As metodologias XP e FDD possuem muitas semelhanas e diferenas. Um bom exemplo que XP utiliza programao em
pares para remover defeitos (erros) e aumentar a qualidade, enquanto FDD utiliza inspees.

MDA Model Driven Architecture
A MDA uma metodologia de desenvolvimento de software proposta pela OMG, e tem por objetivo separar o que o sistema
necessita fazer de como o sistema pode fazer, possibilitando que projetos sejam desenvolvidos independentemente de plata-
forma e que, a partir deste projeto, selecione-se a plataforma especfica e se gere um projeto especificamente para ela.
Alm disso, a MDA busca prover modelos independentes de plataforma para diversos domnios de aplicaes, compreenden-
do banco de dados, sistemas embarcados, sistemas empresariais, etc. O desenvolvimento em trs modelos ou vises:
Modelo independente de computao (CIM - Computation Independent Model): a representao de mais alto
nvel do sistema, representando as possibilidades e funcionalidades deste que no dependem de computao.
Modelo independente de plataforma (PIM - Plataform Independent Model): especifica as funcionalidades do sis-
tema, explicitando a lgica para funcionamento do sistema. O PIM o projeto do sistema e pode ser transformado
em um modelo especfico de uma plataforma, o PSM.
Modelo especfico de plataforma (PSM - Plataform Specific Model): contm as funcionalidades do sistema apli-
cadas na plataforma.
Os objetivos da MDA so: portabilidade, interoperabilidade e reutilizao de elementos de projeto e de cdigo atravs da
separao dos conceitos. Para minimizar custos de desenvolvimento de software, utilizando os padres adotados pela OMG,
em especial os padres UML, CORBA e OCL, a MDA busca separar as funcionalidades de um sistema da forma como ele
deve ser implementado, concentrando-se em um desenvolvimento de software que satisfaa os seus objetivos.
A MDA objetiva prover facilidades para o desenvolvimento de software, como:
Especificao de um sistema independentemente da plataforma que o suporta;
Especificao de plataformas;
85
A escolha de uma plataforma particular para implementar o sistema;
Transformao da especificao de um sistema independente de plataforma em uma plataforma particular.
A MDA uma filosofia de desenvolvimento de software composta por um conjunto de modelos de sistema, utilizados para
suprir os seus objetivos. Um modelo de sistema entende-se por uma descrio ou especificao deste sistema, sempre apre-
sentado como uma combinao de desenhos e textos, estes ltimos que podem ser expressos em linguagem natural ou lingua-
gem de modelagem, como UML. Logo a MDA fornece modelos para especificao das vrias partes constituintes de um sis-
tema. Estes modelos so expressos em diagramas j conhecidos e utilizados pelos projetistas e programadores de software, os
diagramas da notao UML. Alm disso, a MDA prov aos diagramas uma fora maior do que os possuem os diagramas
UML convencionais, de forma que os modelos podem ser usados para direcionar o curso do projeto, construo, emprego,
operao, manuteno e modificao.
Esta filosofia de desenvolvimento de software busca sustentar na Engenharia de Software tradicional a capacidade de abstra-
o do conceito de implementao de um sistema das funcionalidades deste sistema. Para isso, propem modelar todas as
caractersticas do sistema que so independentes de plataforma e, posteriormente, gerar uma implementao do sistema para
uma arquitetura especfica. Ela tem por objetivo separar o que o sistema necessita fazer (requisitos funcionais) de como o
sistema pode fazer (requisitos no funcionais), permitindo uma transio de um modelo independente de arquitetura (PIM)
para uma implementao dependente de arquitetura (PSM), sem que sejam necessrias muitas alteraes no projeto do siste-
ma neste processo. Alguns benefcios com a adoo da MDA so: rapidez (menos tempo para que um software seja entre-
gue), minimizao no impacto ocasionado pelas mudanas de requisitos na escala do desenvolvimento, maior reuso de com-
ponentes de software e consistncia de implementao (poucos erros para corrigir e pouca propagao de erros), flexibilidade
arquitetural e independncia de plataforma.
Este o fluxo utilizado pela OMG para representar a MDA:
Um modelo que especifica o sistema dependente de computao, mas independente de plataforma;
Um modelo que especifica possibilidades que so independentes de computao;
Um mapeamento de um modelo independente de plataforma para uma plataforma especfica e;
Como resultado da transformao deste ltimo modelo gerado, um modelo para a plataforma especfica.
A MDA preocupa-se tambm com gerao automtica de cdigo. Isto quer dizer que, ao selecionar uma arquitetura, como
por exemplo J2EE ou .NET, espera-se que o modelo independente de plataforma PIM, estando convertido em um modelo
especfico de plataforma PSM, possibilite a gerao automtica de cdigo para a arquitetura escolhida. O desenvolvimento de
um sistema em MDA, utilizando o caminho mais curto para gerar cdigo a partir de um modelo UML, procede de um CIM
para um PIM, de um PIM para um PSM e de um PSM para cdigo. Existem atualmente muitas ferramentas de desenvolvi-
mento de projetos de software que convertem modelos UML em cdigo e que aplicam alguns dos conceitos da MDA.

MDD Model Driven Development
As pesquisas relacionadas com gerao automtica de cdigo concentram-se hoje desenvolvimento de software dirigido ao
modelo MDD, ou desenvolvimento dirigido a modelo. A promessa do MDD que compiladores de uma plataforma especfi-
ca produziro implementaes para mltiplas plataformas a partir de uma nica especificao.
Alm disso, eles fazem uma retrospectiva das tcnicas utilizadas de alguns anos pra c para obter um processo de desenvol-
vimento de software rpido, em que para transformao de um modelo UML em cdigo executvel utiliza-se das ferramentas
CASE de uma linguagem de programao especfica, mas salienta que estas ferramentas pouco auxiliaram, at o momento,
no desenvolvimento de um bom cdigo e pouco possibilitaram o aceleramento do desenvolvimento de software

RUP
necessrio um processo que integre as muitas facetas do desenvolvimento. Uma soluo o UP (Unified Process). O UP
um framework genrico de um processo de desenvolvimento, baseado em componentes e utiliza a definio da UML . Ele
dirigido pelos casos de uso, centrado na arquitetura, iterativo e incremental.
O RUP (Rational Unified Process) denota trs conceitos bem diferentes:
O RUP um Processo de Engenharia de Software. Fornece uma abordagem disciplinada para distribuir tarefas e
responsabilidades em uma organizao voltado para o desenvolvimento. O seu objetivo garantir a produo de
softwares de alta qualidade que atendem s necessidades do cliente, no tempo e com o budget previsto.
86
O RUP um Produto de Processo desenvolvido e mantido pela Rational Software. A equipe de desenvolvimento
do RUP trabalha continuamente e de forma dedicada com clientes, parceiros e com os grupos de desenvolvedores de
Produtos da Rational para assegurar que este processo e padro seja atualizado e aprimorado constantimente refle-
tindo as experincias mais recentes comprovando este guia/padro.
O RUP uma Abordagem de Desenvolvimento de Software, que iterativa, centrada a arquitetura, e dirigida a ca-
sos de uso. A maior parte das informaes sobre essa abordagem pode ser encontrado no prprio Produto, que con-
tm detalhes, exemplos, templates e todo o ciclo de vida
As atividades do RUP criam e mantm modelos. Ao invs de focar a produo de grandes quantidades de documentos em
papel, ele enfatiza o desenvolvimento e manuteno de modelos de forma semntica com ricas representaes do sistema /
software em desenvolvimento.
No existe uma maneira exata de aplicar o RUP, pois ele pode ser aplicado de vrias formas e ser diferente em cada projeto
e organizao. Porm, existem alguns princpios que podem caracterizar e diferenciar o RUP de outros mtodos iterativos:
Atacar os riscos cedo e continuamente;
Certificar-se de entregar algo de valor ao cliente;
Focar no software executvel;
Acomodar mudanas cedo;
Liberar um executvel da arquitetura cedo;
Construir o sistema com componentes;
Trabalhar junto como um time;
Fazer da qualidade um estilo de vida, no algo para depois.
Algumas vantagens ao utilizar o Processo Unificado so:
Fornece uma base slida para a construo do software
Melhor compreenso do sistema e organizao do desenvolvimento
Prescreve um refinamento sucessivo arquitetura
um processo iterativo e incremental, logo antecipa riscos e h um aprendizado facilitado.

Melhores Prticas do RUP
So seis as melhores prticas de um processo RUP:
Desenvolver software iterativamente: dado o tempo para desenvolver um software sofisticado, no possvel defi-
nir o problema e construir a soluo em um nico passo. Iterao permite refinar o projeto, e priorizar as atividades
de alto risco, fazendo com que cada iterao termine idealmente com uma nova release.
Gesto de requisitos: uma documentao apropriada essencial para qualquer grande projeto; note-se que o RUP
descreve como documentar a funcionalidade, restries de sistema, restries de projeto e requisitos de negcio. Os
casos de uso (tambm conhecidos como Use Cases) e os cenrios so exemplos de artefatos dependentes do proces-
so, que tm vindo a ser considerados muito mais eficazes na captura de requisitos funcionais.
Uso de arquitetura baseada em componentes: a arquitetura baseada em componentes cria um sistema que pode
ser facilmente extensvel, promovendo a reutilizao de software e um entendimento intuitivo. Um componente
normalmente se relaciona com um objeto na programao orientada a objetos. O RUP oferece uma forma sistemtica
para construir este tipo de sistema, focando-se em produzir uma arquitetura executvel nas fases iniciais do projeto,
ou seja, antes de comprometer recursos em larga escala. Estes componentes so normalmente includos em infra-
estruturas existentes como o CORBA e o COM (Modelo de Componentes de Objetos).
Uso de software de modelos visuais: ao abstrair a programao do seu cdigo e represent-la utilizando blocos de
construo grfica, o RUP consegue uma maneira efetiva de se ter uma viso geral de uma soluo. O uso de mode-
los visuais tambm pode permitir que indivduos de perfil menos tcnico (como clientes) tenham um melhor enten-
dimento de um dado problema, e assim se envolvam mais no projeto como um todo. A linguagem de modelao
UML tornou-se um padro industrial para representar projetos, e amplamente utilizada pelo RUP.
87
Verificao da qualidade do software: no assegurar a qualidade do software a falha mais comum em todos os
projetos de software. Normalmente, pensa-se em qualidade de software aps o trmino dos projetos, ou a qualidade
responsabilidade por uma equipe diferente da equipe de desenvolvimento. O RUP intenciona assistir no controle do
planejamento da qualidade, verificando-a na construo de todo o processo e envolvendo todos os membros da equi-
pe de desenvolvimento.
Gesto e Controle de Mudanas do Software: em todos os projetos de software a mudana inevitvel. O RUP
define mtodos para controlar e monitorizar mudanas. Como uma mudana pode afetar aplicaes de formas im-
previsveis, o controle de mudanas essencial para o sucesso de um projeto. O RUP tambm define reas de traba-
lho seguras, garantindo a um programador que as mudanas efetuadas noutro sistema no iro afetar o seu sistema.
O RUP possui cinco elementos principais: papis, atividades, artefatos, fluxos de trabalho e disciplinas.

Elementos Estticos do RUP
Um papel (workerl) define o comportamento e as responsabilidades de um determinado indivduo ou grupo de indivduos
trabalhando como uma equipe. Papis no so indivduos e nem ttulos de trabalho. Um indivduo pode assumir vrios papis.
Analista de sistema: o indivduo que assume este papel coordena a obteno dos requisitos e a modelagem dos ca-
sos de uso identificando funcionalidades do sistema e estabelecendo limites do sistema;
Projetista: esse indivduo define responsabilidades, operaes, atributos, relacionamentos de uma ou mais classes e
determina como elas devem ser ajustadas para serem implementadas no ambiente;
Projetista de testes: responsvel pelo planejamento, projeto, implantao e avaliao de testes, incluindo a gerao
de plano e modelo de teste, implementando procedimentos de testes e avaliando a abrangncia dos testes, resultados
e a efetividade.
Uma atividade uma unidade de trabalho que um indivduo executa quando est exercendo um determinado papel e produz
um resultado importante para o contexto do projeto. Cada atividade pode ser dividida em passos. So exemplos de atividades:
Planejar uma iterao: realizada pelo papel gerente de projeto;
Encontrar casos de uso e atores: realizada pelo papel analista de sistemas;
Rever o projeto: realizada pelo papel revisor de projeto;
Executar um teste de performance: realizado pelo papel testador de performance.
Um artefato um pedao de informao que produzido, modificado ou utilizado em um processo. Os artefatos so os pro-
dutos de um projeto. So as coisas produzidas durante o desenvolvimento do projeto. Artefatos so utilizados como entradas
de atividades e so produzidos como sada. Os artefatos podem ter vrias formas:
Um modelo, como um modelo de caso de uso, um modelo de projeto;
Um elemento de um modelo, como uma classe, um caso de uso, um sub-sistema ;
Um documento, como um caso de negcio, glossrio, viso;
Cdigo fonte e Executveis.
A enumerao de atividades, papis e artefatos no constituem um processo. necessrio saber a seqncia do desenvolvi-
mento das atividades para que se produzam artefatos de valor para o projeto. Isso definido pelo fluxo de trabalho.
Um fluxo de trabalho (workflow) uma seqncia de atividades que so executadas para a produo de um resultado valioso
para o projeto. Fluxos de trabalho podem ser representados por diagramas de seqncia, diagramas de colaborao e diagra-
mas de atividades da linguagem UML. O RUP utiliza trs tipos de fluxos de trabalho:
Fluxos de trabalho principais (core workflow), associados com cada disciplina;
Fluxos de trabalho de detalhe (detail workflow), para detalhar cada fluxo de trabalho principal;
Planos de iterao, que mostram como a iterao dever ser executada.

88
Qualidade
Processos Tecnologia
Pessoas
Disciplinas do RUP
Uma disciplina uma coleo de atividades relacionadas que fazem parte de um contexto comum em um projeto. As discipli-
nas proporcionam um melhor entendimento do projeto sob o ponto de vista tradicional de um processo cascata. A separao
das atividades em disciplinas facilita a compreenso das atividades, porm dificulta mais o planejamento das atividades.
O RUP possui nove disciplinas, divididas em disciplinas do processo e de suporte. As Disciplinas de Processo so a mode-
lagem de negcios, requisitos, anlise e projeto, implementao, teste e implantao. As Disciplinas de Suporte so o geren-
ciamento de configurao e mudanas, o gerenciamento de projeto e o ambiente (environment).



Fases do RUP
O Processo Unificado repete vrios ciclos at a aposentadoria do sistema cada ciclo gera um produto liberado para uso. Cada
ciclo possui 4 fases: Concepo, Elaborao, Construo e Transio.
Cada fase ento subdividida em iteraes. Um conjunto de artefatos (release) gerado a cada iterao. Um milestone
gerado a cada fase. As fases indicam a nfase que dada no projeto em um dado instante. Para capturar a dimenso do tempo
de um projeto, o RUP divide o projeto em quatro fases diferentes:
Concepo: nfase no escopo do sistema
Elaborao: nfase na arquitetura
Construo: nfase no desenvolvimento
Transio: nfase na implantao

Modelos de melhoria de qualidade de processo e produto
O grande desafio da Engenharia de Software desenvolver softwares de qualidade assegurada, com elevada produtividade,
dentro do prazo estabelecido, e sem necessitar de mais
recursos que os alocados.
Um esforo surgiu com o trabalho pioneiro de Yourdon
para elaborar modelos para desenho e implementao de
sistemas. Surgiu o conceito do Tringulo da Qualidade
(figura), que depende de trs fatores (pessoas, processos
e tecnologia). Outros modelos mais elaborados surgiram
para elevar a qualidade dos softwares.
89
A ISO (International Organization for Standardization) a organizao internacional para a padronizao, estabelecida em
1947. O seu principal objetivo o desenvolvimento de padres mundiais, facilitando o intercmbio mundial de produtos e
servios, e cooperao intelectual, cientfica, econmica e tcnica.
No Brasil a ABNT (Associao Brasileira de Normas Tcnicas) a entidade responsvel pela normalizao tcnica no pas,
alm de representar o Brasil nas entidades de normalizao internacional, como a ISO.

CMM/CMMI
Em 1991, o SEI (Software Engineering Institute) publicou o CMM (Capability Maturity Model) para software, um frame-
work de maturidade que estabelece fundamentos de engenharia de software e de gerenciamento de projeto para controle
quantitativo do processo de software.
O CMM (Capability Maturity Model, ou Modelo de Maturidade da Capacitao) uma estrutura conceitual que prope um
caminho evolutivo de melhoria, para que organizaes venham a praticar Engenharia de Software de forma sistemtica. Este
caminho evolutivo definido por cinco nveis de maturidade. As organizaes passam a evoluir nestes nveis na medida em
que definem, implementam, implantam, medem, controlam e melhoram seus processos de software, saindo de um processo
de desenvolvimento pouco sistemtico e alcanando um processo maduro e otimizado;
O CMM estabelece prticas de Engenharia de Software relacionadas com aspectos gerenciais, organizacionais e tcnicos.
Quando estas prticas so seguidas rotineiramente, as organizaes se capacitam a atingir metas estabelecidas de controle de
custo, cronograma e produtividade. O CMM pode ser utilizado:
Como um guia para ajudar gerentes e tcnicos a definirem e melhorarem os processos de software da organizao,
adotando um processo sistemtico e efetivo de desenvolvimento de sistemas
Para identificar os pontos fracos e os de melhoria nos processos de desenvolvimento e de manuteno de software
praticados na organizao, viabilizando a tomada de ao para aprimorar os processos
Para avaliar o risco de contratar um projeto de software de uma outra organizao, bem como para monitorar os con-
tratos com esta organizao
Segundo o CMM, a principal causa dos problemas de qualidade e produtividade a falta de um processo de desenvolvimento
de software claramente definido e efetivo. O CMM prope um caminho gradual que leva as organizaes a se aprimorarem
continuamente em busca da soluo dos seus problemas. Este caminho se d em cinco nveis de maturidade:
1 Inicial: a improvisao rege o processo de desenvolvimento.
2 Repetitivo: focado nos aspectos gerenciais, como controles bsicos mais imediatos.
3 Definido: nfase na descrio do processo padro da organizao.
4 Gerenciado: tcnicas para controlar os processos de desenvolvimento e a qualidade final.
5 Otimizado: apresenta uma melhoria contnua nos processos, atravs de anlises do nvel anterior.
J o CMMI foi desenvolvido para integrar trs disciplinas: engenharia de software, engenharia de sistemas e desenvolvimento
integrado de produto e processo, utilizando como fonte primria os bem sucedidos padres do modelo CMM. Os seus mode-
los podem ser em estgio (staged) ou contnuos (continuous).











Gerenciamento
de Requisitos
Desenvolvimento
de Requisitos
Soluo
Tcnica
Integrao
de Produto


Cliente
Alternativas de
Soluo
Requisitos
Requisitos de Produto e
Componentes
Componentes
Produto
Requisitos
Componentes
Relatrio Verifica-
o
Artefatos,
Produto
Relatrio
Validao
90








Abaixo, esto relacionadas as reas-chave de Processo para o sistema de qualidade, como descritos no item 3 do Technical
Report CMU/SEI-93 - Capability Maturity Model for Software:

Nvel 1 - Inicial
No tem reas-chave de Processo.

Nvel 2 - Repetvel
Mais do que qualquer outro nvel de maturidade, o nvel repetvel tm interesse especial, pois alm do fato da grande maioria
das empresas estar no nvel 1 (Inicial), o caminho para o nvel 2 talvez o mais difcil de ser percorrido, pois trata-se de colo-
car o trem em movimento, enquanto a passagem para os nveis seguintes pode se beneficiar do embalo gerado pelos esforos
de melhoria para se alcanar o nvel 2.
Iniciando o Processo de Melhoria: a partir de uma avaliao formal ou informal, em que se encontram os principais pontos
fracos no processo de desenvolvimento, necessrio fazer com que todos dentro da empresa comprem a idia da melhoria, e
isto inclui a alta administrao (diretoria), profissionais de informtica (gerentes, analistas programadores, AD, DBA, produ-
o, suporte etc) e usurios (gerncia e pessoal operacional). As negociaes de planejamento so o teste crtico do time ge-
rencial. Este time deve tratar o plano inicial como um ponto de partida e, quando o prazo ou o custo tiverem de ser reduzidos,
o escopo do trabalho deve ser igualmente cortado
O foco do nvel 2: o estabelecimento de procedimento bsicos de Gerenciamento de Projetos. A falta de planejamento a
primeira coisa a ser atacada, sem a qual qualquer outro esforo de melhoria baldado. Uma equipe que desenvolve seu traba-
lho aleatoriamente no poder se beneficiar de tcnicas de inspeo, metodologias de desenvolvimento ou mtricas.
As diversas atividades de melhoria de software devem ser conduzidas por um grupo especialmente constitudo para isto, nor-
malmente chamado de SEPG (Software Engineering Process Group - Grupo de Processos de Engenharia de Software). A
existncia de um grupo especificamente encarregado destas tarefas fundamental para garantir os projetos de melhoria. Ob-
viamente, no so os desenvolvedores j pressionados que disporo de tempo para estas atividades. As KPAs do nvel 2 so:
Gerenciamento de Requisitos: o seu propsito estabelecer um entendimento comum entre o usurio e a equipe de
projeto a respeito dos requerimentos que sero atendidos pelo projeto. Alm disso, so estabelecidos procedimentos
para a mudana dos requisitos, garantindo que os planos, cronogramas e recursos alocados estejam sempre coeren-
tes com os requisitos. Estes requisitos devem tambm ser revisados por diversas reas envolvidas (para verificar sua
viabilidade) e ter sua qualidade controlada. Observe-se que a documentao dos requisitos e sua reviso devem ser
feitas antes da elaborao do plano do projeto. Em seguida, a organizao precisa instituir procedimentos para a alte-
rao dos requisitos. A existncia de um procedimento formal tem dois benefcios: garante que os planos sero revis-
tos para acomodar as alteraes (isto , renegociao de prazos e recursos) e funciona como um freio para alteraes
desnecessrias ou postergveis (normalmente, a maioria), instituindo uma disciplina de controle de prioridades.
Planejamento de Projetos: o seu propsito garantir que, a cada projeto, sejam elaborados planos razoveis para o
desenvolvimento. Isto envolve a realizao de estimativas e o estabelecimento de compromissos. Tambm se inclu-
em aqui atividades de gerenciamento de riscos e alocao de recursos.A empresa deve instituir polticas e procedi-
mentos padronizados para o planejamento de projetos, incluindo a necessidade de envolver todas as reas interessa-
das (tcnicas e usurias) no processo de planejamento. Esta KPA tambm pressupe que a empresa tenha definido
um ciclo de vida de sistemas para ser usado no planejamento.
Acompanhamento e Superviso de Projetos: planejar o projeto no basta. preciso garantir, ao longo de sua exe-
cuo, que os planos esto sendo cumpridos. O propsito desta KPA dar visibilidade sobre o progresso real do pro-
jeto em relao ao planejado, permitindo a tomada de aes corretivas quando a realidade estiver se afastando muito
91
do que foi inicialmente planejado. A organizao deve instituir procedimentos para garantir que o progresso do pro-
jeto continuamente comparado com o planejado, em termos de prazos, custos e qualidade. Alm disso, os proce-
dimentos devem estabelecer gatilhos a serem disparados quando houver muita distncia, indicando as aes correti-
vas a serem tomadas em cada caso, incluindo alteraes nos compromissos assumidos. A evidncia, por exemplo, de
que um prazo no ser cumprido deve levar renegociao de prazo, recursos, escopo ou nvel de qualidade previa-
mente acordados. Esta KPA, naturalmente, inclui o acompanhamento dos fatores de risco identificados nas ativida-
des de gerenciamento de riscos includas na KPA de Planejamento de Projetos. Outro ponto importante coberto por
esta KPA o estabelecimento da obrigatoriedade da existncia de pontos de reviso formal ao longo do projeto. Isto
significa que, em determinados momentos do desenvolvimento, os produtos gerados at ento so revisados for-
malmente pelas reas envolvidas, como forma de garantia que o projeto est andando conforme deveria. Quando o-
correm alteraes nos planos por conta de aes corretivas tomadas, fundamental que os planos originais sejam
mantidos. Isto permitir futuramente que os erros de estimativas sejam conhecidos e, portanto, reduzidos. Sabendo-
se onde se errou, pela comparao entre planejado e real, futuros projetos podero ser estimados com mais preciso.
Gerenciamento de Subcontratao: cada vez mais so usados recursos externos (outsourcing) para colaborar no
desenvolvimento do software. O propsito desta KPA garantir a seleo e gerenciamento eficaz destes recursos
terceirizados. A organizao deve estabelecer procedimentos para garantir que a seleo de subcontratados se faz de
forma apropriada, que as atividades a serem desenvolvidas pelos terceiros estejam bem definidas e planejadas, que o
contrato entre a empresa e os terceiros adequado e que a comunicao entre empresa e terceiros adequada. Alm
disso, devem ser estabelecidos procedimentos especificando como se far a comunicao (por exemplo, documentos
de trabalho a serem trocados) e, naturalmente, procedimentos para reviso e controle de qualidade dos produtos ge-
rados pelos terceiros.
Garantia de Qualidade de Software: o propsito desta KPA prover visibilidade sobre a qualidade tanto dos pro-
cessos utilizados pela equipe de projeto quanto dos produtos gerados. Isto inclui revises formais e informais dos
produtos e auditorias dos processos. Tipicamente, em empresas com recursos suficientes, existe um grupo especial-
mente dedicado a estas tarefas. importante observar que esta KPA diz respeito tanto a produtos quanto a processos.
Alm disso, as revises de qualidade se do em todas as fases do desenvolvimento. Quanto reviso dos processos,
deve-se dizer que no basta revisar produtos. Na maioria das vezes, produtos sem qualidade so resultado de proces-
sos sem qualidade. No basta descobrir que um programa tem um monte de bugs. necessrio descobrir por qu es-
tes bugs existem. Geralmente, a razo ser algo como o no uso dos padres definidos de programao, documenta-
o de programao insuficiente, comunicao inadequada entre analistas e programadores etc. A empresa deve ins-
tituir um grupo de garantia de qualidade (ou ao menos um comit) e procedimentos que garantam que as atividades
necessrias de garantia de qualidade so planejadas, executadas e revisadas. Estes procedimentos devem incluir me-
didas objetivas de verificao de qualidade, e tambm padres de qualidade que possam ser usados como medida de
comparao com os produtos e processos efetivamente utilizados. A cada projeto, portanto, so desenvolvidos pla-
nos de garantia de qualidade, dentro do planejamento geral do projeto. Este planos incluem pontos e procedimentos
de verificao, tais como revises de documentos, inspees de cdigo e, naturalmente, testes.
Gerenciamento de Configurao: o propsito desta KPA identificar, organizar, controlar modificaes de soft-
ware que est sendo construdo por uma equipe, maximizar a produtividade e minimizar erros e defeitos. aplicada
a todo o processo de Engenharia de Software, do incio do projeto at quando produto retirado de operao, garan-
tindo que as alteraes estejam sendo corretamente implementadas e relatadas a outras pessoas que possam ter inte-
resse. Procedimentos de Controle de Mudanas so estabelecidos, garantindo que alteraes em produtos (documen-
tos, dados de teste, programas) so feitas de forma consistente e sob o conhecimento e aprovao de todos os envol-
vidos. O uso de software de Controle de Configurao (Librarians) pode facilitar a execuo destas atividades.
Tambm necessria a criao de um grupo (ou comit) responsvel pelas atividades de gerenciamento de configu-
rao. Toda manuteno passa a ser considerada como a implantao de uma nova verso ou release do software.

Nvel 3 - Definido
Focalizao dos Processos da Organizao
Definio dos Processos da Organizao
Programa de Treinamento
Gerenciamento Integrado de Software
Engenharia de Produto de Software
Coordenao Inter Grupos
Revises Detalhadas para Preveno de Defeitos
92

Nvel 4 - Gerenciado
Gerenciamento Quantitativo dos Processos
Gerenciamento da Qualidade de Software

Nvel 5 - Otimizado
Preveno de Falhas
Gerenciamento das Mudanas nos Processos
Gerenciamento das Mudanas Tecnolgicas
Caractersticas Comuns
Verificao da Implantao (revises e auditorias)
Mensurao e Anlise (medidas e avaliaes)
Compromisso para Realizar (polticas e responsabilidades)
Capacidade para Realizar (recursos, estruturas e treinamento)
Aes e Atividades Realizadas (planejamento, procedimentos e aes corretivas)

ISO 9126
A ISO/IEC 9126 trata das caractersticas da qualidade de software e mtricas, e divide-se em quatro partes:
ISO/IEC 9126-1: Modelo de qualidade.
ISO/IEC 9126-2: Mtricas externas.
ISO/IEC 9126-3: Mtricas internas.
ISO/IEC 9126-4: Mtricas de qualidade em uso.
De acordo com a ISO 9126-1, a mais antiga das normas de qualidade de software, alguns conceitos so:
Qualidade interna: refere-se principalmente ao ambiente de programao, e a totalidade dos atributos de um pro-
duto que satisfazem as necessidades quando utilizado em condies especificadas.
Qualidade externa: refere-se principalmente qualidade de entrega do produto, e constitui o quanto um produto sa-
tisfaz as necessidades quando utilizado em condies especificadas.
Qualidade em uso: a viso do usurio do ambiente de qualidade que o software est inserido.
De acordo com esta norma, um produto possui caractersticas e sub-caractersticas que medem a qualidade:
Funcionalidade: O produto de software satisfaz as necessidades? o conjunto de atributos que evidenciam se as
funes satisfazem as necessidades.
Adequao (se as funes so apropriadas)
Acurcia (evidencia a gerao de resultados corretos)
Interoperabilidade (capacidade de interagir com outros sistemas)
Conformidade (esteja de acordo com as normas e regulamentaes)
Segurana de Acesso (evita acesso no autorizado a programas e dados)
Confiabilidade: O produto de software imune falhas? Atributos que evidenciam se o software capaz de manter
um nvel de desempenho durante um perodo de tempo.
Maturidade (evidncia a freqncia de falhas)
Tolerncia Falhas (capacidade do software de manter o nvel do desempenho em falhas)
Recuperabilidade (capacidade de restabelecer e restaurar dados aps a falha)
93
Usabilidade: O produto de software fcil de usar? Atributos que evidenciam o esforo para se poder utilizar o
software, bem como o julgamento individual deste uso.
Operabilidade (evidencia a facilidade de operar e controlar as funes do software)
Apreensibilidade (facilidade de aprendizado do software)
Inteligibilidade (facilidade de entendimento dos conceitos utilizados pelo software)
Eficincia: O produto de software rpido? Mede o nvel de desempenho em relao aos recursos.
Comportamento em relao ao tempo (tempo de resposta, processamento e execuo)
Comportamento em relao aos recursos (quantidade de recursos e a durao do seu uso)
Manutenibilidade: O produto de software fcil de modificar? Atributos que evidenciam o esforo necessrio para
fazer modificaes especificadas no software.
Analisabilidade (evidencia a facilidade de modificao e remoo de defeitos)
Modificabilidade (a facilidade de modificao e remoo dos defeitos)
Estabilidade (evidencia a ausncia de riscos de efeitos inesperados)
Testabilidade (evidencia a facilidade de testar o software)
Portabilidade: O produto de software fcil de usar em outro ambiente? Atributos que evidenciam a capacidade de
um software de se transferir para outro ambiente.
Adaptabilidade (capacidade do software de ser adaptado a ambientes diferentes)
Capacidade para ser instalado (facilidade de instalao do software)
Conformidade (conformidade com o software com padres ou convenes de portabilidade)
Capacidade para substituir (capacidade do software de substituir outro software)
Alm de todas estas caractersticas, utiliza-se uma outra ISO (14598) para descrever detalhadamente todos os passos para a
avaliao destas caractersticas e sub-caractersticas de um software.

Gesto da Qualidade
Destaca-se o mtodo PDCA, que pode ser aplicado a todos os processos, e uma ferramenta que fornece o carter cientfico
administrao moderna, equiparado ao mtodo cientfico moderno.
Planejamento("Plan"): estabelecimento dos objetivos e dos processos necessrios para a obteno de resultados,
de acordo com os requisitos do cliente e com a poltica da qualidade da organizao.
Execuo ("Do"): implementao dos processos.
Verificao ("Check"): monitoramento e medio de processos e produtos em relao poltica, objetivos e requi-
sitos para o produto, bem como comunicao dos resultados.
Ao ("Act"): tomada de aes a fim de melhorar continuamente o desempenho dos processos.



94
Atividades da Qualidade Total (ISO 9001)
1 - Responsabilidade da administrao
2 - Sistema da qualidade
3 - Anlise crtica de contrato
4 - Controle de projeto
5 - Controle de documentos e de dados
6 - Aquisio
7 - Controle de produto fornecido pelo cliente
8 - Identificao e rastreabilidade de produto
9 - Controle de processo
10 - Inspeo e ensaios
11 - Controle de equipamentos de inspeo, medio e ensaios
12 - Situao de inspeo e ensaios
13 - Controle de produto no-conforme
14 - Ao corretiva e ao preventiva
15 - Manuseio, armazenamento, embalagem, preservao e entrega
16 - Controle de registros da qualidade
17 - Auditorias internas da qualidade
18 - Treinamento
19 - Servios associados
20 - Tcnicas estatsticas







95
Modelagem de Processos de Negcio

Conceitos bsicos
Os negcios de qualquer tipo de organizao necessitam do apoio da tecnologia e isso faz com que seja importante que o sis-
temas de informao sejam projetados para suportar e atender aos objetivos de negcio. Um negcio pode ser entendido co-
mo qualquer tipo de operao em andamento que tem ou usa recursos e tenha um ou mais objetivos. Para se projetar, entender
ou se buscar melhorias no funcionamento de um negcio, torna-se essencial fazer o modelo de processos de negcio, que
uma viso simplificada da realidade complexa da organizao. A modelagem permite, por exemplo, a abstrao de detalhes
irrelevantes em determinados momentos e concentrar foco em aspectos importantes.
A Modelagem de Processos de Negcio um ponto central para os que gerenciam ou influenciam mudanas. Assuntos como
Melhoria Contnua de Processos, Qualidade Total, Gerenciamento de Processos, Gerenciamento do Conhecimento, Melhoria
da Qualidade, ISO 9000, e outros temas semelhantes, requerem habilidades de Modelagem de Processos de Negcio.
O Modelo de Negcios uma abstrao de como um negcio funciona. Ele se prope a:
prover uma viso simplificada da estrutura do negcio;
atuar como uma base para a comunicao, melhorias ou inovaes;
definir os requisitos do sistema de informao que so necessrios para apoiar o negcio.
Do ponto de vista de metodologias para a realizao da modelagem de processos de negcio, existem diversas abordagens.
Cada uma delas utiliza uma determinada notao e linguagem, mas abrangem o mesmo conjunto de passos/atividades:
1) definir o escopo da ao;
2) documentar a misso, estratgia, metas e objetivos da organizao;
3) compreenso do processo/organizao como est (asis);
4) avaliao do modelo obtido;
5) decidir quanto a: abandonar, contratar, manter como est, melhorar ou redesenhar os processos;
6) discutir e gerar idias;
7) determinar caractersticas do processo desejado;
8) projetar os processos desejados (to-be).

Identificao e delimitao de processos de negcio
Um processo de negcio um procedimento onde documentos, informaes e tarefas so passadas entre participantes de a-
cordo com um conjunto de regras definidas a serem alcanadas ou realizadas para o objetivo de negcio.
Os elementos de um processo so:
Trabalho / Processo: o objetivo direcionado. Como exemplo, a "Reviso de Currculos de Candidatos".
Objetivo: razo para a realizao do trabalho. Um exemplo "Seleo Criteriosa de empregados".
Atividades: a decomposio do trabalho em tarefas a serem realizadas. "Reviso do Currculo" e "Envio de Carta
de Recusa" e "Agendamento da Entrevista" so exemplos de atividades.
Atores / Agentes: se encarregam das atividades. No exemplo: "Gerente de RH", "Analista de RH" e "Secretria".
Entradas / Sadas: so os produtos necessrios / gerados a cada atividade / processo. "Currculo" e "Avaliao".
Regras: so as dependncias entre atividades. Podem aparecer em um fluxograma. "Candidato Qualificado?"
A identificao dos processos permitem um entendimento uniforme do negcio. Existem alguns modelos que permitem me-
lhorar essa capacidade, como o Modelo da Organizao (estrutura da organizao), o Modelo de Objetivos (liga os objeti-
vos da empresa com os processos de negcio), o Modelo de Processos (modela a estrutura de processos e atividades) e ou-
tros, como o Modelo de Workflow, Modelo de Interao e Modelo de Casos de Uso.

96

Tcnicas de mapeamento de processos (modelos AS-IS)
A modelagem de processos de negcio visa a otimizao dos processos executados em uma organizao. Contudo, para haver
melhorias, fundamental que se saiba a forma como o negcio est sendo executado hoje ou, em outras palavras, quais os
processos que atendem ao negcio atualmente. Este procedimento conhecido como modelagem AS-IS.
Normalmente durante o mapeamento AS-IS so identificados problemas na execuo, como por exemplo, a mesma tarefa
sendo executada mais que uma vez e de formas diferentes; ou ainda a ordem de execuo das tarefas originando gastos adi-
cionais. Tambm inclui a Anlise de Risco (participantes faltantes, interao entre eles, desacordos, resoluo de conflitos).

Tcnicas de anlise e simulao de processos

Construo e mensurao de indicadores de processos

Tcnicas de modelagem de processos (modelos TO-BE)
Para realizar a otimizao dos processos de negcio, so elaborados os modelos TO-BE que identificam quais os processos
que efetivamente devem ser executados, alm da ordem de execuo.
O modelo TO-BE pode ser originado a partir do AS-IS quando este for criado. Note, no entanto, que no existe obrigatorie-
dade da elaborao de ambos: se for considerado suficiente, pode ser realizado apenas o mapeamento TO-BE.

Modelagem de Processos em UML
A UML adequada tanto para a modelagem de sistemas de software, quanto para modelagem de negcio pelos motivos:
Muitos desenvolvedores j esto familiarizados com a linguagem, o que facilita a utilizao.
A utilizao da mesma linguagem tanto para a modelagem de negcio quanto para a modelagem do sistema de soft-
ware faz com que a documentao seja consistente e ainda facilita a comunicao entre as duas modelagens
Existe um grande nmero de ferramentas disponveis para a modelagem de negcio usando a UML.
Com a UML possvel descrever:
o Aspectos tanto estruturais quanto de negcio (como a organizao, hierarquia de objetivos, ou recursos).
o Aspectos comportamentais do negcio (como os processos).
o Regras de negcio que afetam tanto a estrutura quanto o comportamento.
O uso da UML para modelar processos de negcio facilita uma melhor compreenso dos negcios da organizao, na medida
que diagramas como os de caso de uso e de seqncia podem ser usados.
http://www.uniandrade.br/publicacoes/revista/cientifica/MontaArtigo.asp?ID=156

Modelagem estrutural: diagramas de classe, pacotes lgicos, diagramas de objetos
Modelagem comportamental: diagramas de casos de uso, diagramas de interao, diagramas de atividade, DTEs (estados)


Notao

Artefatos

97
Atividades








98
Gerncia de Projetos

Gerncia de Projetos (ou Gesto de Projetos) a aplicao de conhecimentos, habilidades e tcnicas na elaborao de ativi-
dades relacionadas para atingir um conjunto de objetivos pr-definidos. O conhecimento e as prticas da gerncia de projetos
so melhores descritos em termos de seus processos componentes.
Reduzida sua forma mais simples, a gerncia de projetos a disciplina de manter os riscos de fracasso em um nvel to bai-
xo quanto necessrio durante o ciclo de vida do projeto. O risco de fracasso aumenta de acordo com a presena de incerteza
durante todos os estgios do projeto.
A gerncia de um projeto de software pode influenciar o desempenho da organizao de diversas maneiras:
prover uma vantagem competitiva, permitindo respostas rpidas s mudanas de mercado;
prover informao necessria, acurada e no tempo para permitir melhor tomada de deciso;
reduzir o custo do negcio, substituindo capital por trabalho e automatizando transaes da empresa;
Gerenciar um projeto requer a realizao das seguintes atividades bsicas:
Planejamento: Identificar e planejar as atividades e tarefas, preparando planos de trabalho, estimativas e cronogra-
mas viveis. Identificar, planejar aes e eliminar fontes de risco, antes que aconteam. Planejar as necessidades e a
obteno dos recursos humanos e tcnicos, e definir os produtos intermedirios e suas entregas.
Execuo: Criar condies para que as atividades previstas possam ser realizadas. Atuar para que o grupo realize as
tarefas com sinergia e supere as dificuldades previstas e imprevistas, de forma a atingir os objetivos (cronogramas).
Estabelecer regras para as solicitaes de mudanas nas especificaes do projeto e negociar as condies para a a-
ceitao destas. Conduzir o processo para a obteno de mxima qualidade do produto.
Controle: Medir e avaliar o progresso do projeto (fsico e financeiro) em relao ao planejado, tomar aes correti-
vas e comunicar o andamento do projeto.

PMBOK
PMBOK (Project Management Body of Knowledge) um padro de Gerncia de Projetos desenvolvido pelo PMI (Project
Management Institute). Ele largamente aceito por diversas indstrias como sendo o padro de fato de Gerncia de Projetos.
O propsito principal do PMBOK identificar o subconjunto de conhecimentos sobre a profisso, sendo aplicveis para a
maior parte dos projetos na maior parte do tempo. Outro propsito prover um vocabulrio nico para a profisso, padroni-
zando seus termos. Tambm usado como referncia bsica para os exames de certificao do PMI.

Conceitos
Um projeto um empreendimento temporrio com o objetivo de criar um produto ou servio nico. Projetos possuem muitas
caractersticas comuns: so executados por pessoas, tm recursos limitados e so planejados, executados e controlados.
Na abordagem tradicional, distinguimos cinco estgios no desenvolvimento de um projeto:
Iniciao de projeto
Planejamento de projeto
Produo de projeto
Monitoramento de projeto
Fechamento (compleo) de projeto

reas de Conhecimento
O gerenciamento de projetos tenta adquirir controle sobre quatro variveis: tempo, custo, qualidade e escopo. De acordo com
a abordagem PMBOK, pode ser classificado em 9 (nove) reas de conhecimento:
99
Gerncia de Integrao: Envolve os processos necessrios para garantir que os vrios elementos do projeto sejam
coordenados de forma apropriada. Envolve as negociaes dos conflitos entre objetivos e alternativas concorrentes,
com a finalidade de atingir ou exceder s necessidades e expectativas dos stakeholders interessados. Envolve:
o Desenvolvimento do plano do plano do projeto
o Execuo do plano do projeto
o Controle integrado de alteraes
Gerncia de Escopo: Envolve os processos necessrios para assegurar que o projeto contm todo o trabalho neces-
srio para completar o projeto com sucesso. O seu foco principal na definio e controle do que est ou no consi-
derado no projeto. O escopo do projeto difere-se do escopo do produto na medida em que o escopo do projeto defi-
ne o trabalho necessrio para fazer o produto, e o escopo do produto define os recursos (atributos e comportamentos)
do produto que est sendo criado.
o Iniciao
o Definio do escopo
o Verificao de escopo
o Controle de alteraes de escopo
Gerncia de Tempo: Envolve os processos requeridos para garantir o trmino do projeto no tempo certo. Os pro-
cessos desta fase so: identificar as atividades que devem ser feitas, arrum-las em uma seqncia lgica, estimar a
durao de cada atividade, desenvolver um calendrio que exibe estas atividades em funo do tempo, e monitorar,
controlar e modificar o calendrio com o passar do tempo.
o Definio de atividades
o Sequenciamento de atividades
o Estimativa de durao das atividades
o Desenvolvimento de cronograma
o Controle de cronograma
Gerncia de Custo: Envolve os processos requeridos para garantir o trmino do projeto dentro do oramento apro-
vado. Inclui o planejamento de recursos, estimativas e controle do budget. Na apurao de custos de software, o mo-
delo de custos uma frmula, ou uma srie de frmulas, usada para prever os custos que provavelmente recairo so-
bre o projeto.
o Planejamento de recursos
o Estimativa de custos
o Oramento de custos
o Controle de custos
Gerncia da Qualidade: Envolve os processos requeridos para assegurar que o projeto ir satisfazer as necessida-
des para o qual foi criado. Isto inclui "todas" as atividades de gerncia geral que determina os objetivos, a poltica e
as responsabilidades em relao qualidade e suas implementaes tais como: planejamento, controle, garantia e
melhoria de qualidade dentro do sistema de qualidade.
o Planejamento de qualidade
o Garantia de qualidade
o Controle de qualidade
Gerncia de Recursos Humanos: Envolve os processos requeridos para tornar o uso mais efetivo das pessoas que
esto envolvidas no projeto. Isto inclui todos os stakeholders. Faz parte desta rea os processos de aquisio de
membros, desenvolvimento das equipes e motivao.
o Planejamento organizacional
o Aquisio de equipe (staff)
o Desenvolvimento de equipe
100
Gerncia de Comunicao: Envolve os processos requeridos para assegurar a gerao, coleo, disseminao, dis-
sertao, armazenamento e disposio final de informao de projeto adequada e apropriadamente. Prov as ligaes
acerca de pessoas, idias e informao que so necessrias para o sucesso do projeto. Todos os envolvidos devem
enviar e receber comunicaes na "linguagem" do projeto e devem entender como as comunicaes individuais afe-
tam o projeto como um todo.
o Planejamento de comunicaes
o Distribuio de informaes
o Relatrios de desempenho
o Encerramento administrativo
Gerncia de Risco: Evolve os processos relacionados identificao, anlise e resposta aos riscos de projetos. Isso
inclui maximizar os resultados de ocorrncias positivas e minimizar as conseqncias de eventos adversos. Um pla-
no de risco inclui as tcnicas para identificar o risco, identificar responsabilidades, estabelecimento dos resultados e
relatrios detalhados.
o Planejamento do gerenciamento de riscos
o Identificao de riscos
o Anlise quantitativa de riscos
o Monitoramento e controle dos riscos
Gerncia de Aquisio: Envolve os processos requeridos para adquirir bens e servios externos organizao.
Tambm chamado de Gerncia de Compras e Subcontratao.
o Planejamento das aquisies
o Planejamento das solicitaes
o Seleo dos fornecedores
o Administrao do Contrato
o Encerramento do Contrato

Anlise de Risco
A anlise de risco do PMBOK envolve definir a tripla (risco, probabilidade, impacto) para cada risco, bem como os impactos
de ocorrncias conjuntas de alguns riscos. Deve-se ainda definir limiares dos riscos, ou seja, a regio ou valores em que pode
ser tomada tanto a deciso de prosseguir quanto a de interromper o projeto diante da ocorrncia dos riscos.
Um produto do processo de anlise de risco a tabela de riscos. A anlise de risco ainda envolve a definio de planos de
contingncia para orientar as aes que devem ser tomadas diante da ocorrncia dos riscos. Esses riscos envolvem tanto ris-
cos tecnolgicos quanto de negcio e organizacionais.

Stakeholders
Stakeholders so indivduos e organizaes ativamente envolvidos no projeto, cujos interesses so afetados (positiva ou nega-
tivamente) por ele, ou que exercem influncia sobre o mesmo. Incluem o gerente de projeto, o cliente, a organizao que far
o projeto, os membros da equipe de projeto, o patrocinador (indivduo/grupo interno ou externo que prov os recursos finan-
ceiros para o projeto). Inclui tambm partes internas e externas, como fundadores, vendedores, fornecedores, agncias gover-
namentais, comunidades afetadas pelo projeto e a sociedade em geral. uma boa prtica identificar cada uma das partes en-
volvidas no projeto, identificar e gerenciar possveis reas de conflito entre elas. Uma orientao geral resolver as diferen-
as entre as partes favorecendo o cliente.
O projeto deve levar em conta as seguintes questes ambientais ou scio-econmicas:
Padres e regulamentos
Questes pertinentes internacionalizao, quando for o caso.
Questes de diferenas culturais (polticas, econmicas, ticas, tnicas, religiosas, etc), quando for o caso.
Sustentabilidade social (econmica e ambiental)
101

Ciclo de Vida do Projeto
O conjunto de fases do projeto chamado ciclo de vida do projeto. De um modo geral, as fases do projeto apresentam as
seguintes caractersticas:
Cada fase do projeto marcada pela entrega de um ou mais produtos (deliverables), como estudos de viabilidade ou
prottipos funcionais.
No incio de cada fase define-se o trabalho a ser feito e o pessoal envolvido na sua execuo. O fim da fase marca-
do por uma reviso dos produtos e do desempenho do projeto at o momento
Uma fase comea quando termina a outra. Quando h overlapping entre as fases, chamamos essa prtica de "fast
tracking": nesses casos, comea-se a trabalhar nas prximas fases do projeto antes do fim da fase corrente (entrega e
reviso dos produtos).
Os custos so geralmente crescentes a medida em que a fase avana.
Os riscos so geralmente decrescentes a medida em que a fase avana.
A habilidade das partes envolvidas alterarem os produtos de cada fase decrescente a medida em que a fase avana.

Estrutura da Organizao
A estrutura da organizao executora freqentemente restringe a disponibilidade ou as condies sob as quais os recursos se
tornam disponveis para o projeto. Podem existir diversos modelos de estruturas:
Funcional: a clssica hierarquizada onde cada funcionrio tem um superior bem definido, e so agrupados por es-
pecialidade (engenharia, marketing, contabilidade). Os departamentos so independentes, e os projetos dependem
dos gerentes funcionais, onde est a coordenao do projeto.
Projetizada: Os membros das equipes freqentemente trabalham juntos, e a maioria dos recursos est envolvida em
projetos, e os gerentes de projeto tm grande autoridade e independncia.
Matricial: uma mistura das caractersticas funcional e projetizada.
o Fraca: o papel do gerente de projetos mais de um coordenador. Parecido com funcional.
o Forte: o papel do gerente de projetos mais autoritrio e dedicado. Parece com projetos.

Projetos de Software

Estrutura de decomposio de trabalho (WBS)
Em Gerncia de projetos, uma Work breakdown structure (WBS) uma ferramenta de decomposio do trabalho do projeto
em partes manejveis. estrutura em rvore exaustiva, hierrquica (de mais geral para mais especfica) de deliverables e tare-
fas que precisam ser feitas para completar um projeto. Em portugus, s vezes traduzida como Estrutura Analtica do Proje-
to, embora o termo WBS seja mais amplamente utilizado.
O objetivo de uma WBS identificar elementos terminais (os itens reais a serem feitos em um projeto). Assim, a WBS serve
como base para a maior parte do planejamento de projeto.
A Work Breakdown Structure uma ferramenta bastante comum. Vrias resolues de trabalho do governo dos Estados Uni-
dos o tm como requerimento. A WBS no criada apenas para o gerente do projeto, mas para toda a equipe de execuo do
projeto.
A WBS deve ser completa, organizada e pequena o suficiente para que o progresso possa ser medido, mas no detalhada o
suficiente para se tornar, ela mesma, um obstculo para a realizao do projeto.
Uma boa heurstica a seguir a regra do 8-80: exige-se que uma tarefa ocupe entre 8 e 80 horas de durao. uma das partes
mais importantes no plano do projeto. Ela serve como entrada para o desenvolvimento da agenda, atribuir funes e respon-
sabilidades, gerenciar riscos, entre outros.
Um exemplo simples de work breakdown structure para pintar um quarto (orientado a atividades) :
102
Preparar materiais: Comprar tinta, Comprar escada, Comprar pincis / rolos / removedor de papel de parede.
Preparar sala: Remover papel de parede antigo, Remover decoraes destacveis, Cobrir cho com jornais velhos,
Cobrir tomadas com fita, Cobrir mveis com lenis velhos, Pintar a sala.
Limpar a sala: Jogar fora, ou guardar a tinta que sobrou, Limpar pincis e rolos, Jogar fora jornais velhos, Remover
e limpar lenis.
O tamanho da WBS no deve exceder 100-200 elementos terminais (se mais elementos terminais so requeridos, use subpro-
jetos). A WBS deve ter de 3 a 4 nveis de profundidade. Essas sugestes derivam do fato que a nossa memria de curto prazo
limitada de 5 a 9 itens, e tendo terminado o tempo de planejamento de um projeto, quanto mais elementos terminais existi-
rem, menos tempo sobra para prestar ateno em cada um deles. Conseqentemente, as estimativas so menos pensadas.

Planejamento
O planejamento uma das atividades fundamentais do processo de gerenciamento de software. No planejamento so coloca-
dos estimativas de esforo humano (pessoas-ms), durao cronolgica (em tempo de calendrio) e custo (em moeda). Em
suma, planejar estimar.

Acompanhamento e Controle
O acompanhamento e controle de um projeto de software uma atividade de anlise de risco.
Na especificao de um cronograma devemos estabelecer prazos para o esforo de desenvolvimento.
Dois mtodos de determinao de cronograma so:
PERT Program Evaluation and Review Technique (mtodo de avaliao e reviso de programa).
CPM Critical Path Method (mtodo do caminho crtico).
Em ambas as tcnicas existem uma rede de tarefas a serem desenvolvidas desde o comeo at o final do projeto. A rede
definida ao se desenvolver uma lista de todas as tarefas associadas a um projeto especfico e uma lista de disposies que
indica em que ordem as tarefas devem ser executadas. As duas tcnicas permitem:
Determinar o caminho crtico cadeia de tarefas que determina a durao do projeto.
Estabelecer as estimativas de tempo provveis para tarefas individuais ao aplicar modelos estatsticos.
Calcular limites de tempo que definam uma janela de tempo para uma tarefa em particular.

Grfico de Gantt
O grfico de Gantt constitui-se de uma tima ferramenta para representar o cronograma do plano do projeto. Permite uma
comparao entre o previsto e o realizado, mostrando o andamento do projeto no tempo. Ele deve aparecer em dois nveis
distintos, no mnimo:
Cronograma Mestre: representando as
atividades sumrias. Este cronograma
d uma viso geral dos prazos do proje-
to, mostra sua durao total e interessa
principalmente ao usurio ou superiores
nos nveis estratgicos ou ttico de de-
cises.
Cronograma Parcial: representando o
detalhamento das atividades sumrias.
Este cronograma relaciona as atividades
e usa uma escala de tempo menor do
que no cronograma mestre, ele interessa
mais aos componentes do projeto para
controle operacional.


103
Ferramentas de Controle de Qualidade
Algumas das ferramentas bsicas para as melhorias da qualidade em uma organizao so:
Formulrio de dados: os dados devem traduzir os fatos e devem ser a base da discusso e das aes de projetos de
melhoria. Isto mostra a importncia de se planejar muito bem o tipo de formulrio que dever ser usado para coletar
os dados, o qual deve ser adaptado a cada situao. Existem, porm, alguns tipos bsicos de formulrios, que podem
ser teis em muitos casos: check-sheet, data sheet e checklist.
Diagrama de Pareto: uma figura simples que visa dar uma representao grfica estratificao. O modelo eco-
nmico de Pareto foi traduzido para a rea da qualidade. Este princpio tambm conhecido como "Lei 20/80" pode
ser detalhado nas mais variadas formas. Dentre elas, podem ser citadas: 20% do tempo gasto com itens importantes
responsvel por 80% dos resultados; 20% do tempo gasto em planejamento economiza at 80% do tempo de execu-
o; 20% dos clientes representam 80% do faturamento global; 20% dos correntistas so responsveis por 80% dos
depsitos; 20% das empresas detm 80% do mercado; 20% dos defeitos so responsveis por 80% das reclamaes;
e 20% dos clientes so responsveis por 80% das vendas. Em linhas gerais, o que o diagrama de Pareto sugere que
existem elementos crticos e a eles deve-se prestar total ateno. Usa-se, assim, um modelo grfico que os classifica
em ordem decrescente de importncia, a partir da esquerda.
Fluxograma: um diagrama que representa o fluxo (ou seqncia) das diversas etapas de um processo qualquer. Ao
iniciar um projeto de melhoria, sua grande utilidade fazer com que todos os participantes adquiriam uma viso
completa do processo, ao mesmo tempo que permite que cada pessoa tenha melhor percepo de qual o seu papel no
processo e de como seu trabalho influi no resultado final. Uma outra forma de utiliz-lo fazer o fluxograma de co-
mo as atividades esto sendo feitas na prtica e compar-lo com o fluxograma de como as atividades deveriam estar
sendo feitas. Isto pode revelar a origem de alguns problemas. Podem ser usados quaisquer smbolos ou desenhos,
desde que o entendimento seja fcil para todos.
Diagrama de Ishikawa: tambm conhecida por vrios outros nomes: diagrama causa-efeito, diagrama espinha de
peixe, diagrama 4M, diagrama 5M, sendo uma ferramenta de valor indispensvel, pois permite conhecer os proble-
mas cada vez mais a fundo. Pode ser facilmente aprendida e imediatamente posta em prtica por pessoas de qualquer
nvel dentro da empresa. Embora possa ser utilizada individualmente, a principal qualidade do diagrama de Ishikawa
sua capacidade de "focalizar" a discusso em grupo, estimando a participao de todos e direcionando o conheci-
mento de cada pessoa no sentido de identificar as causas ou os fatores responsveis por um dado problema ou situa-
o (efeito). Permite, assim, a organizao das idias e sua visualizao agrupada destacando as reas mais significa-
tivas. Existem trs tipos de diagrama causa-e-efeito, definidos por Ishikawa: anlise de disperso, classificao de
processo e enumerao de causas.
Histograma: baseia-se na idia de que cada fenmeno tem seu jeito prprio de variar. Ento, pode-se visualizar esta
variao, obtendo muita informao til sobre o fenmeno. O histograma exatamente isto: uma representao gr-
fica que nos permite visualizar a distribuio caracterstica de um fenmeno ou processo.
Grfico de Shewhart: uma das mais fortes ferramentas para controlar processos e indicar oportunidades de melho-
rias nos mesmos. A capacidade das coisas variarem e formarem um padro tpico de variao, uma das leis mais
fundamentais da natureza: tudo varia, impossvel prever um resultado individual, contudo, um grupo de resultados,
vindos do mesmo conjunto de causas, tende a ser previsvel, seguindo uma certa distribuio; quando um conjunto
de causas perturbado por causas externas, a distribuio de resultados se altera.
Grfico de correlao: permite a avaliao da relao existente entre duas variveis, parmetros ou caractersticas
de interesse. Como exemplo, pode ser citado o estudo da relao entre o peso de uma pessoa e sua altura. Se for ob-
tido o peso e a altura de vrias pessoas, o grfico de correlao poder representar em cada ponto uma pessoa. A ca-
racterstica altura uma varivel independente, pois a idia obter o peso de uma pessoa dada sua altura. O peso a
varivel dependente. medida que os dados apresentem uma tendncia, ou comportamento razovel previsvel, po-
de-se dizer que as variveis tm correlao. A tendncia mais comum o comportamento linear, ou seja, os pontos
tendem a se alinharem e com isso pode-se imaginar uma reta que representa a correlao entre essas variveis.

Coleta de Mtricas de Software
Medies e mtricas auxiliam a entender o processo usado para se desenvolver um produto. O processo medido a fim de
melhor-lo e o produto medido para aumentar sua qualidade.
As medidas so uma forma clara de avaliao de produtividade no desenvolvimento de software. Atravs da obteno de
medidas relativas produtividade e qualidade, possvel que metas de melhorias no processo de desenvolvimento sejam
estabelecidas como forma de incrementar estes dois fatores.
104
Mtricas de software referem-se a uma ampla variedade de medidas de software. O gerenciamento de projeto preocupa-se
com mtricas de produtividade e de qualidade medidas do resultado do desenvolvimento de software como uma funo do
esforo aplicado e medidas da adequao ao uso do resultado que produzido.
Podemos dividir o domnio das mtricas de software em:
Mtricas de produtividade: concentram-se na sada do processo de engenharia de software com o objetivo de ava-
liar o prprio processo.
Mtricas de qualidade: oferecem uma indicao de quo estreitamente o software conforma-se s exigncias impl-
citas e explcitas do cliente.
Mtricas tcnicas: concentram-se nas caractersticas do software (exemplo: complexidade lgica e modularidade).
Ou ainda podemos dividir o domnio das mtricas de uma outra forma:
Mtricas orientadas ao tamanho: medidas so derivadas a partir de atributos de tamanho do software como linhas
de cdigo (LOCs), esforo, custo, quantidade de documentao (PODs), etc...
Mtricas orientadas para a funo: oferecem medidas indiretas. Ex: a Anlise de Pontos por Funo (APF)
Mtricas orientadas s pessoas: usam informaes sobre a maneira pela qual as pessoas desenvolvem software e
percepes humanas sobre a efetividade das ferramentas e mtodos.

Estimativa de tamanho de software
As mtricas de tamanho de software surgiram com o objetivo de estimar o esforo(nmero de pessoas-hora) e o prazo associ-
ados ao desenvolvimento de sistemas. Para saber o custo de um projeto de software precisamos saber o esforo necessrio
para desenvolv-lo e para determinar o esforo precisamos saber o tamanho do projeto de software.
Existem vrias tcnicas de estimativas de tamanho de software, e a seguir so apresentadas as mais importantes:
COCOMO: modelo desenvolvido para estimar o esforo de desenvolvimento, prazos e tamanho da equipe para pro-
jetos de software. Utiliza equaes desenvolvidas por Boehm (BARRY,1981) para prever o nmero de programado-
res-ms e o tempo de desenvolvimento; podem ser calculados usando medidas de linhas de cdigo ou Pontos de
Funo. Devem ser realizados ajustes nas equaes a fim de representar as influncias sobre os atributos, hardware e
software durante o ciclo de vida do projeto. Uma desvantagem desta tcnica que os coeficientes da mtrica
(a,b,c,d) no so aplicveis a tamanho ou seja a produtividade diferente, o que torna difcil realizar comparaes.
Linhas de Cdigo (LOC): a tcnica de mensurao por linhas de cdigo uma das mais antigas medidas de tama-
nho de projeto de desenvolvimento de software. Ela consiste na contagem da quantidade de nmero de linhas de c-
digo de um programa de software. Alm de ser muito simples tambm muito fcil automatizar sua implementao,
mas, apresenta algumas desvantagens dentre as quais citamos: a dependncia da linguagem de software e do desen-
volvedor; ausncia de padro de contagem e o fato de somente poder ser aplicada na fase de codificao.
Metricas de Hasltead: um conjunto de mtricas proposto por Maurice Halstead (HASLTEAD,1977). O princpio
desse mtodo est na anlise e quantificao de operandos e operadores e no conceito de que a partir do conhecimen-
to das medidas, consegue-se quantificar os vocbulos e a extenso do algoritmo do estudo.
Puttnams Slim Model: um modelo de estimativa que busca medir esforo e prazo atravs da dinmica de mlti-
plas variveis que pressupe distribuio de esforos especficos ao longo da existncia de um projeto de software.
Relaciona o nmero de linhas de cdigo ao tempo e esforo de desenvolvimento. Uma desvantagem da tcnica sua
vinculao linguagem usada e a exigncia de certo tempo para obter valores reais para os parmetros da frmula.
Delphi: uma tcnica que se resume consulta de especialistas de determinada rea, em determinada linguagem
e/ou determinado assunto para que, usando sua experincia e entendimento do projeto proposto, faam estimativas
devidas. Devem ser feitas vrias estimativas do mesmo projeto, pois comum que elas carreguem influncias e ten-
dncias dos especialistas. um mtodo emprico, baseado em experincias profissionais que podem ser subjetivas.
PSP (Personal Software Process): uma tcnica derivada do SEI-CMM (Software Engineering Institute Capabi-
lity Matutiry Model) que foi desenvolvida com a funo de capacitar, melhorar e otimizar o processo individual de
trabalho. A tcnica divide-se em sete etapas, sendo que nas etapas PSP0, PSP0.1 e PSP1 estima-se o tamanho e o
tempo necessrio para o desenvolvimento do produto.
PCU (Pontos por Caso de Uso): foram criados por Gustav Karner em 1993 como uma adaptao especfica dos
Pontos de Funo para medir o tamanho de projetos de software orientados a objeto. Explora o modelo e descrio
do caso de uso, substituindo algumas caractersticas tcnicas proposta pelos Pontos de Funo. um mtodo simples
105
e de fcil utilizao mas ainda esta em fase de pesquisas e no existem regras de contagem padronizadas. Tm se es-
tudado a aplicao em conjunto da PCU e APF tentando explorar a relao entre elas existente.(EDMIA,2004)
Anlise por Pontos de Funo: Busca medir a complexidade do produto pela quantificao de funcionalidade ex-
pressa pela viso que o usurio tem do mesmo. O modelo mede o que o sistema, o seu tamanho funcional e no
como este ser, alm de medir a relao do sistema com usurios e outro sistemas. independente da tecnologia u-
sada e mede uma aplicao pelas funes desempenhadas para/e por solicitao do usurio final.; podendo tambm
ser usada em estimativas.
Contagem de Pontos de Funo segundo o NESMA: Alm do IFPUG, o NESMA tambm promove o uso de pon-
tos de funo e publica o seu prprio manual de contagem complacente com o manual do IFPUG. O manual da
NESMA apresenta trs tipos de contagens por pontos de funo: a contagem indicativa de ponto de funo, a conta-
gem estimada de ponto de funo e a contagem detalhada de pontos de funo. A contagem indicativa muito usada,
nela so identificados os grupamentos de dados relativos natureza do negcio, conforme a viso do usurio. Estes
grupamentos so classificados como Internos (mantidos pela aplicao e Externos (referenciados ou consultados pe-
la aplicao). Para calcular o tamanho de uma aplicao em Pontos de Funo no Ajustados (PFNA) a NESMA re-
comenda a seguinte frmula: PFNA = ( 35 * I) + ( 15 * E ).

Anlise de Pontos por Funo (APF)
um mtodo padronizado para a medio de projetos de desenvolvimento de software, visando estabelecer uma medida de
tamanho, em Pontos de Funo (PF), considerando a funcionalidade implementada, sob o ponto de vista do usurio (produti-
vidade). Os objetivos da APF so:
medir a funcionalidade requisitada e recebida pelo usurio;
medir projetos de desenvolvimento e manuteno de software, independente da tecnologia a ser implementada.
As organizaes podem aplicar a Anlise de Pontos por Funo como:
uma ferramenta para determinar o tamanho do pacote de software adquirido atravs da contagem de todos os Pontos
por Funo includos no pacote.
uma ferramenta para apoiar a anlise da qualidade e da produtividade.
um mecanismo para estimar custos e recursos envolvidos em projetos de desenvolvimento e manuteno de softwa-
re, alm de um fator de normalizao para comparao de software.
A tcnica Anlise de Pontos por Funo de grande utilidade para garantir a completeza da especificao de requisitos. Uma
contagem de Pontos de Funo realizada usando a informao contida na especificao do sistema sob a viso do usurio,
que representa uma descrio formal das necessidades do negcio na sua linguagem. Assim, contagem pode servir como uma
reviso dos requisitos do sistema com o usurio.
A APF tambm pode ser utilizada para estabelecer medies para a gerncia de requisitos, como indicadores para apoiar o
controle da estabilidade e rastreabilidade de requisitos e anlise de impacto das mudanas.
O gerente de projetos pode utilizar APF para aferir as mudanas de requisitos no decorrer do desenvolvimento, realizando
uma recontagem e gerando novas estimativas. Para melhorar a preciso das estimativas dos novos projetos, a organizao
deve utilizar um banco de dados histrico, contendo atributos de projetos anteriores.

106

COCOMO
Um mtodo de estimativas o COCOMO (COnstructive COst MOdel), que foi desenvolvido por Barry Boehm, para estimar
esforo, prazo, custo e tamanho da equipe para um projeto de software.
O mtodo foi derivado de um data set que compreendia 63 projetos cobrindo reas como: negcios, controle, cientfica, su-
porte e sistema operacional. O COCOMO classifica o projeto em 3 tipos:
Modelo Orgnico (Convencional): software de aplicao, equipes pequenas, desenvolvimento "in-house".
Semidestacado (Difuso): software utilitrio ou bsico, equipe com experincia mdia em aplicaes relacionadas.
Embutido (Restrito): software de sistema, grandes restries de operao, especificaes rgidas, prazos curtos.
Alm disso algumas de suas caractersticas so:
O COCOMO supe que no haver alteraes substanciais nas especificaes de requisitos do Sistema.
necessrio levantar as caractersticas de todos os projetos j desenvolvidos na instalao.
A medida do tamanho do projeto dada em KDSI (Thousands of Delivered Source Instructions).
Permite estimativas com 20% de variao em relao ao custo real e com 30% de variao em relao ao prazo.
Alm disso consiste em trs implementaes (COCOMO Bsico, Intermedirio e Avanado)

Implementao Bsica
um modelo esttico que calcula o esforo de desenvolvimento de software e seu custo, em funo do tamanho de linhas de
cdigos desenvolvidas.

Onde E o esforo aplicado pela pessoa no ms, D o tempo de desenvolvimento em meses cronolgicos, KLOC o nmero
calculado de linhas de cdigo para o projeto (expressado em milhares), e P o nmero das pessoas necessrio. Os coeficien-
tes ab, bb, cb e db so dados na seguinte tabela:
Projeto de Software ab bb cb db
Incio 2.4 1.05 2.5 0.38
Meio 3.0 1.12 2.5 0.35
Fim 3.6 1.20 2.5 0.32
Cocomo bsico bom por ser rpido em estimativas e custos de software, mas sua exatido limitada por causa de sua falta
de fatores para explicar as diferenas entre ferramentas, qualidade de pessoal e experincia, uso de ferramentas modernas e
tcnicas, e outros atributos de projeto que influenciam nos custos de software.
Pode-se conseguir um software interativo auxiliar na estimativa de custos e prazos de projetos de sistemas. A partir de um
conjunto de atributos, premissas e modos de desenvolvimento o COCOMO estima os prazos, custos e recursos necessrios
para cada estapa do ciclo de vida do produto.

Implementao Intermediria
Calcula o esforo de desenvolvimento de software em funo do tamanho do programa, que inclui custo, avaliao subjetiva
do produto, ferramentas, pessoal e atributos de projeto.

107
Onde E o esforo aplicado em pessoas por ms, LOC o nmero de linhas de cdigo para o projeto e EAF o fator calcu-
lado acima. Os coeficientes ai e o bi so dados na prxima tabela.
Projeto de Software ai bi
Incio 3.2 1.05
Meio 3.0 1.12
Fim 2.8 1.20
O mtodo intermedirio uma extenso do mtodo bsico, mas com mais categorias de controle como: Atributos do produto,
Atributos de hardware, Atributos pessoais, Atributos do projeto.

Implementao Avanada
Tambm conhecido como Implementao Detalhada. So incorporadas caractersticas da verso intermediria com uma ava-
liao de impacto de custo em cada passo de todo o projeto. Apresenta tcnicas para estimar tanto em nvel de mdulo, como
subsistema e Sistema, individualizando, a cada fase do projeto, os atributos de Custo.

Anlise de Desempenho
A avaliao de desempenho de sistemas computacionais consiste em um conjunto de tcnicas e metodologias que permitem
responder questo de como se obter o melhor desempenho de um sistema computacional a um dado custo. A atividade de
avaliao de desempenho compreende:
Seleo de tcnicas de avaliao, mtricas de desempenho e cargas de trabalho;
A correta conduo das medidas de desempenho e das simulaes;
A utilizao de tcnicas estatsticas apropriadas para comparar as diversas alternativas;
O desenvolvimento dos experimentos de medio e simulao visando prover a maior quantidade de informao
com o menor esforo;
A utilizao de modelos de filas para analisar o desempenho dos sistemas.

Modelos Analticos
Um modelo analtico uma construo matemtica que representa aspectos-chave de um sistema computacional. Estes mode-
los so uma ferramenta excelente para uma rpida avaliao de um produto novo ou modificado.
Modelo de Fila: um modelo de fila representa um sistema como um conjunto de centros de servio que processam
requisies de clientes, denominadas tarefas, transaes ou chegadas. Os centros de servios podem ser qualquer re-
curso ativo como a CPU, o disco ou a conexo de rede. Os modelos de fila podem prever a latncia, a vazo e a utili-
zao do sistema e seus componentes.
Modelo Assinttico: a aplicao mais simples de redes de filas. So utilizados para prever o melhor e o pior caso
de latncia e vazo de um nico centro de servios. Um uso tpico examinar o comportamento do ponto de conten-
o de um conjunto de recursos sob diferentes cargas.
Modelo de Rede Aberta: neste modelo, os clientes passam atravs do sistema uma nica vez. Por exemplo, um dis-
positivo de rede processando um fluxo de pacotes pode ser modelado com um sistema aberto. O nmero de clientes
do sistema calculado pela taxa de chegada de clientes e as caractersticas do centro de servio. Se existirem tipos
diferentes de clientes, um modelo aberto de mltiplas classes poder ser utilizado.
Modelo de Rede Fechada: neste caso, o nmero de clientes fixo. O exemplo clssico o sistema computacional
de tempo compartilhado com um nmero fixo de terminais de usurio. Neste modelo, o nmero de clientes conhe-
cido e a vazo calculada. Um mtodo interativo conhecido como Anlise do Valor Mdio (Mean Value Analysis ou
MVA) usado para calcular vazo e latncia. A exemplo dos modelos abertos, os modelos fechados podem ser de
classe nica ou de mltiplas classes. As duas variaes do algoritmo MVA so: soluo exata e soluo aproximada.
Cadeias de Markov: so usadas para modelar sistemas como um conjunto finito de estados com uma taxa conheci-
da de transies entre os estados. Este modelo adequado para prever a disponibilidade de um sistema, dadas as ta-
108
xas de falha de um componente e as taxas de recuperao. Tambm podem ser usadas para modelar buffers de filas
que armazenam um pequeno nmero de itens idnticos.

Simulao
Conceitualmente, a simulao modela um sistema do mundo real como um programa de computador. A simulao permite
que um sistema seja modelado em qualquer nvel de detalhe: de uma traduo direta de um modelo de redes de filas captura
de todo aspecto do comportamento do sistema. A simulao suporta qualquer coleo de mtricas de desempenho que possam
ser definidas. Existem trs tcnicas bsicas para gerar cargas de trabalho para realizar simulaes:
Simulao Estocstica: descreve a chegada de padres de clientes e outros aspectos da carga por amostragem a par-
tir de uma distribuio probabilstica. Muitas cargas podem ser descritas precisamente pelo uso de uma distribuio
apropriada. As cargas estocsticas so uma boa escolha quando a informao detalhada sobre a carga no est dispo-
nvel ou quando existe necessidade de variar as caractersticas da carga. A gerao de carga eficiente e no necessi-
ta de grandes arquivos de dados.
Simulao por rastreamento: representa a carga como uma sequncia de operaes ou requisies. Por exemplo,
para a simulao de um servidor Web, uma sequncia de requisies http deve ser rastreada, enquanto na simulao
de uma CPU, as operaes do micro-cdigo devem ser rastreadas. Se dados de rastreamento que representam corre-
tamente a carga esto disponveis, obteremos bons resultados de simulao, sendo desnecessrio escrever o cdigo
que modela a carga. A desvantagem desta tcnica que montar uma coleo de rastreamentos um esforo no tri-
vial e o tamanho dos arquivos de dados muito grande.
Simulao baseada em execuo: utilizada para modelar processadores em detalhes. A entrada de uma simulao
baseada em execuo o mesmo cdigo executvel que seria processado no sistema real.
A principal desvantagem de utilizar qualquer tcnica de simulao o esforo necessrio para escrever e validar o programa
de simulao e os considerveis requisitos de processamento (tempo de CPU para todas as simulaes e espao em disco para
rastreamentos). Em geral, a simulao significativamente mais lenta do que um sistema real: uma hora de simulao pode
significar alguns poucos segundos do tempo real, mas pode ocorrer o contrrio.

Medio de Desempenho
Devemos considerar, ao planejar uma medio de desempenho, o propsito da medio, a seleo da carga de trabalho e sua
implementao, os dados a serem coletados, a instrumentao utilizada na coleta destes dados e a forma de validao dos
resultados. Todos os experimentos de medio de desempenho requerem trs elementos bsicos: o sistema sob teste, os gera-
dores de carga de trabalho e a instrumentao que ir coletar os dados de desempenho.
Benchmarks so uma categoria importante de cargas sintticas, definindo no somente a carga de trabalho, mas as mtricas de
desempenho a serem coletadas e relatadas. Benchmarks desenvolvidos independentemente so sempre preferidos porque
permitem aos clientes compararem resultados de mltiplos fornecedores.
O sistema sob teste pode ser instrumentado para coletar uma variedade de mtricas. Muitos benchmarks simplesmente me-
dem a latncia e a taxa de servio. Entretanto, a informao sobre a utilizao do processador e de outros recursos muito til
na identificao de pontos de conteno no sistema ou para futuros esforos de modelagem. Existem contadores implementa-
dos tanto em software quanto em hardware que fornecem informao til de desempenho. Por exemplo, falhas de pgina po-
dem ser gravadas em um contador na CPU, no kernel do sistema operacional ou em ambos. Rastreamento das operaes ou
eventos tambm podem ser coletados.
O SPEC (Standard Performance Evaluation Corporation) uma organizao que busca estabelecer, manter e endossar um
conjunto padro relevante de benchmarks e mtricas de avaliao de desempenho.

Mtricas de Desempenho
Todas as mtricas de desempenho baseiam-se no comportamento do sistema ao longo do tempo. As trs classes principais de
mtricas que podem ser observadas por um usurio ou uma outra entidade externa ao sistema so:
Latncia ou Tempo de Resposta: que mede o atraso entre a requisio de alguma ao e a obteno do resultado.
medida em unidades de tempo decorrido, e deve especificar um evento de incio e um evento de trmino (exemplo:
tempo decorrido entre digitar um novo endereo em um navegador Web e a pgina ser completamente exibida).
109
Taxa de servio: que mede quantidade de trabalho realizado por unidade de tempo ou a taxa em que novos resulta-
dos so obtidos. Como exemplo, nmero de transaes completas por minuto, gigabytes de dados escritos em fita
por hora, nmero de acesso memria por segundo, e assim por diante.
Disponibilidade: que mede quanto tempo o sistema est disponvel para operao normal. Embora seja medida em
frao de tempo (ex: 0,96), ela sozinha no completa, necessitando da mtrica de confiabilidade MTBF (Mean Ti-
me Between Failures) que indica o perodo mdio em que um sistema utilizvel, e a mtrica MTTR (Mean Time to
Repair), que quantifica o tempo necessrio para recuperar o sistema de uma falha..
A quarta classe de mtrica, que seria a mtrica de utilizao, s pode ser observada de dentro do sistema. A informao de
utilizao vital para entender e prever o desempenho do sistema. Utilizao a frao de tempo em que um componente do
sistema, por exemplo, a CPU, o disco ou a rede realizou servio, em relao a um perodo de tempo observado. Segue dessa
definio que os valores de utilizao esto entre 0 e 1. Na prtica, o tempo de resposta aumenta rapidamente quando a utili-
zao atinge o mximo, por isso sistemas so projetados para manter uma utilizao abaixo da capacidade mxima (60-80%).

Planejamento de Capacidade
A metodologia de planejamento de capacidade de um software envolve o entendimento do ambiente, caracterizao da carga,
previso da carga e anlise de custo / desempenho, utilizando os seguintes modelos:
Modelo de custo: representado em termos monetrios, onde se avalia o custo do sistema atual (aquisio e manu-
teno). utilizado para avaliar o custo / benefcio de uma possvel atualizao do sistema, para definir se vivel
ou no financeiramente. Se trata de uma viso mais gerencial do processo de deciso.
Modelo de carga: baseado na utilizao dos recursos do sistema levando em conta a quantidade de recursos e suas
respectivas taxas de utilizao. Esses modelos so fortemente apoiados em modelos matemticos, para fazer uma re-
presentao o mais fiel possvel do ambiente real, para que o processo de avaliao de desempenho seja vlido.
Modelo de desempenho: trata de avaliar a situao atual do sistema, confrontando os recursos disponveis e a sua
utilizao pelos usurios. O modelo baseado em observaes sobre o comportamento do sistema, por um perodo
de tempo, de forma a caracterizar um padro de utilizao, para que se possa ter uma base de comparao que seria
utilizada como referncia em um cenrio de planejamento de capacidade.


110
Gesto e Recursos Informacionais
A rea de TI ampliou o seu domnio com o crescimento das redes de computadores e a sua utilizao voltado para negcios.
Na rea dos negcios on-line (E-business) existem as tecnologias de Data Warehousing e Data Mining, que baseiam-se na
busca de informaes estratgicas em grandes bancos de dados. Na mesma rea existem tambm aplicativos de atendimento
ao cliente, ou CRM, de planejamento de recursos empresariais, ou ERP e gerenciamento de recursos humanos, ou HRMS. Na
rea de comrcio eletrnico existem sistemas B2B, que so processos automatizados entre parceiros de negcios, e sistemas
B2C, que leva o negcio diretamente ao cliente, exemplificado pelas lojas virtuais (Amazon). Existe tambm a rea do marke-
ting eletrnico, que alm de incluir os sistemas CRM, tambm permite o marketing personalizado e promoes atravs da
Internet, diretamente ao consumidor, atuando s vezes de forma indesejvel, como por e-mails no solicitados (Spams).

Servio de TI
Um servio bem sucedido em TI um conjunto de facilidades sustentadas pelo fornecedor (do servio) que completa um ob-
jetivo do negcio do cliente.
As organizaes buscam na tecnologia da informao meios para ajud-las a se tornar mais eficientes e efetivas no seu neg-
cio. Usurios finais so os consumidores dos servios de TI, que cada vez exigem mais dos servios que utilizam em seu tra-
balho. Simultaneamente, as organizaes procuram em TI um aumento no valor do seu negcio e retorno do investimento.

O objetivo de uma cultura de servios garantir que a organizao de TI fornece os servios que alcanam as expectativas e
necessidades da organizao a um custo apropriado. Alm disso existem polticas que devem estar claras para cada membro
das equipes, que devem saber como conduzir uma tarefa especfica e lidar com diversas situaes. Tambm devem possuir
funes e responsabilidades bem definidas.

Funes de TI
De forma geral, as funes da rea de TI recaem em trs categorias:
Desenvolvimento: envolve o desenvolvimento dos softwares propriamente ditos. O CMMI um exemplo de mode-
lo de qualidade de processos dessa rea.
Operaes: refere-se s atividades dirias que devem ser executadas para manter a infra-estrutura de TI funcionando
adequadamente. A ISO e o ITIL so modelos aplicveis a essa funo.
Controle: envolve a habilidade para medir e auditor a performance de uma infra-estrutura de TI. O COBIT (segu-
rana, etc) e o SixSigma oferecem modelos para a funo de controle.

111
Modelos de Governana em TI: ITIL
ITIL (Information Technology Infrastructure Library) um conjunto de melhores prticas que ajudas as organizaes de TI a
entregar servios de alta qualidade que agregam valor a sua organizao.
ITIL consiste em uma biblioteca de livros que aborda tpicos relacionados ao Gerenciamento de Servios (Service Manage-
ment). recomendado que organizaes adotem uma viso holstica das capacidades de seus servios, tendo como principal
objetivo o provisionamento timo dos processos operacionais e de gerenciamento, para suportar os requisitos de negcio a
um custo justificvel. Segundo o modelo definido pelo ITIL, toda disciplina de um modelo de TI deve adotar tcnicas de se-
gurana dentro de seus prprios processos.
TI deve ajudar uma organizao em alcanar os seus objetivos estratgicos da maneira mais eficiente possvel. ITIL comple-
menta essa tarefa, ajudando as organizaes a manter o foco em seus objetivos. ITIL ajuda as organizaes a gerenciar de
forma apropriada toda a sua infra-estrutura, com uma contribuio e suporte timos. Alguns dos seus benefcios so:
Aumento da Qualidade e Melhora Contnua
Gerenciamento Financeiro Efetivo
Cultura de Servios
Processos trabalhando juntos e de forma consistente
Foco nos Servios e Negcios
Interface definida e Ferramentas integradas
As reas do Service Management Process so duas:
Service Support
Service Delivery

Service Support


112
Service Desk: atua como um ponto focal de contato para os usurios finais de uma organizao de TI, ajudando os
usurios a resolver problemas e restaurar a operao rapidamente. o comunicador entre os processos.
Incident Management: o primeiro processo executado pela funo do Service Desk, onde incidentes so detectar
e resolvidos. Um incidente pode ser definido como um evento que no parte da operao normal de um servio, e
que causa (ou pode causar) interrupo ou reduo na qualidade do servio.
Problem Management: o processo de detectar e remover erros de uma infra-estrutura de TI, analisando a causa
(root cause). Um problema um incidente ou conjunto de incidentes significativos com sintomas em comum que in-
dicam um erro simples. Problemas so erros na infra-estrutura, podendo levar a mais incidentes.
Change Management: o processo de controlar uma mudana aos itens de configurao (CI), garantindo que os
procedimentos apropriados so seguidos. Um Comit de mudanas (Change Advisory Board) responsvel por as-
sessorar o impacto tcnico e funcional da requisio da mudana (Change Request).
Release Management: aps as mudanas serem aprovadas no processo anterior, deve ser garantido que apenas itens
adequadamente testados e aprovados existam na infra-estrutura de TI, seguramente armazenada, controlada e distri-
buda para os itens de hardware e software correspondentes. Envolve tambm preparao e treinamento.
Configuration Management: o processo de rastrear todos itens da infra-estrutura de TI, identificando e relatando
os seus componentes, incluindo as verses, relacionamentos e componentes constituintes. A informao de todos os
itens de configurao (CI) devem ser mantidos em um banco de dados apropriado.

Service Delivery


Capacity Management: um processo que procura garantir as necessidades atuais e futuras da capacidade e de-
sempenho dos recursos. Aumentar a capacidade gera custos, mas mant-la abaixo do esperado pelos clientes tam-
bm, e o objetivo desse processo garantir um custo eficiente dimensionando a capacidade de forma correta.
Availability Management: o processo que busca otimizar a disponibilidade dos servios atravs de suporte pr-
ativo e reativo, em alinhamento com os requerimentos de negcios a um custo justificvel. Algumas de suas ativida-
des so: a monitorao, necessidade de manuteno e rastreamento da informao de gerenciamento (produo).
113
Service Level Management: um processo que alinha o provisionamento dos servios com os requerimentos de
negcio, quantificando negociando e monitorando o nvel dos servios. responsvel pela melhora no relaciona-
mento entre os servios de TI e os negcios. Um termo chave para este o SLA (Service Level Agreement).
IT Financial Management: processo que identifica, monitora, e se necessrio, rev os custos para fornecer servios
de TI. Um modelo de custo e sistema de budget permitem que decises referentes custos de TI sejam tomadas co-
mo qualquer deciso de negcio. O modelo de custo registra os custos dos clientes, atividades e servios.
IT Service Continuity Management: um processo que garante que a organizao possui a capacidade de restau-
rar os seus servios no caso de um desastre, alm de procurar reduzir riscos. Os servios crticos so identificados, as
suas vulnerabilidades e ameaas medidos.

Modelos de Auditoria em TI COBIT
O CobiT (Control Objectives for Information and related Technology) uma ferramenta eficiente para auxiliar o gerencia-
mento e controle das iniciativas de TI nas empresas.
O CobiT um guia para a gesto de TI recomendado pelo ISACF (Information Systems Audit and Control Foundation). O
CobiT inclui recursos tais como um sumrio executivo, um framework, controle de objetivos, mapas de auditoria, um conjun-
to de ferramentas de implementao e um guia com tcnicas de gerenciamento. As prticas de gesto do CobiT so recomen-
dadas pelos peritos em gesto de TI que ajudam a otimizar os investimentos de TI e fornecem mtricas para avaliao dos
resultados. O CobiT independe das plataformas de TI adotadas nas empresas.
O CobiT orientado ao negcio. Fornece informaes detalhadas para gerenciar processos baseados em objetivos de neg-
cios. O CobiT projetado para auxiliar trs audincias distintas:
Gerentes que necessitam avaliar o risco e controlar os investimentos de TI em uma organizao.
Usurios que precisam ter garantias de que os servios de TI que dependem os seus produtos e servios para os cli-
entes internos e externos esto sendo bem gerenciados.
Auditores que podem se apoiar nas recomendaes do CobiT para avaliar o nvel da gesto de TI e aconselhar o con-
trole interno da organizao.
O CobiT est dividido em quatro domnios:
Planejamento e organizao.
Aquisio e implementao.
Entrega e suporte.
Monitorao.

Processos do COBIT
Os mapas de controle fornecidos pelo CobiT auxiliam os auditores e gerentes a manter controles suficientes para garantir o
acompanhamento das iniciativas de TI e recomendar a implementao de novas prticas, se necessrio. O ponto central o
gerenciamento da informao com os recursos de TI para garantir o negcio da organizao.
Cada domnio cobre um conjunto de processos para garantir a completa gesto de TI, somando 34 processos:
Planejamento e Organizao
o Define o plano estratgico de TI
o Define a arquitetura da informao
o Determina a direo tecnolgica
o Define a organizao de TI e seus relacionamentos
o Gerencia os investimento de TI
o Gerencia a comunicao das direes de TI
o Gerencia os recursos humanos
o Assegura o alinhamento de TI com os requerimentos externos
114
o Avalia os riscos
o Gerencia os projetos
o Gerencia a qualidade
Aquisio e implementao
o Identifica as solues de automao
o Adquire e mantm os softwares
o Adquire e mantm a infra-estrutura tecnolgica
o Desenvolve e mantm os procedimentos
o Instala e certifica softwares
o Gerencia as mudanas
Entrega e suporte
o Define e mantm os acordos de nveis de servios (SLA)
o Gerencia os servios de terceiros
o Gerencia a performance e capacidade do ambiente
o Assegura a continuidade dos servios
o Assegura a segurana dos servios
o Identifica e aloca custos
o Treina os usurios
o Assiste e aconselha os usurios
o Gerencia a configurao
o Gerencia os problemas e incidentes
o Gerencia os dados
o Gerencia a infra-estrutura
o Gerencia as operaes
Monitorao
o Monitora os processos
o Analisa a adequao dos controles internos
o Prove auditorias independentes
o Prove segurana independente
o Desenvolvimento do CobiT

Ferramentas de Gerenciamento do COBIT
Na era da dependncia eletrnica dos negcios e da tecnologia, as organizaes devem demonstrar controles crescentes em
segurana. Cada organizao deve compreender seu prprio desempenho e deve medir seu progresso. O benchmarking com
outras organizaes deve fazer parte da estratgia da empresa para conseguir a melhor competitividade em TI. As recomen-
daes de gerenciamento do CobiT com orientao no modelo de maturidade em governana auxiliam os gerentes de TI no
cumprimento de seus objetivos alinhados com os objetivos da organizao.
Os guidelines de gerenciamento do CobiT focam na gerncia por desempenho usando os princpios do balanced scorecard.
Seus indicadores chaves identificam e medem os resultados dos processos, avaliando seu desempenho e alinhamento com os
objetivos dos negcios da organizao.
Os modelos de maturidade de governana so usados para o controle dos processos de TI e fornecem um mtodo eficiente
para classificar o estgio da organizao de TI. A governana de TI e seus processos com o objetivo de adicionar valor ao
negcio atravs do balanceamento do risco e returno do investimento podem ser classificados da seguinte forma:
115

0) Inexistente
1) Inicial / Ad Hoc
2) Repetitivo mas intuitivo
3) Processos definidos
4) Processos gerenciveis e medidos
5) Processos otimizados
Essa abordagem deriva do modelo de maturidade para desenvolvimento de software, Capability Maturity Model for Software
(SW-CMM), proposto SEI. A partir desses nveis, foi desenvolvido para cada um dos 34 processos do CobiT um roteiro:
Onde a organizao est hoje
O atual estgio de desenvolvimento da industria (best-in-class)
O atual estgio dos padres internacionais
Aonde a organizao quer chegar
Os fatores crticos de sucesso definem os desafios mais importantes ou aes de gerenciamento que devem ser adotadas para
colocar sobre controle a gesto de TI. So definidas as aes mais importantes do ponto de vista do que fazer a nvel estrat-
gico, tcnico, organizacional e de processo.
Os indicadores de objetivos definem como sero mensurados os progressos das aes para atingir os objetivos da organiza-
o, usualmente expressos nos seguintes termos:
Disponibilidade das informaes necessrias para suportar as necessidades de negcios
Riscos de falta de integridade e confidencialidade das informaes
Eficincia nos custos dos processos e operaes
Confirmao de confiabilidade, efetividade e conformidade das informaes.
Indicadores de desempenho definem medidas para determinar como os processos de TI esto sendo executados e se eles per-
mitem atingir os objetivos planejados; so os indicadores que definem se os objetivos sero atingidos ou no; so os indicado-
res que avaliam as boas prticas e habilidades de TI.

Sistemas de Gerenciamento eletrnico de documentos (GED)
O GED ou EDM (Electronic Document Management) a tecnologia que prov um meio fcil de armazenar, localizar e recu-
perar informaes existentes em documentos e dados eletrnicos, durante todo o seu "Ciclo de Vida".
A possibilidade de controlar e gerenciar documentos torna-se hoje uma necessidade estratgica para a competitividade. Cap-
turar, gerenciar, armazenar, preservar e distribuir documentos eficientemente possibilita s empresas tornarem os seus
negcios aptos s rpidas mudanas de mercado, aos mesmo tempo que aumenta a produtividade e reduz custos.
a tecnologia do GED que torna o eBusiness uma realidade, pois alicera todas as informaes referentes a qualquer etapa
de qualquer processo de negcio. No so simplesmente sistemas de gerenciamento de arquivos. O GED mais, pois ele im-
plementa categorizao de documentos, tabelas de temporalidade, aes de disposio e controla nveis de segurana. vital
para a manuteno das bases de informao e conhecimento das empresas.

Aspectos Tcnicos
A durao do ciclo de vida de um documento, bem como cada estgio, depende muito do tipo de documento, dos processos
de negcios, dos padres da indstria, e at mesmo do carter legal. Portanto, o correto entendimento do ciclo de vida e dos
padres de documentao em uma empresa so fatores crticos para se determinar os requisitos de um sistema de GED.
Quando se analisa sistemas GED, alguns aspectos tcnicos importantes devem ser cuidadosamente avaliados:
Gerenciamento: O sistema GED deve ser capaz de gerenciar qualquer formato eletrnico, incluindo diferentes for-
matos de imagens, textos, documentos compostos, arquivos eletrnicos, udio digital, vdeos etc.
116
Armazenamento: Um sistema GED deve suportar, idealmente, tanto o arquivamento off-line, quanto o on-line, em
diferentes mdias de armazenamento, desde mdias digitais como discos pticos, CD-ROM, discos magnticos, fitas,
at mdias tradicionais como microfilme e papel. O sistema deve gerenciar de forma segura o uso da mdia para o
armazenamento do documento, migrar documentos entre mdias quando definido pelo ciclo de vida, e fazer uso de
cache para acelerar a recuperao dos documentos mais utilizados;
Recuperao: O sistema deve permitir que os documentos armazenados sejam recuperados a partir de um conjunto
de atributos previamente definidos (metadados), mas tambm deve suportar a recuperao atravs de palavras e fra-
ses contidos nos documentos. A pesquisa deve ser realizada de forma unificada, de modo que os documentos sejam
acessados, recuperados, e visualizados independente do local de armazenamento;
Intercmbio: Visando o intercmbio de documentos entre a empresa e entidades sem acesso ao sistema GED, o
mesmo deve permitir o acesso a aplicaes de terceiros, permitindo que os documentos sejam extrados em seu for-
mato nativo, e transportados como desejado;
Internet: Todas as funcionalidades de um sistema GED, devem estar disponveis via Web.

Evoluo do GED
O GED um conjunto de tecnologias. Ele formado pelas seguintes tecnologias:
Document Imaging (DI): enfatiza basicamente a digitalizao de documentos de origem papel
Document Management (DM): ferramentas para controle de localizao, atualizao, verses e de temporalidade
de guarda dos documentos. uma das exigncias da ISO 9000, e permite a rastreabilidade das alteraes.
Workflow: substitu o processo humano de trmite de documentos em papel, muitos ganhos so obtidos.
COLD/ERM (Computer Output to Laser Disk): substitu os microfilmes, reduo no custo de armazenamento. De-
vido a abrangncia dessa tecnologia, ela passou a ser chamada de ERM (Enterprise Report Management).
Forms Processing: em vez da utilizao de digitadores para a retirada das informaes, utilizam-se sistemas digi-
tais. Outra tecnologia complementar o RIM (Records and Information Management).
Algumas das aplicaes do GED so: apoio aos processos de fiscalizao, auditoria, importao e exportao, cartes de as-
sinatura, processos judiciais, disponibilizao de dirios oficiais, controle de bilhetes, impostos, taxas, multas, extratos, entre
muitos outros. O GED tambm impulsiona outras tecnologias, como o Knowledge Management, CRM, ERP e SCM.

Sistemas Integrados de Gesto

ERP - Enterprise Resource Planning
ERP (Planejamento de Recursos Empresariais) so sistemas de informaes transacionais(OLTP) cuja funo armazenar,
processar e organizar as informaes geradas nos processos organizacionais agregando e estabelecendo relaes de informa-
o entre todas as reas de uma companhia. uma plataforma de software desenvolvida para integrar os diversos departa-
mentos de uma empresa, possibilitando a automatizao e armazenamento de todas as informaes de negcios.
Algumas vantagens e mudanas mais palpveis que um sistema de ERP propicia a uma corporao so:
Maior confiabilidade dos dados
Monitorao em tempo real dos dados
Diminuio do retrabalho
O passo a passo de um projeto para implantao do ERP :
Raio X: Esta a fase do projeto onde os processos e as prticas de negcio so analisados. o momento em que a
companhia profundamente observada e quando definida a necessidade de uma soluo ERP.
Desenvolvimento: neste momento que uma aplicao escolhida e configurada para uma companhia. Tambm
so definidos o modelo de funcionamento da soluo e outros aspectos do ambiente.
Teste: Aqui a soluo de ERP colocada em um ambiente de teste. quando os erros e falhas so identificados.
117
Treinamento: Todos os profissionais so treinados no sistema para saber como utiliza-lo antes da implementao
ser concluda.
Implementao: O software de ERP finalmente instalado na companhia e se torna funcional aos usurios.
Avaliao: A soluo de ERP avaliada, observando-se o que necessrio melhorar e o que est ou no funcionan-
do adequadamente. Esta apenas uma avaliao geral do projeto ERP para referncias futuras.
Mesmo tendo implantado sistemas de ERP, as empresas ainda tm as seguintes quatro principais dificuldades:
Quando necessitam de um documento, ele est arquivado em papel com as tradicionais limitaes do seu manuseio.
Os processos so lentos e no tm um "motor" que os movimente e que controle seu andamento, prazos e tarefas
dentro da empresa.
A quantidade de dados gerados pelo ERP aumentou muitas vezes o volume de informaes disponvel dentro da
empresa. Armazenar e consultar essas informaes de forma rpida e inteligente tornou-se um fator crtico.
A quantidade de documentos eletrnicos aumentou. necessrio o controle de verses, histrico de uso, segurana
de acesso e, principalmente, um enfoque corporativo de utilizao integrado aos processos de negcios do ERP.
A nica alternativa para superar essas dificuldades a utilizao das solues de GED - Gerenciamento Eletrnico de Docu-
mentos, integradas ao ERP. por isso que vrios fornecedores de ERP j estabeleceram parcerias com empresas de GED.
Implementar recursos de imagem, Gerenciamento Eletrnico de Documentos, workflow, COLD/ERM e Knowledge Mana-
gement integrados ao ERP, e via web, a soluo para aumentar a eficincia e produtividade na gesto do seu negcio, ge-
rando os indispensveis diferenciais de competitividade.

CRM - Customer Relationship Management
CRM um conceito que implica em mudanas nos processos e na cultura das empresas. Para sua efetivao, utiliza vrias
tecnologias que objetivam conhecer o cliente e atend-lo melhor, faz-lo comprar mais e ret-lo.
CRM uma estratgia de negcio voltada ao entendimento e antecipao das necessidades dos atuais clientes e daqueles po-
tenciais de uma empresa. Envolve captar todos os seus dados, consolid-los em um banco de dados, analis-los para identifi-
car padres, distribuir resultados para todos os pontos de contato e usar essas informaes para interagir com os clientes.
Entre as tecnologias usadas esto call center, a integrao de sistemas legados e sistemas de suporte deciso, como o GED.
O CRM, visto como uma aplicao, deve integrar mdulos de automao de vendas, gerncia de vendas, telemarketing, tele-
vendas, atendimento ao consumidor, solues para informaes gerenciais, web e comrcio eletrnico. A base de dados deve
ser alimentada com o apoio da documentao que diz respeito aos clientes. Isso cabe ao COLD, GED, workflow, ERP. Essas
tecnologias servem para tornar utilizveis as informaes sobre os clientes captadas das mais diferentes formas.
O workflow parte fundamental para a eficcia de um sistema de CRM. Com uma ferramenta de workflow ligando o call
center aos processos de negcio todas as solicitaes jamais se perdero. Se no forem atendidas no prazo estipulado, o work-
flow se incumbir de disparar alarmes para os mais diferentes nveis organizacionais.
Identificar e conhecer o cliente e suas necessidades, alm de garantir sua satisfao atravs de: atendimento personalizado,
maior ateno dedicada ou simplesmente o aumento da eficincia nos servios prestados; so alguns dos objetivos a serem
atingidos atravs do CRM. Podemos distinguir um projeto de CRM de acordo com sua abordagem ou tema, que pode ser:
Operacional: que visa principalmente melhorar o relacionamento direto entre a empresa e o cliente atravs de ca-
nais como a internet ou Call Centers. Tais melhorias so conseguidas agrupando informaes antes espalhadas pelos
diversos setores da empresa, definindo com maior preciso o perfil do cliente, o que permite que a empresa esteja
melhor preparada na hora de se relacionar com o mesmo;
Analtico: que trata da anlise das informaes obtidas sobre o cliente nas vrias esferas da empresa, permitindo
descobrir entre outras informaes o grau de fidelizao dos clientes, seus diferentes tipos, preferncias e rejeies
quanto a produtos e servios. A comparao entre um CRM de abordagem analtica com um Data Mart para o setor
Marketing e/ou vendas inevitvel, pois ambos auxiliam a responder importantes questes de negcio. Mas impor-
tante lembrar da necessidade de se ter bem definidas as estruturas de datamarts e datawarehouse, antes de comear a
construo da parte fsica ou ferramental de um CRM;
Colaborativo: esta abordagem do CRM procura integrar as estruturas e benefcios dos outros dois temas descritos.
Enquanto o CRM operacional est mais focado nos nveis ttico e operacional, e o CRM analtico nos nveis estrat-
gico e ttico, o CRM colaborativo procura gerar melhorias nos trs nveis. A principal caracterstica deste dessa a-
bordagem est na possibilidade de criar, aumentar e gerenciar a interao com o cliente. Para isso necessrio que a
118
empresa possua um meio adequado para a interao - abordada no CRM operacional - e que possua informaes su-
ficientes sobre seus clientes - obtidas atravs do CRM analtico - de forma centralizada e, claro, integrada.
Dentro das ferramentas de Business Intelligence, o CRM uma das mais importantes solues a ser implementada utilizando
as plataformas de datamarts e do datawarehouse.

Automao de processos de trabalho (Workflow)
Fluxo de Trabalho. a tecnologia que permite gerenciar de forma pr-ativa qualquer processo de negcio das empresas. Ga-
rante o acompanhamento constante de todas as atividades e um aumento de produtividade com objetividade e segurana.
O Workflow tambm atua como um integrador dos mais diversos sistemas e tecnologias: ERP, SCM (Supply Chain Mana-
gement), CRM, eBusiness e outras.
Sistemas de Workflow so programas destinados a suportar processos de negcio:
controlando a lgica que governa as transies entre as tarefas do processo.
suportando as tarefas individuais: ativando recursos humanos e recursos necessrios para completar a tarefa.
O Workflow melhora a eficincia do negcio, pois d a possibilidade de balancear as tarefas entre os funcionrios da empre-
sa, reduzindo custos (pessoal, papel) e ainda diminui o tempo para o usurio perceber que tem uma atividade.
So quatro os conceitos bsicos da tecnologia de Workflow:
Lgica do Processo: a representao computacional de um conjunto de passos de atividades discretas, associadas
com operaes humanas e/ou realizadas por computador e as regras que governam a progresso dessas atividades.
Relacionamento entre Pessoas e Tarefas: o sistema de workflow responsvel por atribuir tarefas que precisam
ser realizadas para as pessoas necessrias para execut-las.
Disponibilizao de recursos de informao necessrios para executar tarefas: os dois tipos de recursos podem
ser classificados em recursos humanos e recursos computacionais.
Gerenciamento de processos: torna a lgica dos processos explcita, permite coletar e avaliar mtricas relativas ao
tempo, custo, qualidade da execuo do processo e suas tarefas constituintes.

Modelo de Referncia
O WfMC (Workflow Management Coalition) uma organizao com mais de 225 membros, localizados em pases em todo o
mundo. Constitudo por fabricantes, universidades, organizaes governamentais, e corporaes interessadas na tecnologia de
workflow. O WfMC define: a Terminologia para elementos de sistemas de workflow, Padres abertos para interoperao de
sistemas, WAPI (Workflow API) e o Modelo de Referncia (Workflow Reference Model).
A definio de Workflow segundo o WfMC a "Automao de uma parte ou de todo um processo de negcio atravs de re-
cursos computacionais".
Dentro do contexto do Workflow, h o WFM (Workflow Management System), que o sistema que define, gerencia e exe-
cuta workflows atravs da execuo de software cuja ordem de execuo controlada por uma representao computacio-
nal da lgica de workflow.
O modelo de referncia define que o WFM composto por cinco subsistemas funcionais, exposto na figura.


119


Workflow no contexto do ERP
Workflow e ERP, independentes, proporcionam benefcios no aumento da eficincia nos negcios.
Trabalhando juntos possibilitam uma abrangncia maior promovendo benefcios para toda a organizao.
Quando falamos de workflow estamos nos referindo a um software que automatiza e controla os processos de negcio de uma
empresa. Como exemplo de processos de negcios, temos departamento de compras, rea de crdito em bancos, sistemas de
sinistro em seguradoras e at mesmo os sistemas de reembolso de despesas.
Os sistemas de ERP permitem que as empresas tenham seus sistemas de planejamento e controle juntos. Geralmente uma
soluo de ERP tem integrada os mdulos de finanas, fabricao, distribuio, logstica e de recursos humanos.
Numa soluo de ERP, tem-se um workflow embutido permitindo agilidade dentro de cada mdulo, bem como proporcio-
nando a integrao entre todos os mdulos. Esses fluxos de workflow so de propriedade exclusiva dos fabricantes de ERP.
Os mdulos de ERP implantados esto totalmente integrados entre si, mas muitas vezes tem-se a necessidade de integrao
com outras reas da empresa, como aplicaes legadas, ERM, CRM, gerenciamento de documentos e outras. Nesses casos, o
uso de ferramentas de workflow de terceiros permite a integrao do ERP a todas as aplicaes existentes na empresa, geran-
do ganhos muitos maiores. O uso de workflow soluciona uma das grandes dificuldades do ERP

Gerenciamento de processos de negcio (BPM)
uma forma genrica de descrever um conjunto de servios e ferramentas que oferecem gerenciamento de processos (anli-
se, definio, execuo, monitorao e administrao), incluindo suporte a interaes tanto humanas como automatizadas.
BPM surgiu de diversas origens como solues de workflow, ferramentas colaborativas, brokers de integrao, servidores de
aplicao, ferramentas de desenvolvimento, etc.
BPM aproveita as ferramentas para analisar e modelar os processos, utilizando normalmente um modelador grfico direcio-
nado aos Analistas de negcio que levantam os processos atuais e definem novos processos. Um ncleo de execuo executa
o processo passo a passo como definido a medida que este fluxo executado aplicaes ou tarefas manuais podem ser invo-
cadas. Alm disso, este ncleo mantm a situao dos processos para que enquanto mltiplas instancias dos processos este-
jam sendo executadas, elas podem ser monitoradas e administradas. Anlises posteriores dos processos tambm so permiti-
das j que estas informaes podem ser armazenadas.

120
E-commerce
Comrcio eletrnico ou e-commerce um tipo de comrcio feito especialmente por um equipamento eletrnico como por
exemplo um computador. Sistema comercial eletrnico, realizado atravs da Internet para transaes de bens ou servios
entre duas ou mais partes.
A capacidade de comprar e vender produtos e servios atravs da Internet. Inclui a exposio de bens e servios on-line, bem
como a colocao de pedidos, faturamento, atendimento e ainda todo o processamento de pagamentos e transaes ou seja,
usar a Internet, comunicaes digitais e aplicativos de TI para possibilitar o processo de compra ou venda. Alguns especialis-
tas definem e-commerce como todas as etapas que ocorrem em qualquer ciclo de negcios usando a tecnologia acima. Outros,
como compras feitas por consumidores e empresas pela Internet. Podemos tambm encontrar a expresso, tambm vlida, E-
marketplace que pode ser genrico (abarcar todos os setores de atividade) ou temtico (apenas um setor de atividade).
O ato de vender ou comprar pela Internet j um bom exemplo de comrcio eletrnico. O mercado mundial est absorvendo
o comrcio eletrnico em grande escala, muitos ramos da economia agora so ligadas ao comrcio eletrnico. Existem diver-
sas modalidades de comrcio eletrnico, entre elas o B2B, B2C, C2C, G2B e G2C.
B2B: Acrnimo de Business to business ou Negcios para negcios. um modelo de comrcio geralmente praticado
por fornecedores e clientes empresariais.
B2C: Acrnimo de Business to Consumers. O chamado B2C o comrcio eletrnico efetuado diretamente entre a
empresa produtora e o consumidor final. Em geral o consumidor adquire os produtos a preo mais competitivo pois
evita o 'atravessador'.
C2C: Acrnimo de Consumer to Consumer Comercio eletrnico que se desenvolve entre usurios particulares, ou
seja, entre internautas
G2B: Acrnimo de Government to Business. Relao de negcios pela Internet entre Governo e empresas ex: Com-
pras pelo Estado atravs da Internet atravs de preges e licitaes, tomada de preos, etc.
G2C: Acrnimo de Government to Consumers. Relao comercial pela Internet entre Governo e consumidores, ex:
pagamento via Internet de Impostos multas e tarifas pblicas.
Podemos encontrar tambm as expresses: Empresas e empresas (B-B) , Empresas e consumidores (B-C) , Consumidores e
consumidores (C-C), Governo e consumidores (G-C), Governo e empresas (G-B) ao invs de B2B, B2C, etc.
E-business (Electronic Business), o termo que se utiliza para identificar os negcios efetuados por meios eletrnicos, geral-
mente na Internet. E-business consiste na utilizao da Web para ajudar as empresas a simplificarem os seus processos, au-
mentarem a sua produtividade e melhorar a sua eficincia. Permite que as empresas se comuniquem com facilidade com par-
ceiros, fornecedores e clientes, que se conectem com sistemas de dados de back-end e que realizem transaes de maneira
segura. Observe que o e-commerce apenas uma parte do processo mais amplo do e-business que pode abranger projeto,
produo, interao de internautas no desenvolvimento de algo que, no futuro poder utilizar o e-commerce para venda.


121
Tcnicas e Linguagens de Programao

Lgica
A lgica o estudo de argumentos. Um argumento uma seqncia de enunciados, na qual um dos enunciados a concluso,
derivado a partir dos outros enunciados, chamados premissas.

Lgica Formal
A Lgica Formal, tambm chamada de Lgica Simblica, se preocupa basicamente com a estrutura do raciocnio. Ela lida
com a relao entre conceitos rigorosamente definidos e fornece um meio de compor provas de declaraes. As sentenas so
transformadas em notaes simblicas precisas, compactas e no ambguas.

Operador Smbolo
NO (Negao)
AND (Conjuno)
OR (Disjuno)
se ... ento
se e somente se

Enunciados Condicionais e Implicaes Materiais

Formas de enunciado, de raciocnio e de argumentos

Algoritmos e Estruturas de Dados
Um algoritmo um processo discreto e determinstico, que termina quaisquer que sejam os dados iniciais. Isso quer dizer que
um algoritmo possui uma seqncia de aes indivisveis, e que para cada passo da seqncia e para cada conjunto vlido de
dados, corresponde uma e somente uma ao.
Um algoritmo constitudo por um conjunto de expresses simblicas que representam aes (atribuir, escolher, etc.), testes
de condies (verdadeiro, falso) e estruturas de controle (ciclos e saltos na seqncia do algoritmo), de modo a especificar o
problema e sua respectiva soluo.

Noes de complexidade de algoritmo
Algoritmos podem ser classificados atravs de quatro critrios:
Completeza: Se o algoritmo sempre encontra uma soluo, se esta existir.
Otimalidade: Se o algoritmo garante encontrar a melhor soluo.
Complexidade de Espao: A quantidade de memria necessria para a execuo do algoritmo.
Complexidade de Tempo: Quanto tempo o algoritmo demora para rodar.
Quando se faz um algoritmo para resolver determinado problema, no basta que o algoritmo esteja correto. importante que
ele possa ser executado em um tempo razovel e dentro das restries de memria existentes. Alm disso, ele deve permane-
cer vivel, medida que o tempo passa, quando a quantidade de dados envolvida normalmente cresce. Os parmetros de
complexidade estudados normalmente so os seguintes:
122
Complexidade de pior caso: caracterizao do tempo de execuo mximo, para determinado tamanho da entrada,
bem como das caractersticas da entrada que levam a esse tempo mximo. Este o principal parmetro para se avali-
ar um algoritmo.
Complexidade de caso mdio: caracterizao do tempo de execuo mdio do algoritmo, para determinado tama-
nho da entrada, considerando a mdia de todas as possibilidades. Em muitas situaes este parmetro til.
Complexidade de melhor caso: caracterizao do tempo de execuo mnimo, para determinado tamanho da entra-
da, bem como das caractersticas da entrada que levam a esse tempo mnimo.
A determinao da complexidade teria que ser feita contando-se todas as instrues executadas e o tempo de execuo de
cada delas, considerando-se determinada entrada. Normalmente isso no vivel. O que se faz determinar um limite superi-
or para esse tempo, o mais prximo possvel da realidade. Para tanto, fixa-se o estudo na instruo mais executada do algo-
ritmo e determina-se uma funo t(n), que d a variao do tempo de execuo em funo de n, o tamanho da entrada.

Tipos de dados
Existem vrias classificaes para os tipos de dados utilizados por uma linguagem de programao:
Primitivos: normalmente, linguagens de programao possuem tipos de dados numricos inteiros e reais e tipos ca-
racter (uma letra, nmero ou smbolo). Outros tipos, como o tipo de dados booleano (boolean) podem ser utilizados
para guardar os valores verdadeiro (true) ou falso (false).
Derivados: So definidos a partir dos tipos de dados primitivos. Exemplos so os vetores, matrizes e cadeia de ca-
racteres (Strings), classificados como homogneos, e registros e unies, classificados como heterogneos, pois a-
grupam dados primitivos de tipos diferentes..
Tipo abstrato de dado um tipo de dado que esconde a sua implementao de quem o manipula, de maneira que determina-
das operaes sobre estes dados podem ser executadas sem que se saiba como isso feito. Tipos abstratos de dados abrangem
dados e operaes sobre estes dados. Exemplos: objetos, listas, rvores binrias...

Listas Encadeadas
Listas Lineares so um conjunto de n ns referentes a n objetos, onde as propriedades estruturais decorrem unicamente das
posies relativas dos ns, dentro de uma seqncia linear. Essas estruturas so tratadas sob o ponto de vista de como a
alocao de memria para os dados: Alocao Sequencial e Alocao Encadeada.
Vetores so as estruturas mais conhecidas de alocao seqencial. Mas as listas implementadas atravs de vetores podem
levar a uma pobre alocao de memria. Uma alternativa utilizar a alocao encadeada.
Na alocao encadeada (ou dinmica) os ns logicamente vizinhos de uma lista no so mais necessariamente vizinhos em
termos de memria. Os ns podem estar aleatoriamente dispostos e a indicao de vizinhana feita atravs de um campo de
endereo (chamado ponteiro). Desta forma, o n da lista contm pelo menos dois campos: a chave e o ponteiro.

O ltimo n contm um ponteiro nulo, que pode receber vrias denominaes: , Null, Nil ou Nulo.
Em um n pode existir mais de um ponteiro. As listas onde existe apenas um ponteiro so denominadas Listas Simplesmente
Encadeadas. Qualquer estrutura encadeada necessita de um apontador para o incio da lista.
Uma lista circular encadeada uma lista com cabea, onde o ltimo elemento, ao invs de apontar para Nil, aponta para o
n cabea. Uma lista duplamente encadeada uma lista encadeada nos dois sentidos. Cada n, ento tem dois links, um
para a frente (prox) e outro para trs (ante).

Pilhas
Uma pilha (stack) uma estrutura de dados linear, em que o ltimo elemento a ser inserido o primeiro a ser retornado pela
estrutura. Funciona como uma pilha de pratos em um restaurante. Ao serem limpos, os pratos so empilhados (armazenados).
Quando algum precisa usar um prato, o ltimo a ser empilhado ser o escolhido. Este o princpio LIFO (Last In First Out).
123
Uma pilha pode ser implementada por um vetor, onde o incio da pilha o primeiro elemento do vetor, e o topo a quantida-
de de itens inseridos no vetor (comea com 0).
As duas principais operaes de uma pilha so:
Push (empilhar): a operao de adicionar um elemento ao topo da pilha, aumentando o seu tamanho em uma uni-
dade. Caso a pilha esteja cheia (sem espao para novos elementos), um erro de overflow ocorre. Esta operao no
retorna nada, e o elemento a ser inserido passado como parmetro.
Pop (desempilhar): a operao de retirar um elemento do topo da pilha, diminuindo o seu tamanho em uma uni-
dade. Caso a pilha esteja vazia, um erro de underflow ocorre. Esta operao retorna o elemento da pilha, e no rece-
be argumentos como parmetro.
Estas duas operaes so suficientes para realizar qualquer alterao na pilha. Por exemplo, para inverter a ordem dos ltimos
dois elementos, basta a seguinte seqncia de instrues:
a = pop ()
b = pop ()
push (a)
push (b)

Filas
Uma fila (queue) uma estrutura de dados linear, em que o primeiro elemento inserido o primeiro a ser retornado pela es-
trutura. Funciona como filas de espera. Os elementos vo sendo colocados na lista e retirados (ou processados) por ordem de
chegada. Este o princpio FIFO (First In First Out).
Uma fila pode ser implementada por um vetor, utilizando dois apontadores, um para o incio da fila, e outro para o seu final.
Duas operaes devem ser implementadas: enfila e desenfila.

Vetores e Matrizes
Vetores guardam um nmero fixo de elementos, normalmente do mesmo tipo. Elementos so acessados utilizando um ndice,
inteiro, que referencia uma posio seqencial do vetor. Nesta seo sero estudadas as vantagens, desvantagens e aplicaes
desta estrutura durante a programao.
Vetores permitem o uso eficiente da memria, pois so armazenados seqencialmente na memria, no precisando de quase
nenhum (ou at nenhum) espao para controle da estrutura. Assim, um vetor com 1000 inteiros utilizar apenas 1000 vezes o
tamanho necessrio para armazenar um nico inteiro.
Uma das grandes vantagens no uso de vetores, em linguagens de programao, o uso de apenas um identificador para refe-
renciar vrios elementos. Suponha que uma aplicao possui o nome dos funcionrios armazenados nas seguintes variveis:
Nome1, Nome2, Nome3, Nome4 e Nome5. No seria nada prtico manter um cdigo desta maneira, pois a cada atribuio ou
acesso a uma destas variveis, ela deve-ria ser referenciada explicitamente (por exemplo, Nome1 = Nome5).
Utilizando vetores, basta declarar um vetor de 5 posies, com o identificador Nome, e cada funcionrio teria o seu nome
armazenado em uma das posies deste vetor.
Outro benefcio no uso de vetores, a propriedade de localidade de referncia. Arquiteturas de computadores modernas utili-
zam tcnicas de paginao de memria (ser visto com mais detalhes no captulo de Sistemas Operacionais) que so benefici-
adas pelo armazenamento seqencial de dados, pois o acesso a uma grande quantidade de dados vizinhos em um vetor far
menos acessos pginas do que na situao de cada elemento do vetor estar espalhado em posies distintas da memria.
A maior desvantagem dos vetores possuir um tamanho fixo. Embora em muitos ambientes seja possvel alterar o limite su-
perior do vetor (vetores dinmicos), esta operao no trivial. Uma possibilidade fazer o vetor crescer no apenas uma
posio, mas sim vrias posies sempre que o limite for atingido. Desta forma, ao inserir os prximos elementos no ser
necessrio expandir o vetor novamente.

124
rvores balanceadas
Muitas vezes precisa-se de estruturas mais complexas do que as seqenciais, especialmente quando se trabalha com grandes
volumes de dados. Uma das classes de estruturas desse tipo so as rvores, que servem para representar estruturas hierarqui-
zadas, onde um elemento pode apontar para vrios outros.
Uma rvore enraizada T, ou simplesmente rvore, um conjunto finito de elementos denominados de ns ou vrtices, tais
que: T um conjunto vazio e ento a rvore dita vazia OU existe um n especial r, chamado raiz de T; os restantes constitu-
em um nico conjunto vazio ou so divididos em m >= 1 conjuntos disjuntos no vazios (subrvores de r), ou simplesmente
subrvores, cada qual por sua vez uma rvore
rvores de busca so famlias de rvores utilizadas para armazenamento e busca de dados. O objetivo dessas estruturas
obter uma performance mdia bem melhor que aquela obtida com listas seqenciais. O mecanismo bsico utilizado nas rvo-
res de busca o de, numa procura, comparar o argumento de busca com determinada chave de determinado n da rvore. Se a
chave for maior, a busca prossegue pela subrvore da direita; se for menor, pela subrvore da esquerda
rvore Binria de Busca (ABB) uma rvo-
re binria onde as chaves dos ns da subrvore
direita de cada n so maiores que as chaves
desse n e as chaves da subrvore esquerda
so menores que a mesma.
So ideais para buscas e inseres, principal-
mente se no for uma rvore completa. Em
compensao, operaes de deleo so com-
plexas, pois deve-se manter a estrutura da rvo-
re.
A complexidade de busca e insero de
O(log
2
n). O nmero de ns de uma rvore des-
te tipo varia entre log
2
n + 1 e n, dependendo do
seu balanceamento.
Alguns exemplos de rvores ABB so as rvo-
res AVL e as rvores B, utilizadas para se ter
rvores balanceadas em disco e como base para
sistemas gerenciadores de banco de dados.
Percorrer uma rvore visitando cada n uma nica vez gera uma seqncia linear de ns, e ento passa a ter sentido falar em
sucessor e predecessor de um n segundo um determinado percurso. H trs maneiras recursivas de se percorrer rvores bin-
rias. So elas:

Travessia em Pr-Ordem (ABDCEGFHI)
1. se rvore vazia; fim
2. visitar o n raiz
3. percorrer em pr-ordem a subrvore esquerda
4. percorrer em pr-ordem a subrvore direita

Travessia em Ps-Ordem (DBGEHIFCA)
1. se rvore vazia, fim
2. percorrer em Ps-Ordem a subrvore esquerda
3. percorrer em Ps-Ordem a subrvore direita
4. visitar o n raiz


Travessia em In-Ordem (DBAEGCHFI)
1. se rvore vazia, fim
2. percorrer em in-ordem a subrvore esquerda
3. visitar o n raiz
4. percorrer em in-ordem a subrvore direita
125
Listas invertidas e ndices
Um ndice uma estrutura de dados contendo dois campos: uma chave e uma referncia. A chave est associada a um campo
(ou combinao de campos) do registro de um arquivo de dados. Um ndice dito primrio quando a chave identifica um
nico registro apenas no arquivo e secundrio no caso de mltiplos registros.

RRN significa Relative Record Number. Uma vantagem
da utilizao de ndices que o seu tamanho bem me-
nor, e pode ser mantido ordenado para acelerar a busca,
ou at mesmo ficar em memria.
Para arquivos de tamanho varivel, ao invs de guardar o
nmero do registro, melhor guardar a sua posio em
bytes.

Mtodos de acesso
Existem trs maneiras bsicas de acessar um registro:
Acesso seqencial: o arquivo lido registro por registro at o registro desejado ser encontrado. Essa a forma me-
nos eficiente de acesso, mas algumas situaes favorecem o seu uso, como a busca por texto (comando grep) ou
quando um arquivo possui poucos registros.
Acesso direto: o acesso direto a um dado registro (ou grupo de registros) em disco requer conhecer o endereo do
registro no arquivo de dados. Assim, comandos como fseek, podem ser usados para localizar diretamente o registro
para leitura/gravao, criando um ndice.
Endereamento: o endereo de um registro o seu deslocamento em bytes (offset) desde o incio do arquivo (ou
aps o cabealho). No caso de registros de tamanho fixo (como arrays), basta armazenar o nmero de registros que
antecedem cada registro, ou seja, a sua posio no arquivo.

Mtodos de ordenao e pesquisa
O problema de ordenao de dados pode ser dado como: " Dada uma lista contendo n chaves, distintas ou no, encontrar uma
permutao dessas chaves tal que elas fiquem em ordem crescente (ou decrescente) na lista".
H vrias idias diferentes para ordenao de dados e a maioria delas usa vetores como estrutura de dados:
Seleo: Criar, passo a passo, uma lista ordenada a partir de um conjunto de dados, retirando do conjunto a cada
passo o menor elemento presente, at esvazi-lo. Para implementar essa idia num vetor, ele dividido em dois sub-
vetores, o primeiro inicialmente nulo, tal que se retire dados do segundo e transfira para o primeiro. A complexidade
do melhor caso igual a do pior caso que igual ao caso mdio: O(n
2
)
Insero: Criar, passo a passo, uma lista ordenada a partir de um conjunto de dados, retirando do conjunto, a cada
passo, o primeiro elemento encontrado. Para implementar essa idia num vetor, ele dividido em dois subvetores. O
primeiro inicialmente contm uma chave, sendo a transferncia de dados feita in place, onde a cada passo o ele-
mento inserido pode ter que deslocar para a direita elementos maiores. A complexidade O(n
2
), sendo O(n) para o
vetor ordenado.
Bubblesort: Tambm conhecido como o mtodo da bolha, o vetor percorrido, e testam-se as posies i e i+1. Caso
i seja maior que i+1, esses elementos so trocados de posio. A varredura continua at o fim do vetor, e deve reco-
mear N vezes (onde N o tamanho do vetor), para garantir que todos elementos foram ordenados em suas posies.
A complexidade O(n
2
).
Quicksort: considerado o melhor algoritmo de ordenao e foi um dos primeiros algoritmos recursivos propostos.
A idia fazer, sucessivamente, parties em subvetores, de forma que a parte esquerda contenha sempre elementos
menores ou iguais aos da direita. O problema simples quando o tamanho de uma partio 1.


126
Hashing
Hashing, ou mais apropriadamente Transformao Chave-Endereo, um conjunto de mtodos que busca diminuir o tempo
mdio de busca em tabelas. Est baseado na idia de se trabalhar com um vetor e calcular o ndice de busca atravs de uma
funo sobre a chave (funo hash), que, idealmente, permitiria encontrar a chave em uma tentativa.
A situao ideal corresponderia a se ter funes hash injetoras. Entretanto, funes injetoras so relativamente raras. Alm
disso, o universo de chaves normalmente extremamente maior que o nmero de endereos. Isso leva a que se trabalhe com a
possibilidade de coincidncia de endereos. Nesse caso, as chaves so chamadas de sinnimos. O uso de hashing, conseqen-
temente, exige que se tenham mtodos de tratamento de sinnimos, o que d origem a vrias alternativas. Outro ponto a ser
notado que, a aplicao da funo hash sobre uma chave pode ser vista como um processo de reduo dessa chave
Alguns critrios que devem ser utilizados para um hashing eficiente so:
A imagem da funo deve ser o intervalo 1- M (ou 0 - (M-1)).
Ela deve ser de clculo rpido.
A distribuio de sinnimos deve ser uniforme. Isso quer dizer que os endereos devem ter probabilidades iguais (ou
muito prximas) de ocupao.
Deve-se ter cuidado para a funo hash no preservar propriedades especficas das chaves.
Algumas funes teis: mdulo da diviso (com M primo) e XOR (nas duas metades da chave).
Para tratar sinnimos, so utilizados os mtodos do Encadeamento Interior ou Exterior (uma lista encadeada para cada entra-
da do vetor), e Endereamento Aberto (onde no se utilizam links, mas os sinnimos so colocados na primeira posio dis-
ponvel a partir do endereo calculado).

Programao

Programao Estruturada
Imagine que tenha que processar as vendas feitas por cada vendedor de cada filial de uma empresa. Se voc vai programar em
um ambiente procedural, como COBOL, ento vai criar algo assim:
Um mdulo de controle, que invocar os procedimentos de inicializao e o loop principal.
Um mdulo que invocado para ler e processar cada filial.
Uma sob-rotina que invocada do mdulo das filiais para poder tratar cada funcionrio de cada filial.
Problemas decorrentes:
1) Falta de isolamento entre os mdulos: alterao em um mdulo pode resultar em danos nos outros.
2) Dificuldade de manuteno. Imagine o problema que seria se alguns tipos de vendedores tivessem regras diferen-
tes... e se algumas filiais tivessem o mesmo problema?
3) Dificuldade de reaproveitamento de cdigo. Se outro programa quisesse utilizar a mesma estrutura haveria copy-
paste e customizao.
A unidade de um programa procedural a sub-rotina, ou pargrafo em COBOL. Para cada coisa criada uma sub-rotina
que processar os dados. Modularizar um programa criar uma rotina para cada funo.

Modularizao
A modularizao a decomposio de um conjunto de componentes de software em sub-partes, denominadas mdulos. Es-
pera-se que os mdulos tenham uma forte coeso interna e um pequeno acoplamento exterior;:
Alta Coeso: todas as partes de um processo (ou mdulo) so fortemente relacionadas.
Baixo Acoplamento: o nmero de interfaces entre os processos (ou mdulos) mantido ao mnimo, visando facili-
tar modificaes futuras.
127
Um bom mdulo deve cumprir uma nica funo, e todos os seus arquivos devem ser suficientes para cumprir esta funo.
Alm disso, ele tambm deve possuir uma interface simples e bem especificada.

Sub-rotinas
Uma sub-rotina uma rotina de cdigo que chamada pelo programa principal para realizar uma tarefa. Normalmente cha-
ma-se de procedimentos as rotinas que no retornam valores, e funes as que retornam.
Passagem por valor: os valores que uma funo passa para outra no so alterados pela funo chamada, pois as
variveis do programa chamador so copiadas para as correspondentes variveis da funo. A passagem por valor
deve ser preferida ao invs do uso de variveis globais.
Passagem por referncia: significa que passamos de uma funo para outra o endereo de uma varivel (sua locali-
zao de memria). Qualquer alterao no contedo apontado pelo ponteiro ser uma alterao no contedo da vari-
vel original.
Passagem por endereo: antigamente, os termos passagem por endereo e por referncia eram sinnimos. Em C s
existe a passagem por valor e por referncia, mas em Algol e C++ as trs esto disponveis. Um vetor em C++ pas-
sado por endereo, assim todo o seu contedo pode ser manipulado .

Escopo de Variveis
O escopo de uma varivel a sua rea de atuao, normalmente o lugar onde foi definida. Para que no existam ambigida-
des na utilizao dos identificadores, no pode existir nenhum caso onde existam dois identificadores com o mesmo nome
dentro do mesmo escopo, i.e. dentro de um escopo existe uma unicidade de nomes. O mesmo vale para parmetros passados
para uma sub-rotina.
Escopo global: so declaradas fora de todas as sub-rotinas, normalmente no incio de mdulos. Todo o mdulo e as
sub-rotinas declaradas em seu corpo possuem acesso a estas variveis.
Escopo local: so declaradas dentro de uma sub-rotina. Apenas a funo possui acesso ao seu contedo, o que au-
menta o reuso do subprograma e evita efeitos colaterais (maior controle).

Tipos de dados
De forma geral, podemos classificar as linguagens de programao quanto ao modelo de tipagem da seguinte maneira: tipa-
gem forte e tipagem fraca. Essa questo manifesta-se principalmente em atribuies.
No caso de linguagens orientadas a objetos, tambm ocorre em invocaes de mtodos.
Tipagem forte: o compilador garante que em tempo de execuo ocorra a compatibilidade entre os elementos de
uma atribuio, e tambm a existncia do mtodo para uma dada referncia. Garante maior robustez aos sistemas de-
senvolvidos, minimizando erros em tempo de execuo.
Tipagem fraca: neste caso, o compilador no existe essa garantia durante a verificao de tipos, sendo responsabili-
dade do programador. Possibilita maior velocidade e facilidade no desenvolvimento.

Programao Orientada a Objetos
A principal tecnologia que facilitou a criao dos programas Windows foi a programao baseada em objetos ou OOP (ob-
ject-oriented programming). Esta tecnologia tornou possvel criar componentes reutilizveis que se tornaram os blocos da
construo dos programas. Os principais elementos da OOP que se usar so objetos reutilizveis. O Delphi, o Visual Basic e
o C++ usam objetos visuais denominados componentes para criar programas. Os componentes que sero usados na constru-
o dos programas so objetos que tm propriedades e mtodos, e que respondem a eventos, como controlar a aparncia e o
comportamento de um componente atravs de suas propriedades. Estes componentes possuem mtodos predefinidos que faci-
litam a programao.
Alguns conceitos de anlise e programao orientados a objetos so:
Abstrao: consiste em considerar apenas os aspectos essenciais de uma entidade, ignorando aqueles tidos por irre-
levantes. uma tcnica importante para lidar com a complexidade de sistemas.
128
Herana: habilidade de passar Mtodos e Propriedades para as classes derivadas, promovendo, assim a reutilizao
de cdigo.
Encapsulamento: oculta a implementao das classes, expondo apenas sua interface. Ele separa o comportamento
externo de um objeto do seu funcionamento interno, evitando interdependncias.
Polimorfismo: habilidade de ter mtodos com o mesmo nome executando de maneira semelhante em Classes Deri-
vadas. Ou seja, classes semelhantes, com mtodos aparentemente idnticos, podem funcionar de maneira diferente.
Assim a mesma operao pode ter comportamentos distintos.
Agregao: tambm chamada de composio, representa uma forma especial de associao (que define-se quando
um objeto recorre aos servios de um outro), e ocorre quando um objeto contm, fsica ou logicamente, outros.
Lembre-se que o agregado mais do que a simples soma das suas partes.

Refactoring
Refactoring ou refatorao a idia de fazer vrias pequenas alteraes incrementais em um cdigo, sem adicionar novas
funcionalidades ou corrigir erros, mas sim melhorar o projeto ou facilidade de leitura do cdigo.
Esta prtica uma oportunidade de melhorar a qualidade do cdigo

Desenvolvimento J2EE

Especificao J2EE
A plataforma Java 2 Enterprise Edition define o padro para desenvolver aplicaes corporativas de vrias camadas baseadas
em componentes. Algumas das caractersticas dessas aplicaes: portabilidade, escalabilidade e integrao facilitada com
aplicaes legadas e dados. Alm disso, tambm permite a construo e utilizao de web services que podem se comunicar
com web services de outras plataformas (por exemplo, .NET).
Algumas das principais tecnologias includas na especificao J2EE so:
JavaServer Pages: pginas JSP so templates usados para produo automtica de servlets. Escreve-se uma pgina
HTML com comandos Java, que so traduzidos em tempo de execuo em um servlet.
Java Servlets: servlets so classes/objetos que funcionam como programas CGI. Com o suporte de um Web contai-
ner um servlet tem acesso a dados de formulrios e tem o compromisso de produzir um cdigo HTML que ser de-
volvido ao cliente.
Enterprise JavaBeans: um objeto que colocado em container adequado pode ser chamado e chamar objetos remo-
tamente de forma (quase) transparente.
Java Message Service (JMS): um conjunto de APIs que permite acessar de forma padronizada servios de men-
sagens. Dispe de mecanismos para criar, enviar, receber e ler mensagens.
Java Naming and Directory Interface (JNDI): o elemento utilizado para cadastramento de responsveis por ser-
vios Java, e isso lhe d a capacidade de responder a perguntas de clientes por esses servios. Uma analogia o ma-
peamento de nomes de sites para IPs (DNS faz o mapeamento).
Java Transaction API (JTA): especifica uma interface padro para aplicaes utilizarem um servio de suporte
transacional. Esse gerenciamento mais conhecido no contexto de banco de dados, mas o seu uso em aplicaes dis-
tribudas mais amplo (falhas na rede, dependncias, etc).
JDBC data access API: um conjunto de APIs que direta ou indiretamente acessam bancos de dados. Programar em
JDBC escrever, explicitamente, chamadas a mtodos cujos parmetros so, grosseiramente, os comandos SQL que
devem ser enviados ao SGBD.

Conceito de servidor de aplicao
Um servidor de aplicao algo mais que um servlet container, que algo mais que um webserver.
129
O Servlet container mais conhecido o Apache Tomcat. Ele implementa as funes de um Web Server (como o apache
httpd), ou seja, apresenta pginas HTML estticas, mais a funcionalidade de interpretar on-the-fly programas java e apresen-
tar sua sada pelo protocolo http. Ele apresenta pginas dinmicas JSP e sadas de programas em java chamados de "servlets".
Um Servidor de Aplicao um Servlet Container e mais vrios servios rodando junto. Acontece que o padro J2EE - Java
2 Enterprise Edition - prev uma srie de funcionalidades a mais de servidor: um servidor de nomes de Java, um distribuidor
automtico de componentes, um balanceador de carga, entre outros. Bom, esses servios, juntos, permitem que os servlets e
JSP's tenham bem mais recursos, conexo mais escalvel com um banco de dados e da por diante. Os EJB's (Enterprise Java
Beans) nada mais so do que componentes que utilizam de todos esses servios pra comunicao com o Banco de Dados.
Existem alguns Applications servers livres, mas o nico realmente srio e com funcionalidade comparvel a servidores de
aplicao comerciais (como o Sun One ou o IBM WebSphere) o JBOSS.
Note que a expresso "Servidor de Aplicao" mais ampla do que essa definio, pois de certo modo ela foi 'apropriada'
pelo Java pra designar um Servidor de Aplicao J2EE. Existem na verdade outros esquemas completamente diferentes, em
outras linguagens, para fazer "servidores de aplicao".
O conceito de J2EE foi agrupar as diversas tecnologias (JNDI, JCA, JSP, Servlets, EJB, JMS) em uma forma nica e consis-
tente. O Application Server um programa que implementa essa J2EE. A Sun possui um programa de certificao para de-
mais fornecedores.
A desvantagem de utilizar um Servidor de Aplicao, que algumas empresas compram o pacote inteiro, para aplicaes
simples com JSP e Servlets. As demais tecnologias so desperdiadas, e bastaria utilizar um simples container Web, como o
Tomcat.

Container web e EJB
Toda aplicao Java executa sob um certo ambiente, o qual se convencionou chamar de container. Por enquanto, imagine um
container como uma JVM, um Class Loader (capaz de buscar classes no sistema de arquivo ou na rede e agreg-lo ao ambien-
te). Quando se executa uma aplicao na linha de comando, o container se liga apenas ao sistema operacional nativo (Appli-
cation Container) e apenas com esse interage.
Applet Container: Por exemplo, quando um applet executado, a JVM funciona como um plugin do web browser, e para
tanto, existe um conjunto de regras que permite ao browser interagir com a JVM para executar cdigo Java dentro de seu am-
biente. Aqui temos o browser como o Container (Applet Container).
Web Container: Uma outra possibilidade o container Web (Web Server), que encapsula as APIs de Servlets e JSPs, cujo
compromisso produzir cdigo HTML para envio ao cliente. Um servidor Web um modelo inteiramente novo, introduzido
pela Internet, e geralmente consiste em uma grande quantidade de clientes, que se comunicam com servidores pesados, res-
ponsveis por atender a milhares de requisies. O container a camada onde ser hospedada a aplicao Java (no caso, no
servidor web).
A comunicao entre eles feita utilizando o protocolo HTTP, normalmente atravs do envio de requisies de um navega-
dor (ou browser) para um servidor Web, que retorna as respostas atravs de contedo Web (como pginas) de volta para o
cliente. Ento a definio de um servidor Web a seguinte: um aplicativo capaz de fornecer ao cliente (navegador Web) os
dados solicitados atravs de suas requisies.
Como exemplo de servidor Web est o Apache, que um aplicativo livre.
EJB Container: EJBs so o corao da plataforma J2EE. Para caracteriz-los, so necessrios: uma interface home, que ofe-
rece mtodos para criar e encontrar instncias EJB; uma interface remote, que a viso que um cliente tem do objeto; e uma
classe bean, que a sua implementao no lado do servidor.
Do ponto de vista de arquitetura um container oferece muitos servios e propriedades aos EJBs, o que permite caracteriz-los
em vrias categorias: Entity Beans, Session Beans ou Message-Driven Beans.
Exemplos de container EJB so o Websphere e o JBOSS.
130


Padres e anti-padres de projeto J2EE
Os padres J2EE foram catalogados pela Sun para resolver problemas que j ocorreram no passado em aplicaes baseadas
na arquitetura J2EE
Intercepting Filter: realiza o pr-processamento de uma requisio ou ps-processamento de uma resposta. O filtro
intercepta as requisies feitas pelo cliente, podendo modific-la ou redirecion-la antes de envi-la para a aplicao.
O mesmo pode ser feito com as respostas antes de serem enviadas. Ele aumenta a reusabilidade e desacoplamento do
componente e facilita a sua configurao.
Transfer Object: permite que uma classe faa a comunicao de dados entre componentes, agrupando as suas in-
formaes em um conjunto nico (serializvel). Normalmente esses componentes so Enterprise Java Beans, que
fazem chamadas a vrios mtodos get e set.
Business Delegate: utilizado para desacoplar componentes de negcios de aplicaes que utilizam os componentes.
O Business Delegate um objeto do lado do cliente que esconde do cdigo do cliente os servios da camada de ne-
gcio. Tambm usado para tratar as excees do servio.
Service Locator: geralmente utilizado em conjunto com o Business Delegate, um componente para lidar com a
busca de servios, ocultando os detalhes do cliente (caso o servio seja substitudo). Reduz a complexidade do cdi-
go no cliente e melhora a performance e manutenibilidade do cdigo.
Front Controller: especifica um componente central para processar as requisies dos clientes. A responsabilidade
deste componente receber as requisies e rote-las de forma apropriada. Alm de centralizar o controle dos servi-
os, reduz a quantidade de cdigo e aumenta a segurana da aplicao.
Outros padres: Alguns outros padres so: Session Faade, Fast Lane Reader, Composite Entity e Value List
Handler.

Padro MVC de Projeto
O padro Model-View-Controller (MVC) separa as camadas de apresentao, de lgica de negcio e de gerenciamento do
fluxo da aplicao, aumentando a reusabilidade e manutenibilidade do projeto.
muito utilizado para casos em que podem existir mltiplas camadas de apresentao para clientes diversos. Por exemplo,
para os usurios diretos de uma aplicao, os dados podem ser apresentados em pginas JSP, mas para os fornecedores pode
existir uma interface WML, enquanto para os usurios remo-tos pode existir uma interface HTML simples.
um dos padres de desenvolvimento mais populares, favorecendo uma arquitetura em trs camadas. O Servlet representa o
Controller (Controlador), enquanto o JSP a View (Viso) e JavaBeans so utilizados para mapear o Model (Modelo). O
servlet recebe uma requisio de um cliente (navegador), instancia um JavaBean e encaminha a requisio para o JSP. Aps
esta operao, o JSP envia a resposta de volta para o cliente.
Algumas das caractersticas do padro MVC so:
Permite que os dados sejam disponibilizados de maneiras diferentes
Encapsula as funes da aplicao, aumentando a manutenibilidade
Desacopla a funcionalidade da aplicao da sua apresentao
131
Facilita a distribuio da aplicao
Permite maior flexibilidade atravs de mdulos "plugveis".
Distribui as responsabilidades da aplicao de forma consistente


132
Desenvolvimento de sistemas Web

HTML
HTML a sigla para Hyper Text Markup Language, ou Linguagem de Marcao de Hipertexto, tradicionalmente utilizada
para a criao de pginas Web. Os seus elementos servem para definir a formatao, apresentao, objetos (imagens, sons) e
links, mas no possui os recursos de uma linguagem de programao. A sua sintaxe simples e universal.
A linguagem consiste em uma srie de tags integradas em um documento texto. Para visualizar os documentos HTML, pode
ser utilizado qualquer navegador Web, como o Internet Explorer, Mozilla Firefox ou o Netscape.
Uma tag uma etiqueta (label) que executa uma funo no documento. Toda pgina HTML deve ser iniciada pela tag <ht-
ml> e terminada pela tag </html>. Note que as tags podem ser escritas tanto em minsculas quanto em maisculas. O fecha-
mento das tags sempre feito com uma barra "/" precedendo o seu nome.

<html>
<head>
<title> Ttulo do Site </title>
</head>
<body background="figura.gif" bgcolor="red">
<h1>Texto de tamanho maior</h1>
<h3>Texto de tamanho mdio</h3>
<h6>Texto de tamanho menor</h6>
<i>Itlico</i> <b>Negrito</b>
<h3 align="center">Texto ao centro</h3>
<h2 align="left">Texto esquerda</h2>
Pargrafo: <p>
Quebra de linha: <br>
Linha horizontal: <hr>
<a href="http://endereco.com">Nome do Link</a>
<img src="Caminho da imagem">
<img src="Img.jpg" alt="Texto" align="right">
</body>
</html>

Tabelas em HTML: TR (Table Row), TH (Table Header) e TD (Table Data)
<TABLE border="1" summary="Statistics about fruit flies">
<CAPTION><EM>A test table with merged
cells</EM></CAPTION>
<TR><TH rowspan="2"><TH colspan="2">Average
<TH rowspan="2">Red<BR>eyes
<TR><TH>height<TH>weight
<TR><TH>Males<TD>1.9<TD>0.003<TD>40%
<TR><TH>Females<TD>1.7<TD>0.002<TD>43%
</TABLE>

133
CSS
Tags HTML foram projetadas originalmente para definir o contedo de um documento. Elas devem indicar "Isto um hea-
der", "Isto um pargrafo" ou "Isto uma tabela", utilizando tags como <h1>, <p>, <table>, e assim por diante. O layout do
documento deveria ser tratado pelo navegador, sem usar nenhuma tag de formatao.
Os principais navegadores (Internet Explorer e Netscape) comearam a adicionar novas tags HTML e atributos (como a tag
<font> e o atributo color) especificao original do HTML, aumentando a dificuldade de criar pginas Web onde o conte-
do dos documentos HTML estavam separados do seu layout (apresentao).
Para resolver esse problema, o World Wide Web Consortium (W3C) criou STYLES em adio ao HTML 4.0. A maioria dos
navegadores atuais suportam o CSS (Cascading Style Sheets):
Estilos definem como os elementos HTML devem aparecer
Estilos so normalmente armazenados em Style Sheets
External Style Sheets so armazenados em arquivos CSS, e economizam tempo de desenvolvimento
Definies mltiplas de estilos se cascateiam em uma

Continuar em: http://www.w3schools.com/css/css_intro.asp


Javascript
JavaScript uma linguagem que executa no Cliente, e permite injetar lgica em pginas HTML. Os pargrafos de lgica do
JavaScript podem estar "soltos" ou atrelados a ocorrncia de eventos. Os pargrafos soltos so executados na seqncia em
que aparecem na pgina (documento) e os atrelados a eventos so executados apenas quando o evento ocorre. Para inserir
pargrafos de programao dentro do HTML necessrio identificar o incio e o fim do set de JavaScript, da seguinte forma:
<SCRIPT>
Set de instrues
</SCRIPT>
Para melhor visualizao e facilidade de manuteno, recomenda-se que toda a lgica seja escrita no incio do documento,
atravs da criao de funes a serem invocadas quando se fizer necessrio (normalmente atreladas a eventos). Se a lgica
escrita a partir de um determinado evento, no necessrio o uso dos comandos <SCRIPT> e </SCRIPT>

Comandos do Javascript
Note que o Javascript sensvel ao tipo de letra (maisculas e minsculas). Caso seja cometido algum erro de sintaxe quando
da escrita de um comando, o JavaScript interpretar, o que seria um comando, como sendo o nome de uma varivel.
Operadores lgicos: so iguais ao Java: == (igual), != (diferente), > (maior), >= (maior ou igual), && (E), || (Ou), etc.
Operadores matemticos: tambm similar ao Java: + (adio), - (subtrao), * (multiplicao), / (diviso) e % (mdulo).
Controles especiais: os caracteres de escape \n, \r, \t, etc. Comentrios usam // e /* ... */, e Strings delimitam-se por "" ou ' '.
Comandos condicionais: os comandos if, for, while, break e continue e o operador ? funcionam como em Java.
var contador = 10
while (contador > 1)
{
if (teste = 3) strTeste = "Fim\n";
contador--;
}
As variveis so criadas automaticamente, pela simples associao de valores a mesma. Ex. NovaVariavel = "Jose"
134
O JavaScript permite que o programador escreva linhas dentro de uma pgina (documento), atravs do mtodo write. As li-
nhas escritas desta forma, podem conter textos, expresses JavaScript e comandos Html.
<script>
valor = 30
document.write ("Minha primeira linha")
document.write ("Nesta linha aparecer: " + (10 * 10 + valor))
</script>

Eventos
So fatos que ocorrem durante a execuo do sistema, a partir dos quais o programador pode definir aes a serem realizadas
pelo programa. Segue a lista dos eventos possveis, indicando os momentos em que os mesmos podem ocorrer:
onload: ocorre na carga do documento. Ou seja, s ocorre no BODY do documento.
onunload: ocorre na descarga (sada) do documento. Tambm s ocorre no BODY.
onchange: ocorre quando o objeto perde o foco e houve mudana de contedo. Vlido para os objetos Text, Select e
Textarea. O evento onblur ocorre quando o objeto perde o foco, independente de mudanas.
onfocus: ocorre quando o objeto recebe o foco. Vlido para os objetos Text, Select e Textarea.
onclick: ocorre quando o objeto recebe um clique do Mouse. Vlido para os objetos Buton, Checkbox, Radio, Link,
Reset e Submit.
onmouseover: ocorre quando o ponteiro do mouse passa por sobre o objeto. Vlido apenas para Link.
onselect: ocorre quando o objeto selecionado. Vlido para os objetos Text e Textarea.
onsubmit: ocorre quando um boto tipo Submit recebe um clique do mouse. Vlido apenas para o Form.

Funes do Javascript
O JavaScript permite que o programador escreva linhas dentro de uma pgina (documento), atravs do mtodo write. As li-
nhas escritas desta forma, podem conter textos, expresses JavaScript e comandos Html. Elas aparecero no ponto da tela
onde o comando for inserido. Pode ser utilizado <br> e <p> para quebra de linha e pargrafo, respectivamente.

<script>
valor = 30
document.write ("A primeira linha <br>")
document.write ("Nesta linha aparecer : " + (10 * 10 + valor) + "<p>")
</script>

Existem trs formas de comunicao por mensagens: alert (aviso), confirm (mensagem Ok / Cancelar) e prompt:
if (confirm ("Algo est errado...devo continuar??")) {
Entrada = prompt("Informe o seu nome", "")
alert("Bem-vindo, " + Entrada + "!")}
else
{ alert("Parando") }

Tambm possvel criar as suas prprias funes em Javascript, utilizando:
function NomeFuno (Parmetros)
135
{ Ao }
Ou utilizar uma funo interna (eval, parseInt, date, Math.abs, Math.pow, Math.max, Math.min, etc).
Tambm existem outras funcionalidades, como criao de Arrays, manipulao de Strings ou datas, instncias de objetos, etc.

DHTML
Dynamic HTML, ou DHTML uma forma de executar scripts no lado do cliente, permitindo que as pginas ganhem
contedo dinmico, atravs da execuo de scripts simples e fceis de desenvolver.
O DHTML no uma extenso da linguagem HTML, e tampouco uma linguagem de programao. Uma das desvantagens
que as implementaes entre os diferentes navegadores (Internet Explorer, Netscape Navigator) no uniforme.
A implementao DHTML, apresentada pela Microsoft na verso 4.0 do Internet Explorer, cobre quatro reas principais que,
na perspectiva do criador de contedo para a Web, lhe oferecem novas funcionalidades extremamente interessantes.
Estilos Dinmicos: possvel alterar dinamicamente qualquer atributo CSS de qualquer texto. Entre esses atributos
incluem-se, por exemplo: cores, visibilidade, fonts, etc. A utilizao de CSS permite controlar a apresentao de
uma pgina Web. Utilizando DHTML, torna-se possvel criar efeitos interativos alterando qualquer um dos atributos
de estilo de qualquer um dos elementos da pgina.
Posicionamento Dinmico: possibilita o posicionamento de objectos na pgina atravs da manipulao de
determinados atributos CSS (top, left, width, right, etc). Isto para alm da possibilidade de controlar a "Z-order" dos
objetos (que define a sua sobreposio vertical), o que permite, por exemplo, colocar uma imagem sobre outra.
Contedo Dinmico: permite adicionar, eliminar ou modificar qualquer poro de texto ou grficos em qualquer
posio da pgina. Sempre que o contedo da pgina for modificado, esta ser redesenhada, de forma a englobar o
novo contedo da melhor forma.
"Data Binding": possvel apresentar, manipular e atualizar os dados da pgina, estabelecendo ligaes entre os
dados e tags HTML. Essa fonte de dados pode ser to simples como um arquivo de texto ou to complicada como
uma base de dados acessvel via ODBC.
Essas reas cobertas pelo Internet Explorer so diferentes de como foi implementado no Netscape Navigator, ou outros.

Arquitetura de aplicaes para ambiente web
Servidor de aplicaes
Servidor Web
Ambientes Internet, Extranet, Intranet e Portal - finalidades, caractersticas fsicas e lgicas, aplicaes e servios
Servidor de Banco de Dados
Objetos Distribudos
Arquitetura de software: arquitetura 3 camadas, modelo MVC

Web services
Web Services so o ltimo conceito na computao distribuda, sendo funes (ou aplicaes) de negcio modulares, auto-
descritivos, que operam na rede. Eles facilitam a interao entre companhias atravs da simplificao das regras de comuni-
cao, utilizando XML como o formato de troca de mensagens em comum (protocolo neutro).
Embora os web services possam ser acessados utilizando uma chamada de procedimento remota (RPC), a comunicao assn-
crona tambm possvel, o que ideal para grupos de web services com baixo acoplamento, operando independentemente.
Web Services tambm oferecem vrios benefcios s organizaes, nos requisitos interao e integrao, pois infra-estruturas
diferentes podem se comunicar. Porm, a segurana uma preocupao que deve ser levada em conta.
Um exemplo de aplicao para web services: uma empresa pode permitir que seus fornecedores monitorem o estoque de um
produto, para que possam abastec-lo sem necessidade de enviar ordens de servio. Isso faz com que os fornecedores satisfa-
am os seus clientes de forma mais rpida, alm de reduzir custos (para todos os trs: empresa, fornecedores e clientes).
136

Arquitetura Service-Oriented Architecture (SOA)
A arquitetura de web services pode ser descrita em termos da Service Orientated Architecture (SOA). Ela uma evoluo do
modelo orientado a objetos, mas todas as entidades so entendidas como servios, que publicam uma interface para uso de
outros servios na rede. A SOA uma mudana do modelo tradicional cliente / servidor, onde as aplicaes compartilham
dados, acrescentando tambm o compartilhamento de servios de negcios entre empresas.
A arquitetura SOA para web services compreende trs papis: provider, broker, e o requestor e trs operaes entre estes
papis publicao(publish), busca (find) e ligao (bind). Os prprios componentes dessa arquitetura so os web services,
que consistem em duas partes: a sua implementao e a descrio ou interface do servio.
Service Provider: fornece o web service, que o
componente de software que os outros servios po-
dem acessar e usar. Pode ser desde uma classe Java
at uma aplicao em COBOL. O service provider
tambm descreve o servio utilizando uma interface,
que inclui informaes como o formato dos dados e
protocolos de rede.
Service Broker (ou registry): a interface do provider
publicada para o broker, que um diretrio centra-
lizado com as descries dos web services. Define
tambm a API para registrar e buscar os servios.
Service Requestor: o cliente em potencial do servi-
o, que disponibilizado pelo broker. Quando o re-
questor encontra o servio que deseja utilizar, ele
invoca o servio do provider (operao bind). Pode
ser tanto um indivduo que procura os servios pela
Internet, uma organizao ou uma aplicao de web
services que invoca os servios.

Tecnologias dos Web Services
XML a maneira de descrever os dados em um formato rgido, que impe uma estrutura que pode ser interpretada. XML
baseada em texto, independente de plataforma e linguagem, e adequados para web services. Outras tecnologias so:
SOAP (Simple Object Access Protocol): utiliza XML para descrever uma maneira em que as mensagens devem ser
passadas em web services. Uma mensagem SOAP consiste de um ou mais cabealhos, um corpo, e um envelope que
contm o prprio web service e os endereos de destino. As mensagens unidirecionais SOAP podem ser combinadas
para gerar vrios padres de mensagens:
o Multicast: o remetente pode fazer um broadcast da mensagem SOAP para mltiplos destinatrios.
o Workflow: a mensagem SOAP pode ser enviada para vrios endpoints antes de retornar ao remetente.
o Request-response: o remetente envia a mensagem para um recipiente, e recebe a confirmao (= RPC).
WSDL (Web Services Definition Language): descreve os web services, permitindo que os usurios entendam como
acess-lo. Tambm uma linguagem baseada em XML, e especifica tambm o protocolo de transporte, as capacida-
des do servio, e os pontos de comunicao em ambos os canais de comunicao. A interface WSDL atua como uma
interface remota Java, ou uma IDL Corba, e tambm conhecida como XML-based IDL.
UDDI (Universal Description, Discovery and Integration): um registro centralizado dos web services, similar a
um catlogo de telefones, utiliza SOAP e XML em suas APIs, alm de usar a linguagem WSDL para promov-los.
Existem trs tipos de registros definidos na especificao UDDI:
o White pages: permite o registro de informaes como o prprio servio, IDS, contrato e dados relacionados.
o Yellow pages: permite organizar o servio pela indstria, geografia ou tipo de servio. (Pginas Amarelas).
o Green pages: inclui detalhes tcnicos de como encontrar e executar um web service.
Para criar um web service, antes deve ser criado um "resumo" do servio utilizando um arquivo WSDL. Ento os detalhes do
servio devem ser registrados / publicados utilizando um registro UDDI. Um cliente envia uma requisio ao diretrio, e

137
capaz de contatar o servidor SOAP aps obter diretamente os detalhes do WSDL do registro UDDI. Assim o cliente pode
utilizar o web service atravs do envio e recebimento de mensagens SOAP.

Portais Corporativos
Portal Corporativo pode ser definido como uma aplicao tipicamente web, desenvolvida para funcionar como interface nica
e personalizada do ambiente eletrnico de trabalho, provendo aos usurios contedo, informao, acesso a aplicaes, colabo-
rao e conhecimentos necessrios a plena atuao, envolvendo todo relacionamento com os stakeholders da empresa
Ainda recente e sem que tenhamos aprendido muito com eles, os Portais Corporativos, como uma resposta evoluo da In-
tranets, vieram sem dvida para ficar e promover uma poderosa transformao no trabalho e nas empresas. Como um grande
aliado da gesto do conhecimento, rapidamente se tornaro comuns maioria das empresas.
Portal Corporativo ou Intranet de terceira gerao (I3g) significa ao funcionrio ter um nico ponto para acesso a todas as
informaes relevantes, ferramentas de colaborao, aplicaes e servios que ele precisa para fazer o seu trabalho. Do ponto
de vista da empresa, representa economia e produtividade aumentadas.
Cada funcionrio passa a ter em seu desktop, uma janela nica que agrupa todas as informaes necessrias a execuo do
trabalho dirio. Alm disso, oferecem considervel independncia de lugar, pois atravs de conexo com dispositivos mveis
possvel aos funcionrios e parceiros da empresa acessar o portal e sua riqueza de informao, onde quer que eles estejam.

Motivao e Caractersticas dos Portais
As razes que estimulam a criao de portais corporativos nas empresas so muitas. Algumas das principais so:
a dificuldade de acesso informao;
muita gente perdendo tempo respondendo a dvidas dos funcionrios que deveriam ser respondidas pela Intranet;
Intranet que oferece tudo para todo mundo (falta de personalizao);
falta de informao e contedos aplicveis ao trabalho (resoluo de problemas, comercializao, atendimento ao
cliente, criao de produtos, etc...);
vrios cones para se chegar a informao desejada e conseqentemente vrias senhas de acesso s aplicaes;
falta de padro das interfaces de acesso a informao e entre as aplicaes;
baixa qualidade das informaes;
desperdcio de tempo na procura de informaes;
vrias Intranets na empresa, produtividade das equipes deficiente;
pouco contexto entre as informaes da Intranet e a realidade de negcios;
baixos ndices de colaborao entre os talentos da empresa e falta de informao para o trabalho.
Os portais corporativos altamente integrados com aplicaes (desenvolvidas internamente e por terceiros), ferramentas de
colaborao e servios de informao de diferentes fontes, formatos e ambientes, permitem integrar processos de negcios e
viabilizam prticas conhecidas como Business to Employee (B2E). H a promessa de reduo de despesas e desperdcios,
aumento de produtividade, reteno de talentos, aumento de empowerment, melhoria de qualidade e atendimento, reduo do
tempo de respostas e resoluo de problemas, prontido de respostas, colaborao, trabalho em grupo, aprendizagem, etc.
Entre todas as razes o que torna mais urgente os servios tipo B2E a possibilidade de se resgatar aos funcionrios da em-
presa, o bem mais precioso de nossos dias: o tempo. Quanto tempo seu pessoal desperdia todos os dias procurando por in-
formaes que deveriam estar publicadas na Intranet? Quanto tempo as pessoas desperdiam delas prprias e de outros fun-
cionrios, se ocupando mutuamente com assuntos que poderiam ser resolvidos pela Intranet? Quanto as pessoas consomem
de telefone na resoluo de problemas ou busca de informaes que poderiam estar na Intranet? Quanto esforo deixa de ser
aplicado na atividade fim da empresa por estas razes? Quanto isso representa ($) por ano em sua companhia?
Alm de apoiar a comunicao empresarial e a aprendizagem dinmica, os portais corporativos suportam muitas das iniciati-
vas de gesto do conhecimento baseadas em Tecnologia da Informao, alavancando a integrao dos processos de negcios,
colaborao, comunidades de prtica, e-learning, e-CRM, disseminao de melhores prticas, espaos virtuais de trabalho,
relacionamento com os stakeholders, inteligncia competitiva, repositrio de documentos, grupos de discusso, web confe-
rence, instant messaging e muito mais, se transformando tambm em uma poderosa vitrine de acesso ao conhecimento.
138
Entre as caractersticas mais bsicas de um portal corporativo temos:
Templates: a As pginas de um portal sempre apresentam elementos comuns, tais como banners, barra de navega-
o, cabealho, rodap entre outros. Estes elementos podem ser armazenados em um ou mais templates, os quais se-
ro utilizados pelas pginas que compem o portal. Isto permite que os construtores do portal atualizem a aparncia
e a estrutura das pginas de maneira centralizada, via templates, atualizando automaticamente todas as pginas rela-
cionadas. Com templates, os desenvolvedores das aplicaes no precisam preocupar-se com aspectos de montagem
da pgina completa, mas apenas com as interfaces da sua aplicao.
Escalabilidade e Robustez: alm de um bom desempenho, um framework oferece escalabilidade para dar apoio s
exigncias dos portais de grande porte. Isto inclui trabalhar com um ambiente de balanceamento de carga, onde ser-
vidores web podem ser dinamicamente adicionados ou removidos, dependendo da demanda e das exigncias de a-
cesso. Escalando para mltiplos servidores, tambm aumenta a robustez e a disponibilidade da soluo, dando supor-
te tolerncia de falhas de hardware.
Integrao Total com Aplicaes: os frameworks fornecem uma camada de apresentao comum para todo o por-
tal. As informaes provenientes dos aplicativos so disponibilizadas para o portal atravs de subsees de uma p-
gina, que recebem diferentes nomes nos diferentes produtos: interfaces, portlets, gadgets e webparts so al-
guns exemplos. Adotaremos "interface". Uma pgina do portal pode conter uma ou mais interfaces, que podem per-
tencer a diferentes aplicativos. O framework fornece ainda uma camada de comunicao entre as interfaces, que
permite aos aplicativos trocarem informaes de uma maneira fcil e genrica. A integrao das interfaces dentro de
uma pgina do portal permite ao framework ter um maior controle da identidade visual do portal corporativo. Tecno-
logias como CSS, XML e XSL so utilizadas pelo framework para controlar e manter a consistncia visual das in-
formaes exibidas para o usurio final.
Gerando Log e Relatrios: incluem ferramentas para registro e gerao de relatrios sobre a utilizao do portal.
Com isso, desenvolvedores tm uma preocupao a menos ao implementar suas aplicaes. Estas informaes so
essenciais para que os administradores possam controlar e analisar o ROI do portal.
Mecanismo de Busca: a capacidade de centralizao e integrao da busca nas diferentes aplicaes, bem como em
documentos corporativos, esto entre as principais funcionalidades oferecidas por um framework. A busca geral-
mente integrada com a personalizao e o controle de acesso do portal, retornando apenas resultados de reas s
quais os usurios tenham permisso de acesso.
Segurana: aplicaes construdas a partir de um framework no precisam preocupar-se com a administrao da se-
gurana do portal. Acesso via HTTPS, validao de login, integrao com mecanismos de autenticao externos e a
tecnologia single-sign-on (senha nica de acesso a todas aplicaes) so tratados pelo prprio portal. Isto no centra-
liza a autenticao e alivia os tcnicos de grandes preocupaes no desenvolvimento de uma soluo.
Personalizao, Colaborao e Integrao com SGC (ou CMS - Content Management System); (ver adiante)

Em sua essncia, o portal corporativo permite empresa organizar tanto a distribuio e uso de seus ativos de tecnologia da
informao, quanto o acesso ao conhecimento em seu estado mais genuno, ou seja, face a face, a partir do relacionamento
humano. Traz alta capacidade de criao de contexto de uso das informaes e facilidade de integrao interface de trabalho
de aplicaes como ERP, CRM, e-mail, agendas e calendrios, ferramentas de escritrio, de busca, CGS, LMS, gerenciamen-
to de documentos, ferramentas de comunicao e colaborao e aplicaes desenvolvidas internamente.
Como os portais permitem embutir muitas ferramentas, tecnologias e utilidades, alm dos benefcios diretos resultantes de sua
utilizao massiva, grande parte dos investimentos realizados em T.I. passam a ser consolidados e depreciados dentro da em-
presa. Iniciativas mais amplas de portal podem estender suas funcionalidades a parceiros, fornecedores, clientes, distribuido-
res, acionistas e outros interessados.
Os portais corporativos parecem responder positivamente s necessidades competitivas das companhias, valorizando simulta-
neamente as expectativas de ROI, o uso efetivo dos ativos da tecnologia da informao e seus ativos intelectuais.

Gesto de Contedo
Um componente importante de qualquer soluo de portal corporativo deveria ser a descentralizao e delegao de poder
para que os funcionrios possam facilmente incluir informao e conhecimento no sistema e ter estes inputs eficientemente
e rapidamente distribudos para grupos especficos, toda a empresa e at mesmo clientes. Dessa maneira, as implementaes
Sistema de Gesto de Contedo (SGC), associadas com implementaes portais corporativos, representam uma oportunidade
formidvel e um desafio para as organizaes e consultorias envolvidas na implementao de portais corporativos.
139
Os SGCs esto se tornando uma necessidade prtica em operaes web onde milhares de pginas compartilham de elementos
comuns (ex: marca da empresa). muito difcil manter a integridade de pginas de site e seus vrios links, de maneira geral,
sem o uso de SGCs avanados. Em um ambiente de publicao web, uma simples pgina ou conjunto de pginas pode ser
formada a partir de centenas de fontes de dados, links, gifs e imagens, que so armazenados em arquivos distintos.
Os SGCs mais avanados permitem a integrao fcil e dinmica de dados muito estruturados (dos sistemas de back-end) e
de dados noestruturados (informados pelos indivduos de dentro e de fora da empresa). Os SGCs podem tambm ser inte-
grados profundamente com aplicaes eletrnicas de workflow e outras ferramentas de colaborao e gerenciamento de pro-
jeto. Um processo padro de SGC geralmente envolve os seguintes passos:
1) Criao de Documentos;
2) Reviso de Documentos;
3) Incluso de Metadata e Controle de Qualidade;
4) Publicao;
5) Reviso Peridica;
6) Arquivamento ou Eliminao dos Documentos.
As implantaes de SGC podem desempenhar um papel crtico na implementao dos portais corporativos. Os SGCs forne-
cem a infra-estrutura tcnica e os processos centrais que garantem que o contedo correto, atualizado e pontual estar dispo-
nvel para aqueles que precisarem. Embora engenhosa, em um nvel conceitual, as plataformas SGC podem ser bastante dife-
rentes em termos de suas vrias caractersticas tcnicas. Algumas das caractersticas encontradas nas solues SGC mais a-
vanadas esto includas, mas no limitadas, na seguinte lista:
Funcionalidades de Criao e Design
o Existem poucas limitaes de layout e projeto;
o O contedo separado do formato;
o Incluso de ferramentas grficas e intuitivas para se construir um workflow;
o Permite-se que os usurios no apenas publiquem informao / contedo, mas tambm customizem facil-
mente a interface de suas publicaes;
o Facilidade para os usurios no-tcnicos trabalharem com seus aplicativos de escritrio (desktop);
o Os templates so modificados facilmente;
o Metadata incluida automaticamente;
o Permite-se a criao de documentos baseados em XML por usurios que desconheam XML;
o Facilidade para o usurio organizar, classificar e fazer referncias cruzadas do contedo publicado;
o Permisso para o usurio associar facilmente termos de busca (palavraschave) com o contedo criado;
o Suporte publicao de contedo em muitos tipos de arquivos (ex.: udio, vdeo, imagem, apresentao,
cdigo HTML, componentes Java, arquivos ZIP para download, etc.);
o Permisso para os criadores de contedo inclurem nveis de prioridade no documento que ser publicado
ou distribudo para grupos selecionados;
o Habilidade para customizar dinamicamente a navegao, o contedo e aplicativos que sero mostrados a di-
ferentes grupos de usurios;
o Usurios podem utilizar as ferramentas para criao de contedo que lhes sejam mais adequadas.
Definio de Regras
o Permite-se mudanas fceis de regras para autoria, edio, aprovao, publicao e remoo de contedo;
o Os usurios comuns podem tambm definir ou mudar facilmente as regras e fluxo do processo de publica-
o das pginas;
o Os empregados e/ou o webmaster podem gerenciar facilmente papis e direitos de acesso;
o Permite-se a publicao pblica e com controle de privacidade (isto , os usurios controlam quem tm a-
cesso s suas pginas publicadas).
Administrao e Controle de Verses
140
o Muitas opes para controle de verso;
o Permite-se visualizar o histrico de mudanas de algum item especfico que tenha sido publicado;
o Gerao automtica de atributos (metadata) associados com cada documento publicado (data da criao,
criador, tamanho do documento, indicador de item novo, indicador de item atualizado, etc.);
o Permite-se que papis sejam facilmente designados: quem pode ler, editar, arquivar e eliminar um docu-
mento ou pgina;
o Permite-se a adio de comentrios para documentos revisados;
o Permite-se voltar atrs na publicao de itens caso necessrio;
o So fornecidos relatrios e ferramentas para monitorar facilmente o sistema;
o Inclui alertas via e-mail para os administradores;
o Arquivos totalmente passveis de auditoria so fornecidos.
Arquitetura
o Inclui servidores separados para desenvolvimento, teste e produo?
o Inclui um repositrio global e robusto? O sistema permite a criao de repositrios agrupados?
o Qual o nvel de granularidade que o contedo pode ser armazenado no repositrio? Esses nveis so facil-
mente configurados pelo usurio? So facilmente remontadas e disponibilizadas novamente?
o O sistema produz solues em termos de redundncia no caso de perda total ou parcial dos repositrios?
o O sistema simplifica a reclassificao e recombinao de contedo para novos usurios e para a entrega a-
travs de mltiplos canais ?
o Quais so as habilidades de integrao do sistema? E as ferramentas de desenvolvimento e aplicaes?
o baseado em XML? Suporta LDAP? Quais outros padres so suportados?
o O sistema se integra com as plataformas lderes de PdCC, bancos de dados (Oracle, Sybase, SQL Server,
Informix, etc.), aplicaes legadas, servidores web, servidores de aplicao, servidores comerciais, etc. ?
So fornecidos adaptadores pr-desenvolvidos para essas integraes?
o Ele suporta a integrao de fornecedores e parceiros em um Processo de Gerenciamento de Contedo ne-
cessrio para disponibilizar transaes de comrcio eletrnico em tempo real?
o O sistema inclui caching?
o O sistema inclui procedimentos simples para backup?
Os aspectos essencialmente tcnicos relacionados aos SGC, embora bastante importantes e no triviais, dizem respeito apenas
a uma pequena parte das questes relacionadas a uma efetiva implementao de sistemas de gerenciamento de contedo no
contexto de portais corporativos. Muito mais importante so os temas estratgicos e organizacionais que necessariamente
devem ser transformados durante processos de implementao de SGCs.
Uma efetiva gesto de contedo pode transformar como uma empresa pblica, compartilha e utiliza informao, conhecimen-
to e poder. Por isso, novas polticas de compartilhamento de informao interna e externa (com clientes) e descries de car-
go (definindo responsabilidades, inclusive da alta gerncia) devem acompanhar a implementao das solues de SGC.

JSR 168 - Java Specification Request 168 Portlet Specification
O JSR 168 da Sun define um padro API oferecendo interface comum para agregar diversas fontes e aplicaes de contedo
em um nico portal. suportado pelo Sun ONE Portal Server.
A diferena entre Portal e Portlet tambm importante:
Portal: pode ser definido como uma aplicao baseada na Web que customizada pelo usurio final, tanto em sua
apresentao quanto no seu contedo, inclusive de aplicaes contidas neste. responsvel por agregar o contedo e
outras aplicaes em um ponto nico de entrada para o usurio (e suas ferramentas).
Portlets: so pequenas aplicaes Web que rodam dentro de um portal, ao lado de outras entidades similares. um
componente Web definido pela especificao JSR-168, e gerenciado por um continer, podendo processar requisi-
es e gerar contedo dinmico.
141

WSRP - Web Services for Remote Portlets
O WSRP, do OASIS, uma forma padronizada simples de integrao de aplicaes / contedos remotos dentro de portais,
oferece aos administradores de portais poderem escolher entre uma rica variedade de servios e permitem a integrao deles
em seus portais sem esforos de programao. Como resultado, os WSRP se tornaram os meios para os fornecedores de con-
tedo e aplicaes para fornecer seus servios para as organizaes rodando portais de uma forma fcil e consumvel.
Enquanto Web Services permitem a reutilizao de servios de back end, o WSRP permite a reutilizao de toda a interface
com o usurio. Em outras palavras, permite aos provedores de solues integrarem os Web services a portais sem a necessi-
dade de escrever cdigos de comunicao com a plataforma que roda servios.
O WSPR define os seguintes atores em uma arquitetura WSPR:
WSRP producer: este um Web service que oferece um ou mais por-
tlets, e implementa um conjunto de interfaces WSRP, fornecendo um
conjunto comum de operaes para os consumidores. Dependendo da
implementao, um produtor pode oferecer apenas um portlet, ou pode
fornecer um container para implantao e gerenciamento de vrios por-
tlers. O produtor um Web service completo (descrito por WSDL).
WSRP portlet: A WSRP portlet is a pluggable user interface component
that lives inside of a WSRP producer and is accessed remotely through
the interface defined by that producer. A WSRP portlet is not a Web
service in its own right (it cannot be accessed directly, but instead must
be accessed through its parent producer).
WSRP consumer: This is a Web service client that invokes producer-
offered WSRP Web services and provides an environment for users to
interact with portlets offered by one or more such producers. The most
common example of a WSRP consumer is a portal.
WSRP defines a set of common interfaces that all WSRP Producers are
required to implement and which WSRP Consumers must use to interact
with remotely-running portlets. Standardizing these interfaces allows a
portal to interact with remotely-running portlets generically, since it has
a well-defined mechanism for communicating with any WSRP-
compliant producer. The WSRP Specification requires that every pro-
ducer implement two required interfaces, while allowing them to option-
ally implement two others as well:
Service Description Interface (required): The Service Description
Interface allows a WSRP producer to advertise its capabilities to perspective consumers. A WSRP consumer can use this in-
terface to query a producer to discover what portlets the producer offers, as well as additional metadata about the producer
itself. This interface can act as a discovery mechanism to determine the set of offered portlets, but also importantly allows
consumers to determine additional information about the producer's technical capabilities. The producer's metadata might
include information about whether the producer requires registration or cookie initialization before a consumer can interact
with any of the portlets.
Mark-up Interface (required): The Markup Interface allows a WSRP consumer to interact with a remotely running portlet
on a WSRP producer. For example, a consumer would use this interface to perform some interaction when an end-user sub-
mits a form from the portal page. Additionally, a portal might need to simply obtain the latest mark-up based on the current
state of the portlet (for example when the user clicks refresh or interaction with another portlet on the same page takes place).
Registration Interface (optional): The Registration Interface allows a WSRP producer to require that WSRP consumers
perform some sort of registration before they can interact with the service through the Service Description and Mark-up inter-
faces. Through this mechanism a producer can customize its behavior to a specific type of consumer. For example, a producer
might filter the set of offered portlets based on a particular consumer. In addition, the Registration Interface serves as a me-
chanism to allow the producer and consumer to open a dialogue so that they can exchange information about each others'
technical capabilities.
Portlet Management Interface (optional): The Portlet Management Interface gives the WSRP consumer access to the life
cycle of the remotely-running portlet. A consumer would have the ability to customize a portlet's behavior or even destroy an
instance of a remotely-running portlet using this interface.


142
Acessibilidade
A importncia dessa temtica na rea da tecnologia da informao, tem se tornado um foco de ateno de gestores pblicos e
privados e equipes desenvolvedoras de sistemas. Acessibilidade na internet se refere flexibilidade de acesso informao e
interao de usurios que possuem algum tipo de deficincia, quando os mesmos interagem com mecanismos de navegao,
manuseio de pginas e telas e com operao de software.

Decreto n 5296, de 02/12/2004
Segundo o Decreto n. 5.296, de 02/12/2004, acessibilidade significa: condio para utilizao, com segurana e autonomia,
total ou assistida, dos espaos, mobilirios e equipamentos, das edificaes, dos servios de transporte e dos dispositivos,
sistemas e meios de comunicao e informao, por pessoa portadora de deficincia ou com mobilidade reduzida.
Algumas situaes e caractersticas que o usurio pode estar sujeito e que podem impactar sua navegao:
Incapacidade de ver, ouvir ou deslocar-se;
Impossibilidade de interpretar certos tipos de informao;
Dificuldade visual para ler ou compreender textos;
Falta de percepo de texto e de elementos grficos quando vistos sem cores;
Dificuldade para falar ou compreender a lngua em que o documento foi escrito.
Essas diferentes situaes precisam ser consideradas pelos gestores de intranets e portais corporativos, para que possam ofe-
recer respostas simultneas a vrios grupos de deficientes.
Um stio que respeita a navegao dos deficientes visuais, deve obedecer a regras simples que possibilitam uma boa interpre-
tao das pginas por aplicativos de leitura de tela, proporcionando aos deficientes visuais entendimento do contedo sem que
tenham que "adivinhar" os caminhos que levam informao.
Deficientes visuais utilizam o teclado como ferramenta principal de navegao na web, feita atravs de tabulaes e reconhe-
cimento de telas apresentadas no browser. O aplicativo de leitura de tela l a parte textual da pgina e reconhece a existncia
de imagens e animaes em flash, contudo essas imagens e animaes sempre aparecem como algo sem sentido, pois a men-
sagem que passa no assimilada.
Por isso, toda informao deve, tambm, ser apresentada na forma de texto. Se uma informao for expressa de outra forma,
por exemplo, imagem, animao, filme ou som, ela dever ser repetida na forma de descrio textual. Esta descrio textual
deve ser equivalente, ou seja, deve preservar o sentido da informao. No HTML, os atributos alt e longdesc foram
criados para textos equivalentes. Outras tcnicas para tornar a navegao mais amigvel para portadores de deficincia:
Use rtulo de identificao e descrio para imagens e logomarcas;
Use rtulo de identificao de links em textos e imagens indicando o destino do mesmo;
Use rtulo de identificao em formulrios;
Use "list menus" na navegao por tabulao - essa uma das boas opes para navegao;
Os scripts geralmente no so muito bem resolvidos pelos aplicativos de leitura de tela. Se us-los, tenha sempre
uma segunda opo de navegao;
Sites totalmente construdos em flash no so reconhecidos pelos aplicativos de leitura de tela, impossibilitando a
navegao. As animaes flash podem conter descries por meio do TAG do atributo TITLE, colocado no TAG
OBJECT, que chama a animao flash;
Fornea ttulos de links que faa sentido quando lidos fora do contexto;
No confie apenas na cor para transmitir as informaes sobre links. Ex: Clique nos links vermelhos para editar....
Utilize sempre os atributos de TAG com o parmetro alt="descrio..." ou title="descrio...". Eles so reconhecidos
pelo aplicativo de leitura de tela e ajudam a tornar os caminhos mais claros.

Modelo de acessibilidade
A histria dos modelos de acessibilidade comeou em 1998 com a "Section 508", que uma lei que define: "a tecnologia
inacessvel interfere na capacidade individual de adquirir e usar a informao de maneira rpida e fcil".
143
No que se refere a acesso ao computador, ocorrem quatro tipos de situaes por parte de usurios com necessidades especiais:
Acesso ao computador sem mouse: pessoas com cegueira, dificuldade de controle dos movimentos, paralisia ou
amputao de um membro superior. Tais pessoas sentem vrias dificuldades na utilizao do mouse;
Acesso ao computador sem teclado: pessoas com amputaes, grandes limitaes de movimentos ou falta de fora
nos membros superiores tm srias dificuldades para utilizar o teclado tradicional. Nesses casos, a interao poder
ser feita atravs de um perifrico especial de reconhecimento da fala ou de um emulador de teclado na tela;
Acesso ao computador sem monitor: a verdade que a informao processada por um computador no de natu-
reza visual. Para obterem a informao que projetada na tela, os cegos recorrem a um software (programa leitor de
tela) que capta essa informao e a envia para um sintetizador de voz ou para um terminal Braille;
Acesso ao computador sem udio: encontram-se relacionadas neste caso pessoas com baixa audio e pessoas com
surdez completa. H dificuldade em acessar informaes que se encontram disponveis somente atravs de udio.
Dentro deste contexto, o Departamento de Governo Eletrnico tem o compromisso de elaborar um Modelo de Acessibilidade
para o desenvolvimento e a adaptao de contedos do governo na internet, gerando um conjunto de recomendaes que de-
vem ser consideradas. Uma das principais atribuies do Governo Federal a incluso social (diminuir desigualdades).
O Modelo de Acessibilidade proposto baseado nas regras do W3C e outras normas, com as seguintes vises:
Viso Tcnica: cartilha de recomendaes prticas para a construo e / ou adaptao de stios eletrnicos. A Viso
Tcnica voltada ao desenvolvedor, pessoa que far as alteraes nos cdigos dos stios eletrnicos;
Viso do Cidado: arquitetura de segmentao da Viso Tcnica. A Viso do Cidado do Modelo de Acessibilidade
proporciona uma orientao e compreenso mais lgica e intuitiva do modelo propriamente dito e da Viso Tcnica.
Abaixo ento relacionamos as reas de Acessibilizao compreendidas na Viso do Cidado:
o rea da Percepo: trata de benefcios relacionados apresentao do contedo, da informao. Ela preo-
cupa-se com a percepo de elementos como grficos, sons, imagens, multimdia e equivalentes.
o rea da Operao: preocupa-se com a manipulao da informao, do contedo. Deve garantir formas al-
ternativas ao acesso s informaes atravs de maneiras diferenciadas de navegao ou tcnica similar.
o rea do Entendimento: trata de questes relacionadas compreenso do contedo publicado. Ela deve ga-
rantir que todo o contedo apresentado seja de fcil compreenso para qualquer tipo de usurio.
o rea da Compatibilidade: aborda questes como a necessidade de utilizarmo-nos sempre de tecnologias
acessveis e compatveis com o modelo aqui proposto.
Alm disso, podemos classificar os contedos em trs grandes Nveis de Acessibilidade, por prioridades, onde o Nvel 1 so
as exigncias bsicas de acessibilidade (pontos obrigatrios); o Nvel 2 facilita o acesso s informaes do documento, e o
Nvel 3 facilita o acesso aos documentos armazenados na Web. O nvel AAA aquele que est de acordo com todos nveis.
Os cinco passos do processo de acessibilizao so:
1. Verificao da necessidade de acessibilizao do contedo;
2. Acessibilizao do contedo;
3. Validao da acessibilidade do contedo;
4. Promoo da acessibilidade conquistada;
5. Garantia contnua da acessibilidade.

Cartilha tcnica
A cartilha tcnica de recomendaes foi desenvolvida buscando atender e propiciar a acessibilizao dos stios governamen-
tais, como proposto em "eMAG, Acessibilidade de Governo Eletrnico - Modelo".
Diretriz 1. Fornea alternativas equivalentes para o contedo grfico e sonoro.
Diretriz 2. Assegure-se de que seu stio seja legvel e compreensvel mesmo sem o uso de formataes.
Diretriz 3. D preferncia s tecnologias de marcao e formatao.
Diretriz 4. Assegure que toda a informao seja interpretada corretamente, com clareza e simplicidade.
144
Diretriz 5. Assegure que as tecnologias utilizadas funcionem - de maneira acessvel - independente de programas,
verses e futuras mudanas.
Diretriz 6. Assegure sempre o controle do usurio sobre a navegao no stio.
Diretriz 7. Identifique claramente quais so os mecanismos de navegao.
Diretriz 8. Em casos no contemplados pelas diretrizes anteriores, utilize sempre recursos reconhecidos - por institu-
ies com propriedade no assunto - como tecnologias acessveis.
Os recursos tcnicos para implementao da acessibilidade em HTML (a seguir) sumariza as recomendaes da cartilha.

Recursos tcnicos para implementao da acessibilidade em HTML
Visando tornar a Web acessvel a um nmero cada vez maior de pessoas e com o objetivo de lev-la ao potencial mximo de
interoperabilidade, o W3C, comit formado por grandes empresas, criou o WAI (Web Accessibility Initiative). Entre outras
atribuies, o WAI mantm grupos de trabalho elaborando conjuntos de diretrizes para garantir a acessibilidade do contedo
da Web s pessoas com necessidades especiais, ou que acessam a Web em condies especiais.
As prticas recomendadas incluem Contedo Web (HTML, CSS, imagens, sons, etc), Authoring Tool (ferramentas que
criam pginas Web), User Agent (navegadores e mdia), e as tecnologias (XML, SVG, SMIL, plataformas, etc).
uma boa prtica utilizar <HTML lang="fr"> para identificar o idioma da pgina, e <SPAN lang="it"> para indicar
uma mudana na lngua no meio do texto. Isso facilita softwares de reconhecimento de caracteres especiais.
Utilizar folhas de estilos (CSS) para controlar o layout e a apresentao do documento.
Abreviaes e citaes devem ser indicadas pelos elementos <ACRONYM> e <BLOCKQUOTE>.
Em frmulas matemticas, garantir que as variveis so bem definidas. Por exemplo, F = Fora, m = massa, etc.
Elementos CITE (citaes), DFN, CODE (cdigo), SAMP, KBD, VAR, INS (texto inserido), DEL (texto deletado).
Nas tabelas as informaes das linhas e colunas devem ser definidas, e um sumrio da tabela includo.
Fornecer um equivalente texto para imagens utilizadas como links, atravs do elemento "alt", "longdesc", etc.
Criar uma ordem lgica de "tabs" entre os links e figuras (elemento TABINDEX).
Incluir atalhos de teclas (elemento ACCESSKEY).
Incluir descries longas de imagens, e evitar arte ASCII, ou utilizar um link para pular esses blocos ASCII.
Deve existir contraste entre as cores das figuras, fundo e texto, inclusive para facilitar a visualizao monocromtica.
Prover o texto equivalente udios e vdeos. Isso tambm vale para grficos, botes grficos, etc.
Escrever para navegadores que no suportam FRAMES, e caso sejam utilizados, descrever o seu relacionamento.
Informar previamente ao usurio o destino e resultado da ao, quando houver campos e elementos do formulrio.
Assegurar a acessibilidade de objetos programados (applets, scripts, programas interpretados, objects).
Evite comandos que caram em desuso: "blink", "marquee", "center", "font", "menu", "u", entre outros.
No provocar o aparecimento de janelas de sobreposio, janelas popup ou mudanas dinmicas na pgina atual.
Sempre especificar fontes genricas como opes em folhas de estilos.
A linguagem deve ser clara e acessvel (evite a voz passiva, linguagens idiomticas, grias, frases longas, etc).

Exemplo 1: Para uma imagem simples, decorativa ou acidental, fazer apenas uma breve descrio indicando que a imagem
de um carro amarelo, o cdigo pode ser:
<img src="carro.jpg" alt="Foto de um carro amarelo.">
Exemplo 2: O atributo "longdesc" foi criado para situaes em que a descrio a ser feita deve ser mais longa do que a per-
mitida pelo atributo "alt".
<img src="mont_rio.jpg" longdesc="montanhas.htm" alt="Foto de montanhas no Rio de Janeiro.">
145
Exemplo 3: Se voc produziu um script (ou um programa) que causa um aviso sonoro, para ser tocado se o visitante da sua
pgina tentar enviar um formulrio antes dos campos requeridos estarem preenchidos, coloque no seu programa (ou script) a
capacidade de escrever uma mensagem na tela, que diga algo como:
Alerta: "Voc tentou submeter um formulrio incompleto. Por favor, preencha os campos necessrios".

146
Segurana da Informao

Poltica de segurana
Os objetivos de uma poltica de segurana so, de acordo com a ICP-Brasil:
Definir o escopo da segurana das entidades;
Orientar, por meio de suas diretrizes, todas as aes de segurana das entidades
Reduzir riscos e garantir a integridade, sigilo e disponibilidade das informaes dos sistemas e recursos
Permitir a adoo de solues de segurana integradas
Servir de referncia para auditoria, apurao e avaliao de responsabilidades

Regras gerais da Poltica de Segurana
poltica de segurana das entidades so aplicados os seguintes conceitos:
Ativo de Informao: o patrimnio composto por todos os dados e informaes geradas e manipuladas durante a
execuo dos sistemas e processos das entidades;
Ativo de Processamento: o patrimnio composto por todos os elementos de hardware e software necessrios para
a execuo dos sistemas e processos das entidades, tanto os produzidos internamente quanto os adquiridos;
Controle de Acesso: so restries ao acesso s informaes de um sistema exercido pela gerncia de Segurana da
Informao das entidades;
Custdia: consiste na responsabilidade de se guardar um ativo para terceiros. Entretanto, a custdia no permite au-
tomaticamente o acesso ao ativo, nem o direito de conceder acesso a outros;
Direito de Acesso: o privilgio associado a um cargo, pessoa ou processo para ter acesso a um ativo;
Ferramentas: um conjunto de equipamentos, programas, procedimentos, normas e demais recursos atravs dos
quais se aplica a Poltica de Segurana da Informao das entidades;
Incidente de Segurana: qualquer evento ou ocorrncia que promova uma ou mais aes que comprometa ou que
seja uma ameaa integridade, autenticidade, ou disponibilidade de qualquer ativo das entidades;
Poltica de Segurana: um conjunto de diretrizes destinadas a definir a proteo adequada dos ativos produzidos
pelos Sistemas de Informao das entidades;
Proteo dos Ativos: o processo pelo qual os ativos recebem classificao quanto ao grau de sensibilidade. O
meio de registro de um ativo de informao recebe a mesma classificao de proteo dada ao ativo que o contm;
Responsabilidade: definida como as obrigaes e os deveres da pessoa que ocupa determinada funo em relao
ao acervo de informaes;
Senha Fraca ou bvia: aquela onde se utilizam caracteres de fcil associao com o dono da senha, ou que seja
muito simples ou pequenas, tais como: datas de aniversrio, casamento, nascimento, o prprio nome, o nome de fa-
miliares, seqncias numricas simples, palavras com significado, dentre outras.
A abrangncia da poltica de segurana de uma entidade deve levar em conta os requisitos de segurana humana, segurana
fsica, segurana lgica (recursos criptogrficos, etc). Algumas de suas regras gerais so:
A Poltica de Segurana Geral se aplica a todos os recursos humanos, administrativos e tecnolgicos pertencentes s
entidades que a compem. A abrangncia dos recursos citados refere-se tanto queles ligados s entidades em carter
permanente quanto temporrio;
Esta poltica deve ser comunicada para todo o pessoal envolvido e largamente divulgada atravs das entidades, ga-
rantindo que todos tenham conscincia da mesma e a pratiquem na organizao;
Todo o pessoal deve receber as informaes necessrias para cumprir adequadamente o que est determinado na po-
ltica de segurana;
147
Um programa de conscientizao sobre segurana da informao dever ser implementado para assegurar que todo o
pessoal seja informado sobre os potenciais riscos de segurana e exposio a que esto submetidos os sistemas e o-
peraes das entidades. Especificamente, o pessoal envolvido ou que se relaciona com os usurios deve estar infor-
mado sobre ataques tpicos de engenharia social e como se proteger deles;
Os procedimentos devero ser documentados e implementados para garantir que quando o pessoal contratado ou
prestadores de servios sejam transferidos, remanejados, promovidos ou demitidos, todos os privilgios de acesso
aos sistemas, informaes e recursos sejam devidamente revistos, modificados ou revogados;

Ameaas, ataques e anlise de vulnerabilidade
A anlise de risco fundamental para a segurana de qualquer organizao, pois garante que os controles e gastos sejam co-
mensurveis com os riscos expostos por ela. Definem-se os seguintes conceitos:
Ameaa: um evento que causa dano a empresa.
Vulnerabilidades: so aberturas, fraquezas ou falta de controles da empresa s ameaas
Ativos: so os bens corporativos
Risco: definido como um contexto que inclui as ameaas, vulnerabilidades e o valor a proteger (ativo)
A anlise de risco usada para analisar, estudar, avaliar as vulnerabilidades e a falta de controle que pode gerar ameaas para
a empresa. E essa analise no deve ser baseada somente nas tecnologias mas tambm em todos os processos e pessoas que
fazem parte da instituio. O gerenciamento de risco dividido em 4 (quatro) etapas bsicas:
Identificao dos Riscos: como o prprio nome j diz, nessa etapa so identificados os riscos a que o negcio (o fo-
co sempre deve ser este) est sujeito. O primeiro passo a realizao de uma Anlise de Riscos, que pode ser tanto
quantitativa baseada em estatsticas, numa anlise histrica dos registros de incidentes quanto qualitativa ba-
seada em know-how, e realizada por especialistas, que tm profundos conhecimentos sobre o assunto.
Quantificao dos Riscos: nessa etapa mensurado o impacto que um determinado risco pode causar ao negcio.
Como praticamente impossvel oferecer proteo total contra todas as ameaas existentes, preciso identificar os
ativos e as vulnerabilidades mais crticas, possibilitando a priorizao dos esforos e os gastos com segurana. Uma
das ferramentas existentes no mercado o BIA (Business Impact Analysys). Esta tcnica consiste, basicamente, da
estimativa de prejuzos financeiros decorrentes da paralisao de um servio. Responde a questes do tipo "quanto
sua empresa deixaria de arrecadar caso um sistema estivesse indisponvel durante 2 horas?"
Tratamento dos Riscos: uma vez que os riscos foram identificados e a organizao definiu quais sero tratados, as
medidas de segurana devem ser de fato implementadas. Alguns riscos podem ser eliminados, outros reduzidos ou
at mesmo aceitos pela empresa, tendo sempre a situao escolhida documentada. S no permitido ignor-los.
Nessa etapa podem ser definidas medidas adicionais de segurana, como os Planos de Continuidade dos Negcios.
Monitorao dos Riscos: atravs de uma monitorao constante, possvel identificar quais reas foram bem suce-
didas e quais precisam de revises e ajustes. O ideal que este trabalho seja norteado por um modelo de Gesto de
Segurana, que defina atribuies, responsabilidades e fluxos de comunicao interdepartamentais.

Auditoria de Sistemas e Solues baseadas em Tecnologia da Informao
Auditoria de segurana possui o objetivo de assegurar o cumprimento dos padres definidos e, conseqentemente, medir a
eficcia da estratgia de segurana adotada. Ela divide-se em interna e externa.
A auditoria interna realizada com recursos materiais e pessoas que pertencem empresa auditada. A auditoria interna existe
por expressa deciso da empresa, que pode optar por sua dissoluo em qualquer momento.
Por outro lado, a auditoria externa realizada por pessoas afins empresa auditada; Se pressupe uma maior objetividade que
na auditoria interna, devido ao maior distanciamento entre auditores e auditados
Um sistema completo de segurana deve compreender:
Elementos administrativos
Definio de poltica de segurana
Organizao e diviso de responsabilidades
148
Segurana fsica e contra-catstrofes (incndio, terremotos, etc.)
Prticas de segurana do pessoal
Elementos tcnicos e procedimentos
Sistemas de segurana (de equipes e de sistemas, incluindo todos os elementos, tanto redes como terminais).
Aplicao dos sistemas de segurana, incluindo datas e arquivos
O papel dos auditores, tanto internos como externos
Planos de continuidade de negcios
Algumas ferramentas e tcnicas para a auditoria de sistemas so:
Questionrios: enviado para pessoas de uma rea especfica, para recolher informaes sobre o seu funcionamento,
no precisando ser os responsveis oficiais pela rea.
Entrevistas: uma das atividades pessoais mais importantes do auditor, que pode obter as informaes mais sensveis
sobre o auditado. Uma entrevista bem preparada e sistematizada fundamental para a eficcia desta etapa.
Checklist: o auditor deve aplicar um checklist de modo que o auditado responda ou fornea as informaes entre um
range de respostas (por exemplo, 1-5, ou Muito Deficiente, Deficiente, Razovel, Aceitvel e Excelente), ou em res-
postas binrias (Verdadeiro / Falso ou Sim / No).
Software de Auditoria: com freqncia o auditor necessita verificar se os programas e sistemas realizam as funes
previstas, alm de medir o nvel de segurana e outros requisitos. Para isso existem softwares especficos, que po-
dem medir a vulnerabilidade da rede, gerar logs, grficos e planilhas.
o IDS (intrusion detection system): um dos mecanismos utilizados por esses sistemas a deteco por assina-
tura, em que a assinatura tpica de um trfego malicioso permite identific-lo como um ataque.
o Nessus: uma ferramenta largamente empregada na Internet para anlise de vulnerabilidades em sistemas
operacionais o NESSUS, que permite realizar diagnstico de vrios tipos de dispositivos instalados em
redes que utilizam o protocolo TCP/IP. Ele permite que se faa isso de uma forma segura, no permitindo
que usurios no autorizados possam escanear sua rede com ele. Ele composto por duas partes, sendo um
cliente e um servidor. Pode-se us-lo a partir do Windows, Linux e Unix.

Requisitos de Segurana
Os princpios bsicos de segurana em sistemas so (CIDA):
Confidencialidade: proteo da informao compartilhada contra acessos no autorizados; obtm-se pelo controle
de acesso (senhas) e controle das operaes individuais de cada usurio (log).
Integridade: garantia da veracidade da informao, que no pode ser corrompida por alteraes acidentais ou no
autorizadas, no caso de adulteraes aps a assinatura de um documento, por exemplo.
Disponibilidade: preveno de interrupes na operao de todo o sistema (hardware + software); uma quebra do
sistema no deve impedir o acesso aos dados
Autenticidade: garantia da identidade dos usurios. Quando aplicados documentos digitais, consiste tambm de:
o Irrefutabilidade: o requisito de segurana que garante a impossibilidade de que uma autoria de docu-
mento eletrnico seja negada posteriormente.
o Tempestividade: a qual nos permite saber com total segurana se determinado documento foi ou no pro-
duzido naquela ocasio.

Certificao digital
As tcnicas de certificao digital oferecem seis tipos de servios bsicos. Sem estes predicados no possvel realizar o co-
mrcio eletrnico seguro na Internet:
Disponibilidade: garante que uma informao estar disponvel para acesso no momento desejado.
Integridade: garante que o contedo da mensagem no foi alterado.
149
Confidencialidade (privacidade ou sigilo): impede que pessoas no autorizadas tenham acesso ao contedo da
mensagem, garantindo que apenas a origem e o destino tenham conhecimento.
Autenticidade da origem: garante a identidade de quem est enviando a mensagem.
No-repudiao: previne que algum negue o envio e/ou recebimento de uma mensagem.
Controle de acesso: garante que o contedo da mensagem somente ser acessado por pessoas autorizadas.

Criptografia
O ciframento de uma mensagem baseia-se em dois componentes: um algoritmo e uma chave.
Algoritmo: uma transformao matemtica. Ele converte uma mensagem em claro em uma mensagem cifrada e
vice-versa. Quando o remetente (origem) cifra uma mensagem, ela utiliza um algoritmo de ciframento para trans-
formar o contedo em claro da mensagem em texto cifrado. Quando o destinatrio decifra uma mensagem, ele utiliza
o algoritmo de deciframento correspondente para converter o texto cifrado de novo em uma mensagem clara.
Chave: uma cadeia aleatria de bits utilizada em conjunto com um algoritmo. Cada chave distinta faz com que o
algoritmo trabalhe de forma ligeiramente diferente.
Embora existam algoritmos que dispensem o uso de chaves, sua utilizao oferece duas importantes vantagens. A primeira
permitir a utilizao do mesmo algoritmo criptogrfico para a comunicao com diferentes receptores, apenas trocando a
chave. A segunda vantagem permitir trocar facilmente a chave no caso de uma violao, mantendo o mesmo algoritmo.
O nmero de chaves possveis depende do tamanho (nmero de bits) da chave. Por exemplo, uma chave de 8 bits permite
uma combinao de no mximo 256 chaves (2
8
). Quanto maior o tamanho da chave, mais difcil quebr-la, pois estamos au-
mentando o nmero de combinaes. A segurana passa a residir na chave empregada, e no no algoritmo utilizado.

Criptografia Simtrica
A criptografia simtrica ocorre quando a chave de ciframento a mesma utilizada para deciframento ou esta ltima pode fa-
cilmente ser obtida a partir do conhecimento da primeira, e ambas precisam ser compartilhadas previamente entre origem e
destinatrio, antes de se estabelecer o canal criptogrfico desejado.
DES (Data Encryption Standard): o algoritmo simtrico mais disseminado no mundo. Foi criado pela IBM em
1977 e, apesar de permitir cerca de 72 quadrilhes de combinaes (2
56
), seu tamanho de chave considerado pe-
queno, tendo sido quebrado por "fora bruta" em 1997.
Triple DES (112 ou 168 bits): uma simples variao do DES, utilizando-o em trs ciframentos sucessivos, em-
prega uma verso com duas ou trs chaves diferentes. seguro, porm muito lento para ser um algoritmo padro.
IDEA (International Data Encryption Algorithm): de 128 bits, estruturado seguindo as mesmas linhas gerais do
DES. Mas na maioria dos microprocessadores, uma implementao por software do IDEA mais rpida do que uma
implementao por software do DES. O IDEA utilizado principalmente no mercado financeiro e no PGP (e-mail).
Blowfish (32 a 448 bits): oferece a escolha entre maior segurana ou desempenho atravs de chaves de tamanho va-
rivel. O autor aperfeioou-o no Twofish (proposta para um novo padro do DES, chamado de AES).
RC2, RC4, RC5 (8 a 1024 bits): voltado para criptografia de e-mail corporativo. Tambm possui chave de tama-
nho varivel. Tambm utilizado no protocolo S/MIME.
Rijndael: o NIST lanou um concurso para selecionar um novo algoritmo para ser adotado como o AES - Advanced
Encryption Standard, em substituio do DES. O vencedor foi o Rijndael, criado por belgas e que pode utilizar cha-
ves de 128, 192 e 256 bits.
Apesar de sua simplicidade, existem alguns problemas na criptografia simtrica:
Como cada par necessita de uma chave para se comunicar de forma segura, para um uma rede de n usurios precisa-
ramos de algo da ordem de n
2
chaves, quantidade esta que dificulta a gerncia das chaves;
A chave deve ser trocada entre as partes e armazenada de forma segura, o que nem sempre fcil de ser garantido;
No garante a identidade de quem enviou ou recebeu a mensagem (autenticidade e no-repudiao).

150
Criptografia Assimtrica
Tambm conhecida como criptografia de chave pblica, a criptografia assimtrica est baseada no conceito de par de chaves:
uma chave privada e uma chave pblica. Qualquer uma das chaves utilizada para cifrar uma mensagem e a outra para deci-
fr-la. As mensagens cifradas com uma das chaves do par s podem ser decifradas com a outra chave correspondente. A cha-
ve privada deve ser mantida secreta, enquanto a chave pblica disponvel livremente para qualquer interessado.
A grande vantagem deste sistema permitir que qualquer um possa enviar uma mensagem secreta, apenas utilizando a chave
pblica de quem ir receb-la. Como a chave pblica est amplamente disponvel, no h necessidade do envio de chaves
como feito no modelo simtrico. A confidencialidade da mensagem garantida, enquanto a chave privada estiver segura.
RSA (Rivest, Shamir, Adleman): o algoritmo de chave pblica mais amplamente utilizado, alm de ser uma das
mais poderosas formas de criptografia de chave pblica conhecidas at o momento. O RSA utiliza nmeros primos.
A premissa por trs do RSA que fcil multiplicar dois nmeros primos para obter um terceiro nmero, mas muito
difcil recuperar os dois primos a partir daquele terceiro nmero. Isto conhecido como fatorao.
El Gamal: tambm um sistema comutativo, como o RSA. O algoritmo envolve a manipulao matemtica de
grandes quantidades numricas. Sua segurana advm de algo denominado problema do logaritmo discreto. Assim,
o ElGamal obtm sua segurana da dificuldade de se calcular logaritmos discretos em um corpo finito
Diffie-Hellman: tambm baseado no problema do logaritmo discreto, o criptosistema de chave pblica mais antigo
ainda em uso. Contudo, ele no permite nem ciframento nem assinatura digital. O sistema foi projetado para permitir
a dois indivduos entrarem em um acordo ao compartilharem um segredo tal como uma chave.
Curvas Elpticas: consiste em modificaes de outros sistemas (o ElGamal, por exemplo), que passam a trabalhar
no domnio das curvas elpticas, em vez de trabalharem no domnio dos corpos finitos. Eles possuem o potencial de
proverem sistemas criptogrficos de chave pblica mais seguros, com chaves de menor tamanho.

Hashing
A assinatura digital obtida atravs do uso da criptografia assimtrica (ou de chave pblica) infelizmente no pode ser empre-
gada, na prtica, de forma isolada, devido lentido dos algoritmos assimtricos, em geral cerca de 1.000 vezes mais lentos
do que os simtricos. Assim, na prtica invivel e contraproducente utilizar puramente algoritmos de chave pblica para
assinaturas digitais, principalmente quando se deseja assinar grandes mensagens, que podem levar minutos ou at horas.
Ao invs disso, empregada uma funo Hashing, que gera um valor pequeno, de tamanho fixo, derivado da mensagem que
se pretende assinar, de qualquer tamanho. Assim, a funo Hashing oferece agilidade nas assinaturas digitais, alm de inte-
gridade confivel.
A funo Hashing funciona como uma impresso digital de uma mensagem gerando, a partir de uma entrada de tamanho va-
rivel, um valor fixo pequeno: o digest ou valor hash. Funciona como um check sum de uma mensagem.
MD5 (Message Digest 5): uma funo de espalhamento unidirecional, que produz um valor hash de 128 bits, para
uma mensagem de entrada de tamanho arbitrrio. Foi projetado para ser rpido, simples e seguro. Seus detalhes so
pblicos, e tm sido analisados pela comunidade de criptografia. Existiram outras verses (MD4, MD2, ...)
SHA-1 (Secure Hash Algorithm): uma funo de espalhamento unidirecional inventada pela NSA, gera um valor
hash de 160 bits, a partir de um tamanho arbitrrio de mensagem. Atualmente, no h nenhum ataque de criptoanli-
se conhecido contra o SHA-1. Mesmo o ataque da fora bruta torna-se impraticvel, devido ao seu valor hash.

Protocolos Criptogrficos
Utilizam um esquema hbrido entre a criptografia simtrica (rpida, criptografa a mensagem) e a assimtrica (lenta, distribui-
o de chaves e assinatura digital).
IPSec: padro de protocolos criptogrficos desenvolvidos para o IPv6. Realiza tambm o tunelamento sobre IP.
composto de trs mecanismos criptogrficos (assinatura digital, ciframento simtrico e troca de chaves). Criptografia
e tunelamento so independentes. Permite Virtual Private Network fim-a-fim. Futuro padro para as VPNs.
SSL e TLS: oferecem suporte de segurana criptogrfica para os protocolos NTTP, HTTP, SMTP e Telnet. Permi-
tem utilizar diferentes algoritmos simtricos, hashing e mtodos de autenticao e gerncia de chaves (assimtricos).
PGP: um programa criptogrfico famoso e bastante difundido na Internet, destinado a criptografia de e-mail pes-
soal. Algoritmos suportados: hashing: MD5, SHA-1, CAST-128, IDEA e 3DES, RSA e Diffie-Hellman/DSS.
151
S/MIME: consiste em um esforo de um consrcio de empresas, liderado pela RSADSI e pela Microsoft, para adi-
cionar segurana a mensagens eletrnicas no formato MIME. Apesar do S/MIME e PGP serem ambos padres In-
ternet, o S/MIME dever se estabelecer no mercado corporativo, enquanto o PGP no mundo do mail pessoal.
SET: um conjunto de padres e protocolos, para realizar transaes financeira seguras, como as realizadas com
carto de crdito na Internet. Oferece um canal de comunicao seguro entre todos os envolvidos na transao. Ga-
rante autenticidade X.509v3 e privacidade entre as partes.
X.509: define o relacionamento entre as autoridades de certificao. Faz parte das sries X.500 de recomendaes
para uma estrutura de diretrio global, baseada em nomes distintos para localizao. Utilizado pelo S/MIME, IPSec,
SSL/TLS e SET. Baseado em criptografia com chave pblica (RSA) e assinatura digital (com hashing).

Assinatura Digital
Outro benefcio da criptografia com chave pblica a assinatura digital, que permite garantir a autenticidade de quem envia a
mensagem, associada integridade do seu contedo. Isso feito usando a chave privada para CIFRAR a mensagem, e a cha-
ve pblica para DECIFR-LA. Assim, qualquer um pode ler a mensagem, e quem possui a chave secreta pode escrev-la.
importante perceber que a assinatura digital no garante a confidencialidade da mensagem. Qualquer um poder acess-la e
verific-la, mesmo um intruso, apenas utilizando a chave pblica. Para obter confidencialidade com assinatura digital, basta
combinar os dois mtodos (i.e., assinatura digital com chave pblica + criptografia assimtrica).
Os algoritmos utilizados so o RSA, o El Gamal (j descritos) e o DSA (Digital Signature Algorithm), unicamente destinado
a assinaturas digitais, trata-se de uma variao dos algoritmos de assinatura ElGamal e Schnorr, e foi inventado pela NSA.
Alm disso, existem os Certificados Digitais, que se prope a impedir que a chave pblica fornecida por uma entidade seja
proveniente dela mesma, evitando que cada lado pense que est se comunicando com o outro, quando na verdade esto sendo
interceptados pelo intruso. Tais certificados consistem em chaves pblicas assinadas por uma pessoa de confiana, geralmen-
te no formato padro ITU X.509v3. Servem para evitar tentativas de substituio de uma chave pblica por outra.
CA (Certification Authority): validam outros certificados; so auto-assinados ou assinados por outra CA.
Servidor: utilizados para identificar um servidor seguro; contm o nome da organizao e o nome DNS do servidor.
Pessoais: contm nome do portador e, eventualmente, informaes como endereo eletrnico, endereo postal, etc.
Desenvolvedores de software: utilizados para validar assinaturas associadas a programas.
Autoridades de certificao, como Verisign, Cybertrust e Nortel, assinam certificados digitais garantindo sua validade. Uma
CA tambm tem a responsabilidade de manter uma lista com os certificados revogados (Certificate Revocation List - CRL)


152
Discursivas possveis:
Apresente os principais operadores da lgebra booleana. Qual a importncia da representao binria em sistemas computacionais?
Fale sobre a numerao binria e hexadecimal, e d exemplos das diferentes informaes que um nmero binrio pode representar.
Explique como um programa pode detectar se houve "overflow" ou "underflow" ao adicionar dois nmeros em numerao binria.
Compare e explique as arquiteturas CISC e RISC, explicando os argumentos a favor de cada uma.
O que DMA, e como o computador o utiliza em conjunto com o sistema operacional? Quais so os dispositivos perifricos que o utilizam,
e exemplifique a sua utilizao.
Conceitue e d exemplos onde pode ocorrer uma interrupo de software e uma de hardware.
Cite trs estruturas de endereamento das instrues de mquina, a sua interao com os registradores e explique o seu funcionamento.
Compare as vantagens e desvantagens de se utilizar um Compilador ou Interpretador para a execuo de um programa de computador.
Compare e os sistemas multiprogramados e monoprogramados. Quais as suas caractersticas?
Explique se existe alguma diferena conceitual entre mainframes, mini e microcomputadores?
Conceitue sistema operacional. Qual a sua importncia para um sistema computacional?
Quais so os passos que o sistema operacional toma ao escalonar um processo? Explique.
Descreva o escalonamento de processos Round Robin, para os seguintes processos...
Quais as vantagens e desvantagens da paginao, segmentao e paginao com segmentao?
Descreva um algoritmo de alocao de pginas na memria. Use-o para as seguintes pginas...
Descreva os sistemas de arquivos utilizados pelos sistemas Windows e Unix. Faa uma comparao.
De que formas um sistema operacional pode fazer a comunicao com um dispositivo de hardware?
D um exemplo onde pode ocorrer deadlock, e d uma soluo para o problema de concorrncia.
Quais so os principais objetivos e benefcios de uma rede de computadores?
Explique a diferena entre transmisso ponto-a-ponto e redes de difuso, e entre redes com transmisso sncrona e assncrona.
Descreva a arquitetura OSI ou TCP/IP e explique as funes das camadas.
Descreva um algoritmo de recepo / transmisso de pacotes IP.
Explique o que significa DNS, e qual a sua importncia para a Internet.
Compare os mtodos funcionais / de dados com os mtodos OO, como feito a modelagem, aspectos como a facilidade de compreenso do
domnio, a sua robustez e facilidade de manuteno.
Faa uma modelagem DFD, dado um sistema
Modele um sistema utilizando UML: os seus requisitos (casos de uso), um modelo de domnio (classes) com classes, relaes entre classes,
atributos e restries, e o ciclo de vida de um objeto (diagrama de estados).
Faa uma modelagem MER (Entidade-Relacionamento), dado um sistema
Coloque na xFN (Forma Normal) a(s) seguinte(s) tabela(s)
Descreva um exemplo de estratgia de implementao de gesto de qualidade, as atividades e os seus objetivos.
Cite pontos fracos e fortes de cada um dos modelos de ciclo de vida da Engenharia de Software
Caracterize cada uma das principais atividades do processo de Engenharia de Requisitos.
Em que consistem inspees de software? Qual a sua relevncia em processos de validao e verificao de software?








153
MATERIAL COMPLEMENTAR


SISTEMAS DE COMPUTAO
Organizao de Computadores
http://www.organizacaodecomputadores.kit.net/


ENGENHARIA DE SOFTWARE
Pressman Software Engineering Resources
http://www.rspa.com/spi/


JAVA E WEB
Java e Web para Concursos
Rafael B. Pereira
http://www.rbper.com/java-e-web-para-concursos
http://www.agbook.com.br/book/26055--Java_e_Web_para_Concursos

JAVA OO
Introduo Programao Orientada a Objetos usando Java
Rafael Santos
http://www.elsevier.com.br/site/produtos/Detalhe-produto.aspx?tid=1439&seg=3&isbn=9788535212068&cat=8&origem=Busca


BANCO DE DADOS
Sistemas de Bancos de Dados
http://www.submarino.com.br/produto/1/191303/sistemas+de+banco+de+dados?menuId=1324


MINERAO DE DADOS
Inteligncia Artificial
Stuart Russell e Peter Norvig.
Editora Campus, 2004.