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 1

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 2

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 3

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 4

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 5

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

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, interpreta 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 negao 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 variveis booleanas igual a 1 somente se todas as variveis forem iguais a 1. Caso contrrio, o resultado 0. Esta operao conhecida como produto lgico. O operador OR representado pelo smbolo +, como em A + B. O resultado da aplicao deste operador sobre variveis booleanas igual a 1 se pelo menos uma das variveis for igual a 1. Caso contrrio, o resultado 0. Esta operao 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; 7

Lei do zero e do um: Lei da inverso:

A+1=1 A+=1

e e

A 0 = 0; A = 0; e A B = B A; e A (B C) = (A B) C; A + (B C) = (A + B) (A+ C).

Lei da comutatividade: A + B = B + A Lei da associatividade:

A + (B + C) = (A + B) + C

Lei da distributividade: A (B + C) = (A B) + (A C) e

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 28 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 nmeros 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 representados em complemento a 2. Nesta conveno os nmeros que possuem 0s esquerda so considerados positivos e os nmeros com 1s esquerda so considerados negativos. O complemento a 2 obtido invertendo-se o nmero 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 deslocamento. 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 processamento (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.

O seu principal componente a UC (Unidade de Controle). O processador conta tambm com uma Unidade Lgica e Aritmtica (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 Register), 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. 2. 3. 4. 5. 6. Busca instrues da memria para o registrador de instruo (IR) Atualiza o contador de programa (PC) Determina o tipo de instruo, e (se usar) localiza os dados na memria Busca os dados (se houver) para registradores Executa a instruo, e armazena resultados 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 instrues 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 quantidade de instrues diferentes e complexas. Os programadores executam um nmero menor de instrues do processador, pois cada instruo realiza tarefas mais complexas. Isso reduz o tamanho do cdigo, diminuindo a necessidade 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 organizao 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 necessidade de esperar pelo trmino, e vrias operaes podem ocorrer simultaneamente, atravs de um vetor de interrup9

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 sistemas 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 processamento 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 controle 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 haver 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 interrupo 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. 2. 3. Detectar a fonte da interrupo (o dispositivo que interrompeu) Executar as aes apropriadas (que dependem do dispositivo) 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 invlido, 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.

10

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 gerado 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.

11

Sistemas Operacionais O sistema operacional responsvel por gerenciar todos os recursos de uma mquina, facilitando a inter-face entre o hardware 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 endereo, 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, processador e memria) aos programadores. Uma tarefa do sistema operacional fornecer uma interface amigvel para o programador, 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 proporciona 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 apenas 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 atravs de uma rede para completar uma tarefa. Um sistema distribudo um conjunto de computadores que age como uma mquina 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, leitura 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 interconectar 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.

12

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 utilizadas, 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 podem 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 processos 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 esperando 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 intervalo de tempo, ocorre sua substituio pelo prximo processo na fila de processos ativos, sendo o processo em execuo interrompido 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.

13

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 somado a endereo lgico.

Alocao Contgua Simples A memria principal dividida em duas parties: Sistema Operacional (parte baixa) e Processo do Usurio (restante da memria). O usurio tem controle total da memria, inclusive da rea do SO (Ex.: DOS). A proteo (bits de proteo) foi posteriormente 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 > conjunto de trabalho. Obs.: espao de endereamento virtual > espao de endereamento fsico

14

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 processos. Apenas algumas das pginas virtuais tm um correspondente fsico em cada instante; as demais pginas so marcadas 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 organizar 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 magneticamente 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 mdio de acesso. Os tempos mdios de acesso dos discos atuais so da ordem de 10 ms e resultado das seguintes operaes: 15

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 variar de aproximadamente 0 ms (referente ao acesso a um setor localizado na mesma trilha onde no momento est a cabea de leitura), 3 ms (para acesso a setores em trilhas adjacentes) a at 20 ms (referente ao acesso entre trilhas localizadas nas extremidades do disco). Este tempo diretamente dependente da qualidade dos mecanismos eletromecnicos 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 constantemente 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 cabea. 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, dependendo 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 mdios 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 reconhecido e utilizado pelo sistema operacional, necessria uma nova formatao, chamada de formatao lgica. A formatao 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 diretamente. Cada unidade de alocao possui apenas 512 bytes, evitando o desperdcio de disco. Utilizado pelo Windows 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 simultneos. 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-

16

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 operacional. 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 velocidade 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 processo nunca executar sua rotina. Sincronizao condicional: quando um recurso no est pronto para ser utilizado, o processo que vai acessar o recurso 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 sistema 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 mensagem 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 deadlock, 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 17

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 liberao 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.

18

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 computadores 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 surgiram utilizando esta interconexo. As redes modernas tm razes nos primeiros sistemas de telefones e telgrafos. Para lidar com o aumento no nmero de usurios, foi preciso criar novos meios de distribuir o processamento e utilizao dos outros recursos pelas redes, criando o conceito de multi-processamento e sistemas de processamento distribudos. Na dcada de 60, o governo dos EUA iniciou o projeto 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 baixo 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 volume 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 representou 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 sofisticados 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 comunicao, 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 alternadamente, 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 comunicao (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 sinal de temporizao (clock). O receptor, conhecendo os intervalos de tempo permitindo delimitar um bit, poder identificar a seqncia dos bits fazendo uma amostragem do sinal recebido 19

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 cobre, fibra ptica, wireless, etc) e mostra a configurao geral da rede atravs da planta de localizao dos equipamentos.

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 transmitida. Alguns protocolos, por exemplo, levam em conta a distncia mxima entre os ns da rede para seu perfeito funcionamento. Ao lado esto relacionadas as topologias 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 Topologia Estrela

Ponto Positivos

Pontos Negativos

Topologia Anel (Token Ring) Topologia Barra-

mais tolerante a falhas Fcil de instalar usurios Monitoramento centralizado Razoavelmente fcil de instalar Requer menos cabos Desempenho uniforme Simples e fcil de instalar Requer menos cabos

Custo de Instalao maior porque recebe mais cabos Se uma estao para todas param Os problemas so difceis de isolar. A rede fica mais lenta em perodos de uso intenso.

20

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 encaminhada 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 confirmao 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. 2. 3. 4. 5. 6. 7. 8. Voc disca o nmero do telefone de outra pessoa (CONNECT.request) O telefone da outra pessoa toca (CONNECT.indication) Ela atende dizendo al (CONNECT.response) Voc ouve o al da outra pessoa (CONNECT.confirm) Voc solicita uma informao( DATA.request) A pessoa ouve a solicitao (DATA.indication) Ela informa o que voc solicitou (DATA.request) Voc ouve a informao (DATA.indication) 21

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 numerao 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 compartilhar 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 perifricos. Atuam como guardas de trfego de dados, evitando colises e congestionamentos. Estes dispositivos permitem 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 multiplexadores inteligentes, possuem processador e um buffer onde armazenam os dados oriundos dos terminais

22

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 "linha comutada dedicada" a cada uma das suas conexes. Um hub que dispe 10 Mbps, compartilha esta velocidade 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 o o o o ler o endereo do pacote e retransmit-lo; filtrar as mensagens, de modo que pacotes com erros no seja retransmitidos; armazenam os pacotes quando o trfego for muito grande; memorizar os endereos lgicos dos dispositivos, e gerar lista dos dispositivos ligados a cada porta; 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 rotas 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 diferentes. Na comunicao entre arquiteturas diferentes surgem diversos problemas, como por exemplo: o o o o tamanho mximo de pacotes; forma de endereamento; tcnicas de roteamento; 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. 23

A segurana lgica requer um estudo maior, pois envolve investimento em softwares de segurana ou elaborao dos mesmos. Deve-se estar atento aos problemas causados por vrus, acesso de invasores de rede, programas de backup desatualizados (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 contedo 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 (representados por bits) entre dois equipamentos terminais, via um suporte de transmisso. Alguns protocolos padres so: IEEE 24

802, ISO 2110, etc. O Ethernet um dos padres mais populares para a conexo fsica de uma LAN. Utiliza um procedimento de compartilhamento de cabos denominado de CSMA/CD e trata das colises de dados que podem ocorrer quando diferentes 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 conjunto 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 transmisso 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 camada 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 momento de cada dilogo em funo das condies de trfego, devendo ainda efetuar a gesto dos problemas de congestionamento 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 componentes so o Roteador, o ATM Switch, Switch nvel 3, entre outros. 25

Camada de Transporte Esta camada cria normalmente uma conexo de rede para cada conexo de transporte requerida pela camada de sesso, e determina 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 conexo. Ela tambm permite um "isolamento" em relao s camadas superiores, pois o ltimo dos nveis que seriam mais orientados 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 (probabilidade 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 terminais, 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 problema 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 tpico 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 significado da informao para reduzir a quantidade de informao enviada, inclusive para implementar funes de confidencialidade 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 interagir, foi o pioneiro no desenvolvimento de protocolos de software para redes, que poderiam funcionar em mais de uma mar26

ca e modelo de computador. O principal conjunto estabelecido pelo DoD o Transmission Control Protocol/Internet Protocol (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-afim 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 destinatrio, 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 globais 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 descem 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 dados.

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 mesma 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 encapsulamento 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 sobre a rede, e o ARP (Address Resolution Protocol) para resoluo de endereos IP.

27

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 orientado 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 Destino). O protocolo TCP oferece as seguintes caractersticas: 28 Controle de Fluxo e Erro fim-a-fim (a comunicao full-duplex fim-a-fim).

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).

29

Classe B: como exemplo, o endereo 128.126.12.34 pertence classe B. So possveis 16.384 redes (os dois primeiros 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

30

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 procedimento 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 incorporado 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 inexistente no sistema (todas as bibliotecas devem ser copiadas junto com o executvel).

31

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 oposio 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 (fornecido 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 encontrar 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 centralizandoas em um determinado ponto, chamado Servidor de Aplicaes. O acesso ao banco de dados feito atravs das regras contidas no Servidor de Aplicao. Apresentao: Esta camada fica no cliente, fornecendo a interface visual da aplicao. Alteraes ela so mais raras, 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 navegador (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 memria, 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 chamadas de procedimentos.

32

A chamada remota segue o modelo da chamada local, sendo que o procedimento chamado executado em um processo diferente, 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 Domain. 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 enviar 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 33

Gateway entra em cena aqui, porque quando se emite um pacote IP que no pertence a rede local algum tem que tomar providencia 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 roteador 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 mesmo um s. Um deles, pelo menos, mantido pelo Estado. Mas existem tambm backbones em empresas particulares. O primeiro backbone da Internet criado no Brasil foi a RNP (Rede Nacional de Pesquisa), comeou atendendo entidades, faculdades 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 conectar 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.

34

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 descentralizao 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 corporativa 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 software. 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 mensagens 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 computadores 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 lados por meio da avaliao do nmero da sesso TCP dos pacotes. Este tipo de firewall mais complexo, porm muito 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 informaes 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 controle sobre as aes realizadas na rede, sendo possvel at mesmo descobrir quais usurios as efetuaram.

35

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 especialista em tcnicas de modelagem de dados para sistemas OLTP (On-Line Transactional Processing) e sistemas OLAP (OnLine 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. Algumas 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 corporao, 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 apresentao 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. Esmiuando este conceito, um Administrador de Banco de Dados tem as seguintes responsabilidades: 36 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

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 futuros 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 o o Compilador e pr-compilador da Linguagem de Modelagem de Dados Interpretador da Linguagem de Definio de Dados Motor de Avaliao de consultas.

Gerenciador de armazenamento: o o o o Gerenciador de Integridade e Autorizao Gerenciador de Transaes Gerenciador de Arquivos Gerenciador de Buffer

Estruturas de Dados da Implementao do sistema fsico: o o o o Arquivos de Dados Dicionrios de Dados ndices Dados estatsticos

37

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 interao 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 comandos de uma DDL um conjunto de tabelas que so armazenadas em um arquivo chamado dicionrio de dados. Este dicionrio 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 aplicao especfica da empresa, podendo existir vrias vises externas. Modelo interno: definido pelo Administrador de Banco de Dados. Se preocupa com a implementao fsica dos dados 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 denominadas 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.

38

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 o o um para um: significa que h uma de cada coisa no relacionamento. um para muitos: uma linha em uma tabela vinculada a muitas linhas na outra tabela. 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 integrante 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 conhecimento 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 representados por elipses duplas. 39

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 exemplo, 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 relacionamentos, 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 gerenciador 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 atravs 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 caracterstica. 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 deseja ser, um sistema gerenciador de banco de dados relacionam deve ser capaz de gerenciar, por completo, bases de dados atravs 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 independente 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 representada 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 recuperao de informaes. Entretanto, deve haver pelo menos uma linguagem, com uma sintaxe bem definida e ex-

40

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, autorizaes 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 aplicaes. Regra 10 Independncia de Integridade: As aplicaes no so afetadas quando ocorrem mudanas nas restries de integridade. Regra 11 Independncia de Distribuio: As aplicaes no so logicamente afetadas quando ocorrem mudanas geogrficas dos dados. Devem permanecer inalterados quando so distribudos em meios ou mquinas diferentes. Regra 12 No Subverso: Se um sistema possui uma linguagem de baixo nvel, essa linguagem no pode ser usada 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 chaves 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 entrada 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 fornecedores 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. 41

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 valor 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 dependente 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 00001

cdigo-curso ENG01

descrio-curso ENG. CIVIL

avaliao A

data-concluso 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, assumem apenas um nico valor. Elimine atributos multivalorados criando tantos conjuntos de entidades quantos forem os atributos multivalorados

A tabela ao lado anteriormente possua valores multivalorados para Cdigo-Pea (P1,P2,P3,P4,P5) e Quantidade (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 desejvel.

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

42

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 relaciona 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 tabelas 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 assim, ela de responsabilidade do programador que codifica a transao. Ela s executa se o estado do Banco de Dados permanecer consistente aps seu fim. Isolamento: Sua necessidade surge em execues concorrentes, as diversas transaes que ocorrem simultaneamente, 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 43

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 contagem 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 o Bloqueio Compartilhado (Shared): permite que outras transaes leiam o item 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.

44

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 referencial, 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 segurana, 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. Diferente de tabelas normais em um banco de dados relacional, uma view no faz parte do esquema fsico, mas sim uma tabela dinmica 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, utilizado 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 associado 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, criando 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 determinada 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 dados. Um BDD pode ser entendido como uma coleo de mltiplos bancos de dados, logicamente inter-relacionados, distribudos 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.

45

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 centralizados 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 operando. Em particular, se itens de dados so duplicados em diversos ns, uma transao que necessita de um item de dado particular 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 processamento, 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 quando 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 arquitetura completamente replicada, que possui alta disponibilidade e capacidade de recuperao. O desempenho das consultas aumenta, 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++.

46

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 considervel 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 semntica 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;

47

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 localidades 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 state

(SELECT cnt_code, st_code FROM 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 48

49

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 analisados 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), onde 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 chance de erros humanos diminuiu, porm o processo todo consumia bastante tempo, alm de no suportar relatrios customizveis 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 criarem seus prprios relatrios, embora ainda no fossem amigveis. O usurio precisaria conhecer as estruturas de dados armazenadas nos bancos, s vezes gerando queries de baixa performance (com vrios joins), pois esses bancos no foram projetados 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 mercadolgica 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 diferentes, 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 evidncias. 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.

50

Ferramentas de BI sempre existiram e fizeram parte de um projeto de DW. Veremos que a maioria das solues de BI apresentadas 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 histrico 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 desempenho, como um pacote CRM (Customer Relationship Management), por exemplo, necessria a implementao 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, comunicao, 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 dados, 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 negcio, 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 (hardware, rede, etc.) e pelo gerenciamento dos servios que contribuem para manter o data warehouse atualizado e consistente. 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 importantes 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 sistema 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 relatrio financeiro para um cliente, precisaramos acessar cada sistema OLTP separadamente. Porm, um data warehouse 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 especiais), cada sistema identifica um produto de forma diferente (letras, nmeros). Para que a informao sobre os produtos seja carregada pelos trs sistemas de forma significativa, eles devem ser convertidos para um cdigo em comum. 51

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 cadeia 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 menores 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 empresa avaliar a sua demanda e optar pela melhor soluo. Como um data mart possui uma quantidade significativamente menor 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 escolha 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)

52

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 cidade, 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? Resposta: 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 requisitos com mais detalhes, podemos ver que ser necessria uma anlise de PERODO DE FRIAS. Este tipo de anlise 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 efetiva, 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 suas necessidades de cruzar as informaes de uma forma no vista e com mtodos que o levem aquilo que procura. 53

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 multidimensional (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 microcubo 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, alm do servidor de banco de dados no ficar sobrecarregado, sem incorrer em problemas de escalabilidade. A desvantagem 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 causando, 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 combinao 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 dimensional. A capacidade de poder observar um banco de dados no formato de um cubo, contendo duas, trs, ou mais dimenses, 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 definido 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): 54

Dimenses: Representam as possveis formas de visualizar os dados. So as entradas para as consultas (tempo, regio, cliente, etc). So os atributos e hierarquias das dimenses que permitem realizar as operaes descritas anteriormente, 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, valores,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 comumente utilizada o esquema estrela (star schema), que utiliza a abordagem relacional e os seus componentes, com algumas 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 compreensibilidade 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:

55

Foi identificado o fato ocorrncia. O gro do fato ser o nmero de ocorrncias registradas de uma empresa, em um dia, acompanhada 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 analgica. 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 administrao, e sistemas de autorizao de acesso. Ferramentas de controle de verses (Chekin-Chekout), busca e navegao, colaborao e workflow esto includas nessa categoria.

56

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 dados, 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 engenharia, 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 desempenho. 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 explorao. 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 importncia e utilidade. Essa tcnica, orientada a minerao de dados, oferece uma poderosa alternativa para as empresas descobrirem 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 problema, 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 usurio, 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 empresas, ajudando as mesmas a conseguirem serem mais competitivas e maximizarem seus lucros.

57

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 desenvolvedores 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 informaes 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 gerenciamento 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 Relacionamento (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 sadas. 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 conectados (de uma maneira no direcional), como redes eltricas analgicas. Redes lgicas (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, indicando a direo do fluxo de dados por setas. No modelo baseado em variveis, o foco dado s variveis afetadas pelas funes. 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 definies 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] 58

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 tarefa tediosa, mas necessria para a preciso e organizao sistemtica dos termos. = + () {} [] ** @ | composto de e opcional (pode estar presente ou ausente) iterao seleciona alguma das vrias alternativas comentrio identificador (campo chave) separa alternativas na construo [ ] 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|'|-| | ] 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 composio 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*

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):

59

 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 quando uma entrada ou sada de um processo for a combinao 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 projeto), e o ltimo possui de informaes da implementao 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 subdivises. 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 paralelas ou elipses, e so os dados armazenados (repouso), internos ao sistema. Os retngulos so os terminadores, que so as entidades externas com as quais o sistema se comunica, pode ser uma pessoa ou sistema. Ao elaborar um DFD, deve-se evitar processos (crculos) com entradas mas sem sadas, e tambm dar nomes significativos aos seus componentes. No ligue setas entre processos! Outros nveis podem ser criados para especificar mais o sistema (subdividir em detalhes). Lembre de Numerar 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 especificao, 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. 60

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 implementao 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 processo 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 importantes tendem a ser globais a todo o sistema, o que coloca problemas significativos fase de manuteno, quando as representaes 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 encapsulamento 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 propagao 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 nica, 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). 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, Diagrama 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. 61

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 Essencial 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 narrativa 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 concluso 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 computadores). 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 provavelmente 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 aplicam-se a todas as ocorrncias do objeto. Operaes Comuns: um conjunto de operaes pode ser definido para o objeto em potencial, e essas operaes aplicam-se a todas as ocorrncias do objeto. Requisitos Essenciais: entidades externas que aparecem no espao problema e produzem ou consomem informaes 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 comportamento 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 transformaes. 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). 62

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, atravs 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 orientados 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 necessariamente 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 descreve uma caracterstica, e o diagrama com todos os casos de uso deve representar todas as situaes possveis de utilizao do sistema. Normalmente os diagramas so acompanhados por uma descrio de cada caso de uso narrativas de texto do caso de uso em que devem ser ressaltados vrios atributos (como nome, atores relacionados, objetivo, 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 Componente_Plstico so tipos de Produto e herdam os atributos e mtodos de tal classe.

63

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 desenvolvimento orientado a objeto pe muita nfase na diferena entre interface e implementao, mas isto freqentemente negligenciado na prtica porque a noo de classe em uma linguagem OO combina interface com implementao, 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 perspectiva 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. 2. 3. 4. 5. 6. 7. 8.

Identificar as classes; Identificar os atributos das classes (sem levar em considerao suas visibilidades ou tipos); Analisar os atributos das classes, identificando que alguns deles so na realidade relacionamentos; Identificar os mtodos; Identificar os relacionamentos entre os objetos; Definir a herana; Definir as colaboraes; 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).

64

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 destruio 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 composto morrer, as partes morrem tambm (definio da composio), ou quando um carro se mover, as partes se movem tambm. 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: losango 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) podem 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 aspectos 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.

65

Diagrama de atividades Representa o conjunto de passos a serem executados por um mtodo, mostrando como uma operao pode(ria) ser implementada. 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 similar 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 acrescentar nmeros de seqncia s mensagens para indicar a ordem de chamada. Outra diferena que esse diagrama NO mostra explicitamente o retorno das chamadas.

66

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).

67

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, incluindo 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 comportamento 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 conjunto 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 distribuio das classes por trs camadas. A primeira camada identificada como camada de apresentao abrange as classes que so responsveis pela interao 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.

68

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 desenvolvimento a uma aplicao, permitindo a comunicao do seu problema, estratgias e boas prticas de programao, alm da soluo para o problema proposto. Estas solues foram experimentadas por vrios desenvolvedores experientes, e por isso podem ser reusadas de forma confivel. 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 dependncia 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 como 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 mensagens. 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 agregados 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 granularidade. 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 encapsulamento. 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 objeto. Strategy: Define uma famlia de algoritmos, encapsula cada um deles, e torna a escolha de qual usar flexvel. O Strategy desacopla os algoritmos dos clientes que os usa. 69

Template Method: Define o esqueleto de um algoritmo em uma operao. O Template Method permite que subclasses componham 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 dirigidos sintaxe (inclusive grficos), mecanismos de validao, entre outros. Este tipo de ambiente de desenvolvimento de software recebe a denominao genrica CASE (Computer-Aided Software Engineering), 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 automatizada. Em alguns casos, implementam um ambiente relativamente refinado no qual vrias atividades de especificao ou codificao so apoiadas por recursos computacionais. Dependendo da atividade suportada podem ser classificados em Lower CASE, provendo suporte codificao, teste, depurao 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 ferramentas 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

70

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 tratamento 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 respectivas 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 procedimentais 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 (tecnologia, 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. 71

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 completa 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 requisitos definidos em uma representao de software com detalhes suficientes para que possa ser implementado. Como os requisitos, 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, sistematicamente, 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 necessrio que estes sejam planejados com seus objetivos claramente definidos. Na anlise dos resultados deve-se procurar identificar 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 tcnicas 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. 72 A atividade de teste no prova a ausncia de erros, apenas a existncia dos mesmos;

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 encontrados 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 parece 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 produto, 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 manuteno 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 possvel 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 Anlise qualidade e gerncia do projeto.

Projeto
Modelo Clssico ou Cascata A primeira proposta deu origem ao modelo tradicional ou cascata. Nesse modelo as fases so executadas sistematicamente em seqncia.

Construo Avaliao Manuteno

73

O sistema entregue ao usurio aps se chegar a um resultado satisfatrio na fase de avaliao, com um certo grau de confiana. claro que o sistema ainda passar por alteraes, devido principalmente a erros observados pelo usurio, ou por mudanas 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, Projeto, Construo ou Avaliao. Assim sendo, a reutilizao utiliza: cdigo j testado anteriormente, projetos validados, especificaes 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 prototipagem 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, refletindo os aspectos visveis do software. Este projeto rpido leva construo de um prottipo. Um benefcio que o desenvolvedor do software pode compreender melhor o domnio sobre o qual est trabalhando, a partir das questes levantadas pelo usurio. Alm disso partes 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 desenvolvedor 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 produtividade. Opositores afirmam que as ferramentas no so to mais fceis de usar do que ferramentas mais convencionais e que o 74

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 processo 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 mostrando 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 interfaces. Usando de forma embutida a orientao a objetos, essa tcnica fundamenta-se nos seguintes conceitos: 75

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 codificao 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 unidade 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 bemsucedida 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 execuo 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 desempenha 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 cobertura 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 menos 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 programa que foi determinada pelo projeto. A integrao pode ser incremental (top-down ou bottom-up) ou noincremental.

76

Testes de validao: pode ser considerado bem sucedido quando o software funciona da maneira esperada pelo cliente. 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 conformidade com os requisitos. Testes alfa e beta: so os testes de aceitao, feitos pelo usurio, que dificilmente opera o sistema da forma prevista, 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 customizado, 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 sistema 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 walkthrough 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 matemtica 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 matematicamente que um programa est correto em relao especificao formal. Ex.: {x = 5} x: = x + 1 {x = 6} Especificao: condio final Especificao: condio inicial

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 funcionais do software. Ele procura descobrir funes incorretas ou ausentes, erros de interface ou estruturas de dados, erros de desempenho 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.

77

o o

Para o domnio de dados de entradas vlidas devem ser identificadas parties (classes) para os quais o sistema tenha comportamento semelhante. 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 condies lgicas e das aes correspondentes. A tcnica segue quatro passos: o o o o As causas (condies de entrada) e efeitos (aes) so relacionados para um mdulo e um identificador atribudo a cada um. Em seguida gerado um grafo de causa-efeito. O grafo convertido em uma tabela de deciso. 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 operao tem um desempenho de acordo com as especificaes. Razes para a sua execuo so que erros lgicos e pressuposies 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 exercitarem o conjunto bsico tm a garantia de executar cada instruo do programa pelo menos uma vez durante a atividade 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 seguintes 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 utilizam 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 registrados, at o momento.

78

Requisitos Crosby diz que qualidade a "conformidade com os requisitos", logo v-se a importncia da Engenharia de requisitos. Define-se por requisito uma condio ou capacitao necessria a um componente do sistema (ou o prprio sistema) precisa atender, 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 realizadas 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, segurana, 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.
Sistemas de Informao Existentes Necessidades de Stakeholders Padres Organizacionais

Requisitos Acordados

Processo de Engenharia de Requisitos

Especificao do Sistema

Regulamenta es Domnio da Informao

Modelos do Sistema

Elicitao de requisitos A elicitao de requisitos envolve as atividades de coleta, comunicao e validao de fatos. Esta uma atividade de absoro 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: perguntas iniciais, onde o foco est em definir usurios, objetivos gerais e benefcios; perguntas relacionadas ao problema e percepo do usurio sobre o problema; e meta-perguntas onde o desenvolvedor se certifica do andamento da elicitao de requisitos, se est entrevistando a pessoa certa ou se falta algo.

79

A tcnica FAST (Facilitated Application Specification Techniques) utilizada para que a elicitao de requisitos seja realizada com todos os usurios ou com grupos grandes de usurios, aumentando assim a produtividade da tarefa. O foco desta tcnica 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 desenvolvimento 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 assimilar 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 concludas. Ex: Nmero de usurios que completaram a tarefa corretamente. Eficincia: recursos gastos em relao acurcia e abrangncia com as quais usurios atingem objetivos. Ex: Nmero 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 identificados 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 funes, 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 elementos e que indicam se ele pertence a uma determinada classe ou grupo. Ex: Clara distino visual de reas, campos e legenda que tenham diferentes funes.

80

Feedback: a resposta do sistema para as aes dos usurios. Rapidez e qualidade da resposta so duas caractersticas fundamentais para o feedback. Ex: Toda a entrada de dados deve ser mostrada de forma perceptvel, exceto as relativas 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, tamanho 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, aumentando 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 ocorrerem - 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, personalizao, 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 externas) 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 usurios, 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

81

Atividade 1 Tarefa
processo

Da concepo at a descontinuidade
processo processo

Tarefa

Tarefa

Modularidade e responsabilidade

Ciclo PDCA

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 organizao 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. Nestes 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: gerncia, infra-estrutura, melhoria e treinamento.

Metodologias geis: Extreme Programming Programao extrema (Extreme Programming), ou simplesmente XP, uma metodologia gil para equipes pequenas e mdias 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: feedback 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.

82

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, Codificao 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, sendo 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 acesso 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 para 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 seguir estas regras. Desta forma parece que todos os cdigos fontes foram editados pela mesma pessoa, mesmo a equipe possuindo 10 ou 1000 componentes. Desenvolvimento dirigido por testes: primeiro crie os testes unitrios e depois crie o cdigo para que os testes funcionem. 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. Integrar 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 gerenciamento 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. 83

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 processo 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 justamente 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 prximos 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 plataforma 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, compreendendo 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 sistema, 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 aplicadas 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: 84 Especificao de um sistema independentemente da plataforma que o suporta; Especificao de plataformas;

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 apresentado como uma combinao de desenhos e textos, estes ltimos que podem ser expressos em linguagem natural ou linguagem de modelagem, como UML. Logo a MDA fornece modelos para especificao das vrias partes constituintes de um sistema. 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 abstrao 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 sistema neste processo. Alguns benefcios com a adoo da MDA so: rapidez (menos tempo para que um software seja entregue), minimizao no impacto ocasionado pelas mudanas de requisitos na escala do desenvolvimento, maior reuso de componentes 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 desenvolvimento 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 especfica 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 desenvolvimento 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.

85

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 refletindo as experincias mais recentes comprovando este guia/padro. O RUP uma Abordagem de Desenvolvimento de Software, que iterativa, centrada a arquitetura, e dirigida a casos de uso. A maior parte das informaes sobre essa abordagem pode ser encontrado no prprio Produto, que contm 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 definir 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 processo, 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 infraestruturas 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 modelos visuais tambm pode permitir que indivduos de perfil menos tcnico (como clientes) tenham um melhor entendimento 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.

86

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 equipe 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 imprevisveis, o controle de mudanas essencial para o sucesso de um projeto. O RUP tambm define reas de trabalho 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 casos 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 produtos 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 desenvolvimento 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 diagramas 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.

87

Disciplinas do RUP Uma disciplina uma coleo de atividades relacionadas que fazem parte de um contexto comum em um projeto. As disciplinas 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 modelagem de negcios, requisitos, anlise e projeto, implementao, teste e implantao. As Disciplinas de Suporte so o gerenciamento 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 Pessoas 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. Qualidade 88 Processos Tecnologia

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 framework 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 contratos 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 modelos podem ser em estgio (staged) ou contnuos (continuous).

Gerenciamento de Requisitos Requisitos de Produto e Componentes Alternativas de Soluo Soluo Tcnica Requisitos Relatrio Verificao Componentes Componentes Integrao de Produto Requisitos

Desenvolvimento de Requisitos

Artefatos, Produto

Relatrio Validao

Produto 89

Cliente

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 colocar 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, produo, suporte etc) e usurios (gerncia e pessoal operacional). As negociaes de planejamento so o teste crtico do time gerencial. 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 trabalho 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, normalmente 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. Obviamente, 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 coerentes 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 alterao dos requisitos. A existncia de um procedimento formal tem dois benefcios: garante que os planos sero revistos 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 incluem aqui atividades de gerenciamento de riscos e alocao de recursos.A empresa deve instituir polticas e procedimentos padronizados para o planejamento de projetos, incluindo a necessidade de envolver todas as reas interessadas (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 execuo, que os planos esto sendo cumpridos. O propsito desta KPA dar visibilidade sobre o progresso real do projeto em relao ao planejado, permitindo a tomada de aes corretivas quando a realidade estiver se afastando muito

90

do que foi inicialmente planejado. A organizao deve instituir procedimentos para garantir que o progresso do projeto continuamente comparado com o planejado, em termos de prazos, custos e qualidade. Alm disso, os procedimentos devem estabelecer gatilhos a serem disparados quando houver muita distncia, indicando as aes corretivas 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 previamente acordados. Esta KPA, naturalmente, inclui o acompanhamento dos fatores de risco identificados nas atividades 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 formalmente pelas reas envolvidas, como forma de garantia que o projeto est andando conforme deveria. Quando ocorrem 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. Sabendose 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 gerados pelos terceiros. Garantia de Qualidade de Software: o propsito desta KPA prover visibilidade sobre a qualidade tanto dos processos 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 especialmente 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 processos sem qualidade. No basta descobrir que um programa tem um monte de bugs. necessrio descobrir por qu estes bugs existem. Geralmente, a razo ser algo como o no uso dos padres definidos de programao, documentao de programao insuficiente, comunicao inadequada entre analistas e programadores etc. A empresa deve instituir 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 medidas 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 planos 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 software 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, garantindo que as alteraes estejam sendo corretamente implementadas e relatadas a outras pessoas que possam ter interesse. Procedimentos de Controle de Mudanas so estabelecidos, garantindo que alteraes em produtos (documentos, dados de teste, programas) so feitas de forma consistente e sob o conhecimento e aprovao de todos os envolvidos. 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 configurao. 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

91

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 produto 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 satisfaz 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) 92

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 requisitos para o produto, bem como comunicao dos resultados. Ao ("Act"): tomada de aes a fim de melhorar continuamente o desempenho dos processos.

93

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

94

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 sistemas de informao sejam projetados para suportar e atender aos objetivos de negcio. Um negcio pode ser entendido como 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 acordo 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 melhorar essa capacidade, como o Modelo da Organizao (estrutura da organizao), o Modelo de Objetivos (liga os objetivos da empresa com os processos de negcio), o Modelo de Processos (modela a estrutura de processos e atividades) e outros, como o Modelo de Workflow, Modelo de Interao e Modelo de Casos de Uso.

95

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 adicionais. 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 obrigatoriedade 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 software 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 o o Aspectos tanto estruturais quanto de negcio (como a organizao, hierarquia de objetivos, ou recursos). Aspectos comportamentais do negcio (como os processos). 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

96

Atividades

97

Gerncia de Projetos
Gerncia de Projetos (ou Gesto de Projetos) a aplicao de conhecimentos, habilidades e tcnicas na elaborao de atividades 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 baixo 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 cronogramas 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 aceitao 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 corretivas 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, padronizando 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: 98

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 o o Desenvolvimento do plano do plano do projeto Execuo do plano do projeto Controle integrado de alteraes

Gerncia de Escopo: Envolve os processos necessrios para assegurar que o projeto contm todo o trabalho necessrio para completar o projeto com sucesso. O seu foco principal na definio e controle do que est ou no considerado no projeto. O escopo do projeto difere-se do escopo do produto na medida em que o escopo do projeto define 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 o o o Iniciao Definio do escopo Verificao de escopo Controle de alteraes de escopo

Gerncia de Tempo: Envolve os processos requeridos para garantir o trmino do projeto no tempo certo. Os processos 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 o o o o Definio de atividades Sequenciamento de atividades Estimativa de durao das atividades Desenvolvimento de cronograma Controle de cronograma

Gerncia de Custo: Envolve os processos requeridos para garantir o trmino do projeto dentro do oramento aprovado. Inclui o planejamento de recursos, estimativas e controle do budget. Na apurao de custos de software, o modelo de custos uma frmula, ou uma srie de frmulas, usada para prever os custos que provavelmente recairo sobre o projeto. o o o o Planejamento de recursos Estimativa de custos Oramento de custos Controle de custos

Gerncia da Qualidade: Envolve os processos requeridos para assegurar que o projeto ir satisfazer as necessidades 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 o o Planejamento de qualidade Garantia de qualidade 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 o o Planejamento organizacional Aquisio de equipe (staff) Desenvolvimento de equipe

99

Gerncia de Comunicao: Envolve os processos requeridos para assegurar a gerao, coleo, disseminao, dissertao, 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 afetam o projeto como um todo. o o o o Planejamento de comunicaes Distribuio de informaes Relatrios de desempenho 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 plano de risco inclui as tcnicas para identificar o risco, identificar responsabilidades, estabelecimento dos resultados e relatrios detalhados. o o o o Planejamento do gerenciamento de riscos Identificao de riscos Anlise quantitativa de riscos 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 o o o o Planejamento das aquisies Planejamento das solicitaes Seleo dos fornecedores Administrao do Contrato 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 riscos tecnolgicos quanto de negcio e organizacionais.

Stakeholders Stakeholders so indivduos e organizaes ativamente envolvidos no projeto, cujos interesses so afetados (positiva ou negativamente) 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 financeiros para o projeto). Inclui tambm partes internas e externas, como fundadores, vendedores, fornecedores, agncias governamentais, comunidades afetadas pelo projeto e a sociedade em geral. uma boa prtica identificar cada uma das partes envolvidas no projeto, identificar e gerenciar possveis reas de conflito entre elas. Uma orientao geral resolver as diferenas entre as partes favorecendo o cliente. O projeto deve levar em conta as seguintes questes ambientais ou scio-econmicas: 100 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)

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 marcado 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 especialidade (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 o Fraca: o papel do gerente de projetos mais de um coordenador. Parecido com funcional. 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 tarefas que precisam ser feitas para completar um projeto. Em portugus, s vezes traduzida como Estrutura Analtica do Projeto, 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 Unidos 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 responsabilidades, gerenciar riscos, entre outros. Um exemplo simples de work breakdown structure para pintar um quarto (orientado a atividades) : 101

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 subprojetos). 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 existirem, 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 colocados 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 projeto, mostra sua durao total e interessa principalmente ao usurio ou superiores nos nveis estratgicos ou ttico de decises. 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.

102

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 econmico 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 execuo; 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 como 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 problemas 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 conhecimento de cada pessoa no sentido de identificar as causas ou os fatores responsveis por um dado problema ou situao (efeito). Permite, assim, a organizao das idias e sua visualizao agrupada destacando as reas mais significativas. 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 grfica 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 melhorias 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 obtido o peso e a altura de vrias pessoas, o grfico de correlao poder representar em cada ponto uma pessoa. A caracterstica 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, pode-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.

103

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 avaliar o prprio processo. Mtricas de qualidade: oferecem uma indicao de quo estreitamente o software conforma-se s exigncias implcitas 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 associados 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 projetos de software. Utiliza equaes desenvolvidas por Boehm (BARRY,1981) para prever o nmero de programadores-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 tamanho de projeto de desenvolvimento de software. Ela consiste na contagem da quantidade de nmero de linhas de cdigo 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 desenvolvedor; 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 conhecimento 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 mltiplas 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 tendncias 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 Capability 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

104

e de fcil utilizao mas ainda esta em fase de pesquisas e no existem regras de contagem padronizadas. Tm se estudado 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 expressa 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 usada 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 pontos 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 contagem 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 pela aplicao). Para calcular o tamanho de uma aplicao em Pontos de Funo no Ajustados (PFNA) a NESMA recomenda 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 (produtividade). 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 software, 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.

105

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, suporte 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 coeficientes ab, bb, cb e db so dados na seguinte tabela: Projeto de Software Incio Meio Fim 2.4 3.0 3.6 ab 1.05 1.12 1.20 bb 2.5 2.5 2.5 cb 0.38 0.35 0.32 db

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.

106

Onde E o esforo aplicado em pessoas por ms, LOC o nmero de linhas de cdigo para o projeto e EAF o fator calculado acima. Os coeficientes ai e o bi so dados na prxima tabela. Projeto de Software Incio Meio Fim ai 3.2 3.0 2.8 bi 1.05 1.12 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 avaliao 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 modelos 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 recurso ativo como a CPU, o disco ou a conexo de rede. Os modelos de fila podem prever a latncia, a vazo e a utilizao 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 conteno 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 dispositivo 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 conhecido 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 conhecida de transies entre os estados. Este modelo adequado para prever a disponibilidade de um sistema, dadas as ta107

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 partir 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 disponvel ou quando existe necessidade de variar as caractersticas da carga. A gerao de carga eficiente e no necessita 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 corretamente 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 trivial 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 geradores 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 medem 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 implementados tanto em software quanto em hardware que fornecem informao til de desempenho. Por exemplo, falhas de pgina podem 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).

108

Taxa de servio: que mede quantidade de trabalho realizado por unidade de tempo ou a taxa em que novos resultados 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 Time 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 utilizao 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 manuteno). 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 representao 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.

109

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 marketing 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 objetivo do negcio do cliente. As organizaes buscam na tecnologia da informao meios para ajud-las a se tornar mais eficientes e efetivas no seu negcio. Usurios finais so os consumidores dos servios de TI, que cada vez exigem mais dos servios que utilizam em seu trabalho. 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 modelo 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 (segurana, etc) e o SixSigma oferecem modelos para a funo de controle.

110

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 Management). 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 segurana dentro de seus prprios processos. TI deve ajudar uma organizao em alcanar os seus objetivos estratgicos da maneira mais eficiente possvel. ITIL complementa 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

111

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 indicam 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 assessorar 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 distribuda 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 desempenho dos recursos. Aumentar a capacidade gera custos, mas mant-la abaixo do esperado pelos clientes tambm, 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 prativo e reativo, em alinhamento com os requerimentos de negcios a um custo justificvel. Algumas de suas atividades so: a monitorao, necessidade de manuteno e rastreamento da informao de gerenciamento (produo).

112

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 relacionamento 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 como 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 restaurar 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 gerenciamento 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 conjunto de ferramentas de implementao e um guia com tcnicas de gerenciamento. As prticas de gesto do CobiT so recomendadas 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 negcios. 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 clientes 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 controle 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 o o o o o o o Define o plano estratgico de TI Define a arquitetura da informao Determina a direo tecnolgica Define a organizao de TI e seus relacionamentos Gerencia os investimento de TI Gerencia a comunicao das direes de TI Gerencia os recursos humanos Assegura o alinhamento de TI com os requerimentos externos 113

o o o

Avalia os riscos Gerencia os projetos Gerencia a qualidade

Aquisio e implementao o o o o o o Identifica as solues de automao Adquire e mantm os softwares Adquire e mantm a infra-estrutura tecnolgica Desenvolve e mantm os procedimentos Instala e certifica softwares Gerencia as mudanas

Entrega e suporte o o o o o o o o o o o o o Define e mantm os acordos de nveis de servios (SLA) Gerencia os servios de terceiros Gerencia a performance e capacidade do ambiente Assegura a continuidade dos servios Assegura a segurana dos servios Identifica e aloca custos Treina os usurios Assiste e aconselha os usurios Gerencia a configurao Gerencia os problemas e incidentes Gerencia os dados Gerencia a infra-estrutura Gerencia as operaes

Monitorao o o o o o Monitora os processos Analisa a adequao dos controles internos Prove auditorias independentes Prove segurana independente 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 recomendaes 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: 114

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 estratgico, tcnico, organizacional e de processo. Os indicadores de objetivos definem como sero mensurados os progressos das aes para atingir os objetivos da organizao, 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 permitem atingir os objetivos planejados; so os indicadores que definem se os objetivos sero atingidos ou no; so os indicadores 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 recuperar 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. Capturar, 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 implementa 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 formatos de imagens, textos, documentos compostos, arquivos eletrnicos, udio digital, vdeos etc. 115

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 frases 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 formato 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. Devido 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 digitais. 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 assinatura, 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 informao entre todas as reas de uma companhia. uma plataforma de software desenvolvida para integrar os diversos departamentos 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: 116 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.

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 funcionando 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 Documentos, 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 Management integrados ao ERP, e via web, a soluo para aumentar a eficincia e produtividade na gesto do seu negcio, gerando 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 potenciais de uma empresa. Envolve captar todos os seus dados, consolid-los em um banco de dados, analis-los para identificar 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, televendas, 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 workflow 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 canais 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 importante 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 estratgico e ttico, o CRM colaborativo procura gerar melhorias nos trs nveis. A principal caracterstica deste dessa abordagem est na possibilidade de criar, aumentar e gerenciar a interao com o cliente. Para isso necessrio que a 117

empresa possua um meio adequado para a interao - abordada no CRM operacional - e que possua informaes suficientes 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. Garante 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 Management), 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 empresa, 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 recursos computacionais". Dentro do contexto do Workflow, h o WFM (Workflow Management System), que o sistema que define, gerencia e executa workflows atravs da execuo de software cuja ordem de execuo controlada por uma representao computacional da lgica de workflow. O modelo de referncia define que o WFM composto por cinco subsistemas funcionais, exposto na figura.

118

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 proporcionando 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, gerando 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 (anlise, 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 direcionado 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 invocadas. Alm disso, este ncleo mantm a situao dos processos para que enquanto mltiplas instancias dos processos estejam sendo executadas, elas podem ser monitoradas e administradas. Anlises posteriores dos processos tambm so permitidas j que estas informaes podem ser armazenadas.

119

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 especialistas 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, Emarketplace 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 diversas 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: Compras 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, geralmente na Internet. E-business consiste na utilizao da Web para ajudar as empresas a simplificarem os seus processos, aumentarem a sua produtividade e melhorar a sua eficincia. Permite que as empresas se comuniquem com facilidade com parceiros, 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.

120

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 NO (Negao) AND (Conjuno) OR (Disjuno) se ... ento se e somente se

Smbolo

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 permanecer vivel, medida que o tempo passa, quando a quantidade de dados envolvida normalmente cresce. Os parmetros de complexidade estudados normalmente so os seguintes: 121

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 avaliar um algoritmo. Complexidade de caso mdio: caracterizao do tempo de execuo mdio do algoritmo, para determinado tamanho 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 entrada, 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 superior para esse tempo, o mais prximo possvel da realidade. Para tanto, fixa-se o estudo na instruo mais executada do algoritmo 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 caracter (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 caracteres (Strings), classificados como homogneos, e registros e unies, classificados como heterogneos, pois agrupam 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 determinadas 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).

122

Uma pilha pode ser implementada por um vetor, onde o incio da pilha o primeiro elemento do vetor, e o topo a quantidade 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 unidade. 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 unidade. Caso a pilha esteja vazia, um erro de underflow ocorre. Esta operao retorna o elemento da pilha, e no recebe 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 estrutura. 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 referenciar 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 utilizam tcnicas de paginao de memria (ser visto com mais detalhes no captulo de Sistemas Operacionais) que so beneficiadas 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 superior 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.

123

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 hierarquizadas, 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 constituem 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 rvores 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 rvore 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, principalmente se no for uma rvore completa. Em compensao, operaes de deleo so complexas, pois deve-se manter a estrutura da rvore. A complexidade de busca e insero de O(log2n). O nmero de ns de uma rvore deste tipo varia entre log2n + 1 e n, dependendo do seu balanceamento. Alguns exemplos de rvores ABB so as rvores 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 binrias. So elas:

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

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

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

124

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 menor, 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 menos 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 subvetores, 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(n2) 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 elemento inserido pode ter que deslocar para a direita elementos maiores. A complexidade O(n2), 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 recomear N vezes (onde N o tamanho do vetor), para garantir que todos elementos foram ordenados em suas posies. A complexidade O(n2). 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.

125

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, conseqentemente, 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 entrada do vetor), e Endereamento Aberto (onde no se utilizam links, mas os sinnimos so colocados na primeira posio disponvel 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 diferentes... e se algumas filiais tivessem o mesmo problema? 3) Dificuldade de reaproveitamento de cdigo. Se outro programa quisesse utilizar a mesma estrutura haveria copypaste 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. Espera-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 facilitar modificaes futuras.

126

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 chama-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 localizao de memria). Qualquer alterao no contedo apontado pelo ponteiro ser uma alterao no contedo da varivel 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++ passado 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 ambigidades 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 aumenta 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: tipagem 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 desenvolvidos, minimizando erros em tempo de execuo. Tipagem fraca: neste caso, o compilador no existe essa garantia durante a verificao de tipos, sendo responsabilidade 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 (object-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 construo 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 facilitam 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 irrelevantes. uma tcnica importante para lidar com a complexidade de sistemas. 127

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 Derivadas. 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 container um servlet tem acesso a dados de formulrios e tem o compromisso de produzir um cdigo HTML que ser devolvido ao cliente. Enterprise JavaBeans: um objeto que colocado em container adequado pode ser chamado e chamar objetos remotamente de forma (quase) transparente. Java Message Service (JMS): um conjunto de APIs que permite acessar de forma padronizada servios de mensagens. Dispe de mecanismos para criar, enviar, receber e ler mensagens. Java Naming and Directory Interface (JNDI): o elemento utilizado para cadastramento de responsveis por servios Java, e isso lhe d a capacidade de responder a perguntas de clientes por esses servios. Uma analogia o mapeamento 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 distribudas 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.

128

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 apresentar 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 consistente. O Application Server um programa que implementa essa J2EE. A Sun possui um programa de certificao para demais 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 ambiente). Quando se executa uma aplicao na linha de comando, o container se liga apenas ao sistema operacional nativo (Application 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 ambiente. 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, responsveis 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 navegador (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 oferece 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.

129

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 informaes 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 negcio. 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 cdigo 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 servios, 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: 130 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

Facilita a distribuio da aplicao Permite maior flexibilidade atravs de mdulos "plugveis". Distribui as responsabilidades da aplicao de forma consistente

131

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 <html> e terminada pela tag </html>. Note que as tags podem ser escritas tanto em minsculas quanto em maisculas. O fechamento 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>

132

CSS Tags HTML foram projetadas originalmente para definir o contedo de um documento. Elas devem indicar "Isto um header", "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 contedo 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" 133

O JavaScript permite que o programador escreva linhas dentro de uma pgina (documento), atravs do mtodo write. As linhas 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 linhas 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)

134

{ 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, autodescritivos, que operam na rede. Eles facilitam a interao entre companhias atravs da simplificao das regras de comunicao, 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 assncrona 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 satisfaam os seus clientes de forma mais rpida, alm de reduzir custos (para todos os trs: empresa, fornecedores e clientes). 135

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 podem 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 centralizado com as descries dos web services. Define tambm a API para registrar e buscar os servios. Service Requestor: o cliente em potencial do servio, que disponibilizado pelo broker. Quando o requestor 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 o o Multicast: o remetente pode fazer um broadcast da mensagem SOAP para mltiplos destinatrios. Workflow: a mensagem SOAP pode ser enviada para vrios endpoints antes de retornar ao remetente. 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 capacidades 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 o o White pages: permite o registro de informaes como o prprio servio, IDS, contrato e dados relacionados. Yellow pages: permite organizar o servio pela indstria, geografia ou tipo de servio. (Pginas Amarelas). 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 136

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, colaborao 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 Intranets, 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 empresa, o bem mais precioso de nossos dias: o tempo. Quanto tempo seu pessoal desperdia todos os dias procurando por informaes que deveriam estar publicadas na Intranet? Quanto tempo as pessoas desperdiam delas prprias e de outros funcionrios, 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 iniciativas 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 conference, instant messaging e muito mais, se transformando tambm em uma poderosa vitrine de acesso ao conhecimento. 137

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 navegao, cabealho, rodap entre outros. Estes elementos podem ser armazenados em um ou mais templates, os quais sero 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 relacionadas. 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 servidores web podem ser dinamicamente adicionados ou removidos, dependendo da demanda e das exigncias de acesso. Escalando para mltiplos servidores, tambm aumenta a robustez e a disponibilidade da soluo, dando suporte tolerncia de falhas de hardware. Integrao Total com Aplicaes: os frameworks fornecem uma camada de apresentao comum para todo o portal. As informaes provenientes dos aplicativos so disponibilizadas para o portal atravs de subsees de uma pgina, que recebem diferentes nomes nos diferentes produtos: interfaces, portlets, gadgets e webparts so alguns exemplos. Adotaremos "interface". Uma pgina do portal pode conter uma ou mais interfaces, que podem pertencer 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. Tecnologias como CSS, XML e XSL so utilizadas pelo framework para controlar e manter a consistncia visual das informaes 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 geralmente 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 segurana 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 centraliza 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, gerenciamento 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 empresa. Iniciativas mais amplas de portal podem estender suas funcionalidades a parceiros, fornecedores, clientes, distribuidores, acionistas e outros interessados. Os portais corporativos parecem responder positivamente s necessidades competitivas das companhias, valorizando simultaneamente 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.

138

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 integrados profundamente com aplicaes eletrnicas de workflow e outras ferramentas de colaborao e gerenciamento de projeto. 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 fornecem a infra-estrutura tcnica e os processos centrais que garantem que o contedo correto, atualizado e pontual estar disponvel para aqueles que precisarem. Embora engenhosa, em um nvel conceitual, as plataformas SGC podem ser bastante diferentes em termos de suas vrias caractersticas tcnicas. Algumas das caractersticas encontradas nas solues SGC mais avanadas esto includas, mas no limitadas, na seguinte lista: Funcionalidades de Criao e Design o o o o o o o o o o o o o o Existem poucas limitaes de layout e projeto; O contedo separado do formato; Incluso de ferramentas grficas e intuitivas para se construir um workflow; Permite-se que os usurios no apenas publiquem informao / contedo, mas tambm customizem facilmente a interface de suas publicaes; Facilidade para os usurios no-tcnicos trabalharem com seus aplicativos de escritrio (desktop); Os templates so modificados facilmente; Metadata incluida automaticamente; Permite-se a criao de documentos baseados em XML por usurios que desconheam XML; Facilidade para o usurio organizar, classificar e fazer referncias cruzadas do contedo publicado; Permisso para o usurio associar facilmente termos de busca (palavraschave) com o contedo criado; Suporte publicao de contedo em muitos tipos de arquivos (ex.: udio, vdeo, imagem, apresentao, cdigo HTML, componentes Java, arquivos ZIP para download, etc.); Permisso para os criadores de contedo inclurem nveis de prioridade no documento que ser publicado ou distribudo para grupos selecionados; Habilidade para customizar dinamicamente a navegao, o contedo e aplicativos que sero mostrados a diferentes grupos de usurios; Usurios podem utilizar as ferramentas para criao de contedo que lhes sejam mais adequadas.

Definio de Regras o o o o Permite-se mudanas fceis de regras para autoria, edio, aprovao, publicao e remoo de contedo; Os usurios comuns podem tambm definir ou mudar facilmente as regras e fluxo do processo de publicao das pginas; Os empregados e/ou o webmaster podem gerenciar facilmente papis e direitos de acesso; Permite-se a publicao pblica e com controle de privacidade (isto , os usurios controlam quem tm acesso s suas pginas publicadas).

Administrao e Controle de Verses 139

o o o o o o o o o

Muitas opes para controle de verso; Permite-se visualizar o histrico de mudanas de algum item especfico que tenha sido publicado; 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.); Permite-se que papis sejam facilmente designados: quem pode ler, editar, arquivar e eliminar um documento ou pgina; Permite-se a adio de comentrios para documentos revisados; Permite-se voltar atrs na publicao de itens caso necessrio; So fornecidos relatrios e ferramentas para monitorar facilmente o sistema; Inclui alertas via e-mail para os administradores; Arquivos totalmente passveis de auditoria so fornecidos.

Arquitetura o o o o o o o o Inclui servidores separados para desenvolvimento, teste e produo? Inclui um repositrio global e robusto? O sistema permite a criao de repositrios agrupados? Qual o nvel de granularidade que o contedo pode ser armazenado no repositrio? Esses nveis so facilmente configurados pelo usurio? So facilmente remontadas e disponibilizadas novamente? O sistema produz solues em termos de redundncia no caso de perda total ou parcial dos repositrios? O sistema simplifica a reclassificao e recombinao de contedo para novos usurios e para a entrega atravs de mltiplos canais ? Quais so as habilidades de integrao do sistema? E as ferramentas de desenvolvimento e aplicaes? baseado em XML? Suporta LDAP? Quais outros padres so suportados? 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? Ele suporta a integrao de fornecedores e parceiros em um Processo de Gerenciamento de Contedo necessrio para disponibilizar transaes de comrcio eletrnico em tempo real? O sistema inclui caching? O sistema inclui procedimentos simples para backup?

o o o

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, conhecimento e poder. Por isso, novas polticas de compartilhamento de informao interna e externa (com clientes) e descries de cargo (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 requisies e gerar contedo dinmico.

140

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 contedo 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 necessidade 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 portlets, 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 portlers. 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 produceroffered 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 WSRPcompliant producer. The WSRP Specification requires that every producer implement two required interfaces, while allowing them to optionally 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 interface 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 submits 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 interfaces. 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 mechanism 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.

141

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 oferecer 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 interpretao 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 reconhecimento 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 mensagem 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". 142

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 natureza 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 devem 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 o o o rea da Percepo: trata de benefcios relacionados apresentao do contedo, da informao. Ela preocupa-se com a percepo de elementos como grficos, sons, imagens, multimdia e equivalentes. rea da Operao: preocupa-se com a manipulao da informao, do contedo. Deve garantir formas alternativas ao acesso s informaes atravs de maneiras diferenciadas de navegao ou tcnica similar. rea do Entendimento: trata de questes relacionadas compreenso do contedo publicado. Ela deve garantir que todo o contedo apresentado seja de fcil compreenso para qualquer tipo de usurio. 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 governamentais, 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.

143

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 instituies 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 permitida pelo atributo "alt".
<img src="mont_rio.jpg" longdesc="montanhas.htm" alt="Foto de montanhas no Rio de Janeiro.">

144

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".

145

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 automaticamente 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 familiares, 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, garantindo 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 poltica de segurana;

146

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 operaes das entidades. Especificamente, o pessoal envolvido ou que se relaciona com os usurios deve estar informado 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 comensurveis 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 foco 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 baseada 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 sucedidas 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

147

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 respostas 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 podem medir a vulnerabilidade da rede, gerar logs, grficos e planilhas. o o IDS (intrusion detection system): um dos mecanismos utilizados por esses sistemas a deteco por assinatura, em que a assinatura tpica de um trfego malicioso permite identific-lo como um ataque. 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 o Irrefutabilidade: o requisito de segurana que garante a impossibilidade de que uma autoria de documento eletrnico seja negada posteriormente. Tempestividade: a qual nos permite saber com total segurana se determinado documento foi ou no produzido naquela ocasio.

Certificao digital As tcnicas de certificao digital oferecem seis tipos de servios bsicos. Sem estes predicados no possvel realizar o comrcio eletrnico seguro na Internet: 148 Disponibilidade: garante que uma informao estar disponvel para acesso no momento desejado. Integridade: garante que o contedo da mensagem no foi alterado.

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 transformar 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 (28). Quanto maior o tamanho da chave, mais difcil quebr-la, pois estamos aumentando 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 facilmente 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 (256), seu tamanho de chave considerado pequeno, 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, emprega 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 varivel. 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 tamanho 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 chaves 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 precisaramos de algo da ordem de n2 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).

149

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 decifr-la. As mensagens cifradas com uma das chaves do par s podem ser decifradas com a outra chave correspondente. A chave 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 empregada, 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 integridade confivel. A funo Hashing funciona como uma impresso digital de uma mensagem gerando, a partir de uma entrada de tamanho varivel, 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 criptoanlise 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, distribuio 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. Permitem 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 pessoal. Algoritmos suportados: hashing: MD5, SHA-1, CAST-128, IDEA e 3DES, RSA e Diffie-Hellman/DSS.

150

S/MIME: consiste em um esforo de um consrcio de empresas, liderado pela RSADSI e pela Microsoft, para adicionar segurana a mensagens eletrnicas no formato MIME. Apesar do S/MIME e PGP serem ambos padres Internet, 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. Garante 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 chave 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, geralmente 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)

151

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?

152

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.

153