Walter de Tarso
Material de referência
TI – ICMS
Walter de Tarso
Versão 1
2012
Curso de TI
Sumário 1
Gerência de Projetos ....................................................................................................................... 1 1.1
Conceitos básicos ................................................................................................................................. 1
1.2
Processos do PMBOK .......................................................................................................................... 2
1.2.1
2
Áreas de conhecimento do PMBOK ............................................................................................................... 3
1.3
Planejamento e controle de métricas de projeto ............................................................................... 13
1.4
Métodos de gerenciamento do tempo do projeto .............................................................................. 14
1.5
Exercícios ........................................................................................................................................... 14
Gestão de Processos de Negócio (BPM) ....................................................................................... 18 2.1
BPMN - Modelagem de processos ..................................................................................................... 18
2.1.1
2.2
Elementos ................................................................................................................................................... 18
Técnicas de análise de processos ....................................................................................................... 20
2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8
2.3
3
Automação de processos .............................................................................................................................. 20 Fluxograma ................................................................................................................................................. 20 Service blueprint ......................................................................................................................................... 20 Mapa do serviço .......................................................................................................................................... 21 IDEF ........................................................................................................................................................... 21 Estrutura de processamento de clientes ........................................................................................................ 22 Walk-through-audit ..................................................................................................................................... 22 Análise da transação de serviço (STA – Service Transaction Analysis) ......................................................... 23
Exercícios ........................................................................................................................................... 23
Gerência de Serviços de TI ........................................................................................................... 25 3.1
Fundamentos da ITIL V2 .................................................................................................................. 26
3.1.1 3.1.2
3.2
Suporte a serviços ........................................................................................................................................ 26 Entrega de Serviço....................................................................................................................................... 27
Fundamentos de ITIL V3 .................................................................................................................. 28
3.2.1 3.2.2 3.2.3 3.2.4 3.2.5
3.3
Estratégia do serviço (Service Strategy) ....................................................................................................... 28 Desenho de serviço (Service Design) ........................................................................................................... 28 Transição do serviço (Service Transition) .................................................................................................... 29 Operação do serviço (Service Operation) ..................................................................................................... 29 Melhoria de serviço continuada (Continual Service Improvement) ............................................................... 29
Fundamentos de COBIT.................................................................................................................... 29
3.3.1 3.3.2 3.3.3 3.3.4
3.4
4
Planejar e Organizar .................................................................................................................................... 30 Adquirir e Implementar ............................................................................................................................... 30 Entregar e Dar Suporte ................................................................................................................................ 30 Monitorar e Avaliar ..................................................................................................................................... 31
Exercícios ........................................................................................................................................... 31
Engenharia de Software ............................................................................................................... 33 4.1
Software ............................................................................................................................................. 33
4.2
Ciclo de vida do software ................................................................................................................... 34
4.2.1 4.2.2 4.2.3 4.2.4
4.3
Fase de Definição ........................................................................................................................................ 34 Fase de Desenvolvimento ............................................................................................................................ 34 Fase de Operação ........................................................................................................................................ 35 Fase de retirada ........................................................................................................................................... 36
Metodologias de desenvolvimento de software. ................................................................................ 36
4.3.1 4.3.2
Modelo caótico ............................................................................................................................................ 36 Modelo Cascata ........................................................................................................................................... 36
4.4
Desenvolvimento ágil ......................................................................................................................... 38
4.5
Planejamento e avaliação de iterações .............................................................................................. 39
Pág. 2 de 143
Walter de Tarso
4.6
Técnicas de avaliação de software ..................................................................................................... 40
4.6.1 4.6.2
4.7
Análise por Pontos de Função ...................................................................................................................... 40 Método COCOMO ...................................................................................................................................... 44
Gerência de Requisitos de Software .................................................................................................. 44
4.7.1 4.7.2
4.8
Conceitos de Requisitos ............................................................................................................................... 45 Requisitos Funcionais e Não-Funcionais ...................................................................................................... 46
Gerência de Configuração e Mudança .............................................................................................. 47
4.8.1 4.8.2
4.9
Conceitos de Gerência de Configuração e Mudança de software ................................................................... 47 Solicitações de Mudança.............................................................................................................................. 48
Testes e Avaliação de Qualidade de Software ................................................................................... 49
4.9.1 4.9.2 4.9.3
Qualidade de Software................................................................................................................................. 49 Teste de software......................................................................................................................................... 51 Documentos de Teste................................................................................................................................... 52
4.10
5
Exercícios ........................................................................................................................................ 53
Arquitetura de Software................................................................................................................ 59 5.1
Conceitos básicos ............................................................................................................................... 59
5.2
UML ................................................................................................................................................... 59
5.3
GED - Gerenciamento Eletrônico de Documentos e Workflow ....................................................... 61
5.3.1
5.4
Exercícios ................................................................................................................................................... 62
Arquitetura Orientada a Serviço (SOA) ........................................................................................... 63
5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6 5.4.7 5.4.8 5.4.9 5.4.10
6
5.5
Portais corporativos e colaborativos ................................................................................................. 69
5.6
Exercícios ........................................................................................................................................... 70
Banco de Dados ............................................................................................................................ 73 6.1
Conceitos básicos ............................................................................................................................... 73
6.2
Modelagem de Dados Relacional ....................................................................................................... 73
6.2.1 6.2.2 6.2.3 6.2.4
Normalização .............................................................................................................................................. 74 Etapas de modelagem .................................................................................................................................. 75 Relacionamentos ......................................................................................................................................... 75 Transação .................................................................................................................................................... 76
6.3
Modelo Entidade Relacionamento..................................................................................................... 76
6.4
Modelagem de Dados Multidimensional ........................................................................................... 77
6.4.1
6.5 6.5.1
6.6 6.6.1 6.6.2 6.6.3
6.7
7
Serviço ........................................................................................................................................................ 63 Processos .................................................................................................................................................... 63 Tecnologia .................................................................................................................................................. 63 Definições de SOA ...................................................................................................................................... 63 Web Services .............................................................................................................................................. 64 SOAP .......................................................................................................................................................... 66 WSDL ......................................................................................................................................................... 67 UDDI .......................................................................................................................................................... 67 Segurança.................................................................................................................................................... 68 Exercícios ................................................................................................................................................... 68
Sistemas Transacionais X Sistemas Analíticos ............................................................................................. 78
Conceitos de Datawarehouse e ETL .................................................................................................. 78 ETL ............................................................................................................................................................ 80
Conceitos de desenvolvimento em banco de dados SQL Server e Oracle ........................................ 80 SQL ............................................................................................................................................................ 80 Arquitetura de um Servidor Oracle............................................................................................................... 82 Arquitetura de um Servidor SQL Server ....................................................................................................... 83
Exercícios ........................................................................................................................................... 84
Programação de Sistemas ............................................................................................................. 90 7.1
Lógica de Programação ..................................................................................................................... 90
Curso de TI
7.1.1
7.2
Tipos de dados e variáveis ........................................................................................................................... 91
Programação orientada a objetos ...................................................................................................... 92
7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 7.2.7 7.2.8 7.2.9 7.2.10 7.2.11
7.3
Programação na WEB ....................................................................................................................... 95
7.3.1 7.3.2 7.3.3
7.4
Linguagem HTML ...................................................................................................................................... 96 Linguagens web de servidor......................................................................................................................... 97 XML ........................................................................................................................................................... 98
Conceitos de linguagem de programação Microsoft .NET ............................................................... 98
7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6 7.4.7 7.4.8 7.4.9 7.4.10 7.4.11 7.4.12
7.5
8
9
Objetos........................................................................................................................................................ 92 Classe ......................................................................................................................................................... 93 Persistência ................................................................................................................................................. 93 Métodos ...................................................................................................................................................... 93 Atributos ..................................................................................................................................................... 94 Mensagens .................................................................................................................................................. 94 Herança ....................................................................................................................................................... 94 Polimorfismo............................................................................................................................................... 94 Sobrecarga .................................................................................................................................................. 95 Interfaces .................................................................................................................................................... 95 Pacotes ........................................................................................................................................................ 95
arquitetura da .Net ....................................................................................................................................... 99 Linguagens de programação ........................................................................................................................ 99 Common Language Specification (CLS) .................................................................................................... 100 Common Type System (CTS) .................................................................................................................... 100 Framework Class Library (FCL) ................................................................................................................ 100 Camada de apresentação ............................................................................................................................ 100 ADO.Net ................................................................................................................................................... 100 .Net Remoting ........................................................................................................................................... 100 Common Language Runtime (CLR)........................................................................................................... 101 Common Language Infrastructure (CLI) .................................................................................................... 101 Operating System (OS) .............................................................................................................................. 101 Outros detalhes da .Net .............................................................................................................................. 101
Exercícios ......................................................................................................................................... 102
Segurança da informação........................................................................................................... 106 8.1
Conceitos básicos ............................................................................................................................. 106
8.2
Plano de Continuidade de Negócio .................................................................................................. 108
8.3
Vulnerabilidade ............................................................................................................................... 108
8.4
Auditoria e conformidade ................................................................................................................ 109
8.5
Conhecimento sobre norma ISO 27001........................................................................................... 111
8.6
Exercícios ......................................................................................................................................... 111
Sistemas Operacionais ................................................................................................................ 115 9.1
Conceitos de administração de servidores em plataforma Windows ............................................. 115
9.2
Conceitos de administração de servidores em plataforma Linux ................................................... 115
9.2.1 9.2.2 9.2.3 9.2.4 9.2.5 9.2.6 9.2.7 9.2.8 9.2.9 9.2.10
Alguns comandos no Linux ....................................................................................................................... 115 Gerenciando a iniciação do Linux .............................................................................................................. 117 Fazendo Backups....................................................................................................................................... 117 Recompilando e Adaptando o Kernel ......................................................................................................... 117 Agendando Processos ................................................................................................................................ 117 Syslogd - A Caixa Preta do Linux .............................................................................................................. 117 Técnicas Básicas para Trabalhar com Redes (ifconfig, route) ..................................................................... 118 Gerenciando os Serviços - inetd ................................................................................................................. 118 Utilizando Ferramentas de Busca ............................................................................................................... 118 Instalando SSh / SShD .............................................................................................................................. 118
9.3
Conceitos de Virtualização .............................................................................................................. 119
9.4
Active Directory ............................................................................................................................... 121
Pág. 4 de 143
Walter de Tarso
9.5
10
Exercícios ......................................................................................................................................... 122
Redes ....................................................................................................................................... 125
10.1
Conceito de rede ........................................................................................................................... 125
10.1.1
10.2
Configuração de redes TCP-IP ................................................................................................................... 125
Arquitetura de Rede ..................................................................................................................... 127
10.2.1 10.2.2 10.2.3 10.2.4 10.2.5 10.2.6 10.2.7
Camada Física ........................................................................................................................................... 128 Camada de Enlace ou Ligação de Dados .................................................................................................... 128 Camada de Rede ........................................................................................................................................ 128 Camada de Transporte ............................................................................................................................... 129 Camada de Sessão ..................................................................................................................................... 129 Camada de Apresentação ........................................................................................................................... 129 Camada de Aplicação ................................................................................................................................ 129
10.3
Noções de administração de redes................................................................................................ 130
10.4
Acesso Remoto .............................................................................................................................. 130
10.5
Rede Wireless ............................................................................................................................... 130
10.6
Exercícios ...................................................................................................................................... 131
11
Referências .............................................................................................................................. 135
12
Sobre o autor ........................................................................................................................... 136
13
Gabarito................................................................................................................................... 137
Sumário de imagens Ilustração 1 Métricas .......................................................................................................................................... 13 Ilustração 2 Exemplo de Fluxo utilizando pool, lanes, evento de início e fim, tarefas e gateway ......................... 19 Ilustração 3 Símbolos BMPN utilizados no MS Visio .......................................................................................... 19
TI para concursos
1
Gerência de Projetos
1.1
Conceitos básicos 1
Um projeto é um esforço temporário empreendido para criar um produto, não necessariamente temporário, serviço ou resultado exclusivo. Os projetos e as operações diferem, principalmente, no fato de que os projetos são temporários e exclusivos, enquanto as operações são contínuas e repetitivas. Os projetos são normalmente autorizados como resultado de uma ou mais considerações estratégicas. Estas podem ser uma demanda de mercado, necessidade organizacional, solicitação de um cliente, avanço tecnológico ou requisito legal. As principais características dos projetos são: temporários, possuem um início e um fim definidos. planejados, executado e controlado. entregam produtos, serviços ou resultados exclusivos. desenvolvidos em etapas e continuam por incremento com uma elaboração progressiva. realizados por pessoas. com recursos limitados. Esse é um resumo da definição de projeto feita pelo Guia PMBOK®, um guia que identifica o subconjunto do conjunto de conhecimentos em gerenciamento de projetos, amplamente reconhecido como boa prática na maioria dos projetos na maior parte do tempo e utilizado como base pelo Project Management Institute ( PMI®). Gerência de projetos é a disciplina de manter os riscos de fracasso em um nível tão baixo quanto necessário durante o ciclo de vida do projeto. Sua função é definir e alcançar objetivos ao mesmo tempo em que se otimiza o uso de recursos (tempo, dinheiro, pessoas, espaço etc).2 Na abordagem tradicional, distinguimos cinco grupos de processos no desenvolvimento de um projeto: iniciação – autorização do projeto ou fase planejamento – são processos iterativos de definição e refinamento de objetivos e seleção dos melhores caminhos para atingir os objetivos. execução – realização dos planos do projeto: coordenação de pessoas e outros recursos para executar o plano controle – medição e monitoramento do desempenho do projeto. Garantem que os objetivos do projeto são alcançados através do monitoramento e medição regular do progresso, de modo que ações corretivas possam ser tomadas quando necessário. encerramento – aceitação formal do projeto (com verificação de escopo) ou fase para a sua finalização. Repetir os processos de iniciação antes da execução de cada fase é uma maneira de se avaliar se o projeto continua cumprindo as necessidades de negócio. Envolver as partes interessadas no projeto em cada uma das fases é uma maneira de aumentar as probabilidades de satisfação dos requisitos do cliente. O gerente de projetos precisa monitorar e comunicar o desempenho do projeto. Os resultados do trabalho que estiverem abaixo de um nível de desempenho aceitável precisam ser ajustados com ações corretivas para que o projeto volte a estar em conformidade com as linhas de base de custo, prazo e escopo. A comunicação do desempenho do projeto é um dos principais elementos para o gerenciamento de projetos bem sucedido. O projeto ou empreendimento visa a satisfação de uma necessidade ou oportunidade, definida no texto acima como fase inicial na qual existem muitas áreas e/ou pessoas envolvidas. Um programa é um conjunto de projetos com um objetivo comum. Em geral, existe mais do que uma solução ou alternativas para atender às mesmas necessidades. A técnica usada para definir a solução final passa pelo desenvolvimento de alternativas extremas. A primeira, de baixo custo, que atende as necessidades mínimas para ser funcional. A segunda tenta atender a maior parte das as exigências das diversas áreas envolvidas no escopo, que resulta num projeto com custo muito maior e pouco competitivo. A partir de ambas as alternativas é desenvolvida 1
http://pt.wikipedia.org/wiki/Projeto
2
http://pt.wikipedia.org/wiki/Gerência_de_projetos
1
TI para concursos
uma solução intermediária entre as mesmas, que atende a uma boa parte das exigências com um custo competitivo. O gerenciamento de projetos tenta adquirir controle sobre as variáveis tempo - influencia o prazo até o termino do projeto. Uma restrição de tempo pode significar custos aumentados e/ou escopo reduzido. custo - informa o valor monetário incluído no orçamento disponível para o projeto. Um orçamento apertado pode significar tempo aumentado e/ou escopo reduzido. escopo - designa o que deve ser feito para produzir o resultado de fim do projeto. O escopo aumentado pode significar o tempo aumentado e/ou o custo aumentado. Na versão atual do PMBOK, tríplice restrição foi eliminada, passando a existir restrições do projeto que são elas: Escopo, Qualidade, Cronograma, Orçamento, Recursos e Riscos. Portanto, qualquer alteração em um desses itens certamente haverá restrições em um ou mais dos demais itens. Para manter o controle sobre o projeto do início ao fim, um gerente de projetos utiliza várias técnicas, dentre as quais se destacam: Planejamento de projeto Análise de valor agregado Gerenciamento de riscos de projeto Cronograma Melhoria de processo
1.2
Processos do PMBOK O Guia PMBOK3 identifica um subconjunto do conjunto de conhecimentos em gerenciamento de projetos, que é amplamente reconhecido como boa prática, sendo em razão disso, utilizado como base pelo Project Management Institute (PMI). Uma boa prática não significa que o conhecimento e as práticas devem ser aplicadas uniformemente a todos os projetos, sem considerar se são ou não apropriados. O Guia PMBOK também fornece e promove um vocabulário comum para se discutir, escrever e aplicar o gerenciamento de projetos possibilitando o intercâmbio eficiente de informações entre os profissionais de gerência de projetos. O guia é baseado em processos e subprocessos para descrever de forma organizada o trabalho a ser realizado durante o projeto. Essa abordagem se assemelha à empregada por outras normas como a ISO 9000 e o Software Engineering Institute's, CMMI. A versão 2008 do guia, cita 42 processos agrupados em cinco grupos e nove áreas de conhecimento. O conhecimento de gerenciamento de projetos, descrito no Guia PMBOK consiste em: Definição do ciclo de vida e da organização de um projeto Descrição dos cinco grupos de processos de gerenciamento de projetos Grupo de processos de iniciação Grupo de processos de planejamento Grupo de processos de execução Grupo de processos de monitoramento e controle Grupo de processos de encerramento Descrição das nove áreas de conhecimento Existem três documentos principais descritos no Guia PMBOK® e cada um deles possui um objetivo específico: Termo de abertura do projeto. Autoriza formalmente o projeto. Declaração do escopo do projeto. Determina qual trabalho deverá ser realizado e quais entregas precisam ser produzidas. Plano de gerenciamento do projeto. Determina como o trabalho será realizado.
3
http://pt.wikipedia.org/wiki/PMBOK
2
TI para concursos
1.2.1
Áreas de conhecimento do PMBOK Os quarenta e dois processos dos cinco grupos definidos pelo PMBOK podem ser classificados em nove chamadas áreas de conhecimento. Iniciação Desenvolver o termo de abertura do projeto Desenvolver o escopo preliminar do projeto
4 - Integração
Planejamento Desenvolver o plano de gerenciamento de projeto
Planejamento do escopo Definição do escopo Criar EAP Definição das atividades Sequenciamento de atividades Estimativa de recursos das atividades Estimativa de duração das atividades Desenvolvimento do cronograma Estimativa de custos Orçamentação Planejamento da qualidade
5 - Escopo
6 - Tempo
7 - Custo 8 - Qualidade
12 - Aquisições
Encerramento Encerrar o projeto
Controle do cronograma
Controle de custos Realizar o controle da qualidade Gerenciar a equipe do projeto
Planejamento das comunicações Planejamento de gerenciamento de riscos Identificação dos riscos Análise qualitativa dos riscos Análise quantitativa dos riscos Planejamento de respostas a riscos Planejar compras e aquisições Planejar contratações
Solicitar respostas dos fornecedores Selecionar fornecedores
Administração de contratos
Planejamento de RH
11 - Riscos
Monitoramento e controle Monitorar e controlar o trabalho do projeto Controle integrado de mudanças Verificação do escopo Controle do escopo
Realizar a garantia da qualidade Controlar ou mobilizar a equipe do projeto Desenvolver a equipe do projeto Distribuição das informações
9 - RH
10 - Comunicação
Execução Orientar e gerenciar a execução do projeto
Relatório de desempenho Gerenciar as partes interessadas Monitoramento e controle de riscos
Encerramentos de contratos
Os processos descritos se relacionam e interagem durante a condução do trabalho e a descrição de cada um deles é feita em termos de: Entradas – documentos, planos, desenhos etc. Ferramentas e técnicas - que se aplicam as entradas Saidas – que podem ser entradas de outros processos
3
TI para concursos
1.2.1.1
Integração de projetos Núcleo do gerenciamento de projetos, é composto dos processos do dia-a-dia com os quais o gerente de projetos conta para garantir que todas as partes do projeto funcionem juntas. É um processo contínuo que o gerente completa para garantir que o projeto prossiga do início ao fim – é a atividade diária de completar o trabalho do projeto..
4
TI para concursos
1.2.1.2
Escopo de projetos Garantir que o projeto inclui todo o trabalho requerido (requisitos), e somente o trabalho requerido. Destaca-se nesta área a criação da estrutura analítica de processos (EAP), ou Work Breakdown Structure (WBS), uma ferramenta de decomposição do trabalho do projeto em partes manejáveis, uma estrutura em forma de árvore exaustiva, hierárquica (de mais geral para mais específica) de entregáveis (deliverables) e tarefas, genericamente pacotes, que precisam ser feitas para completar um projeto. Um instrumento facilitador do planejamento de projeto que o desmembra em atividades menores que podem ser mais facilmente dimensionadas em relação a tempo de execução, recursos e custos.
5
TI para concursos
1.2.1.3
6
Tempo de projetos Completar o projeto dentro do prazo.
TI para concursos
1.2.1.4
7
Custo de projetos Completar o projeto dentro do orçamento.
TI para concursos
1.2.1.5
8
Qualidade de projetos Garantir que o projeto vai satisfazer as necessidades pelas quais ele foi feito. Qualidade não é o melhor resultado possível, mas o atendimento justo dos requisitos, do cronograma e orçamento. Qualidade é a totalidade de características de uma entidade que a torna capaz de satisfazer necessidades declaradas ou implícitas . Um aspecto crítico da gerência da qualidade, no contexto do projeto, é a necessidade de traduzir as necessidades implícitas em necessidades declaradas, através da gerência do escopo do projeto
TI para concursos
1.2.1.6
9
Recursos humanos de projetos Fazer o uso mais efetivo das pessoas envolvidas no projeto.
TI para concursos
1.2.1.7
10
Comunicações de projetos Garantir rápida e adequada geração, coleção, disseminação, armazenamento e disposição final das informações do projeto.
TI para concursos
1.2.1.8
11
Riscos de projetos Identificar, analisar e responder aos riscos do projeto.
TI para concursos
1.2.1.9
12
Aquisições de projetos Adquirir bens e serviços externos.
TI para concursos
1.3
Planejamento e controle de métricas de projeto Métricas são medidas quantitativas que podem produzir informações usadas para minimizar atrasos e riscos, e para avaliar a qualidade durante o desenvolvimento. Definições: Medida - fornece uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto ou processo. Medição - ato de determinação de uma medida. Ilustração 1 Métricas Métrica - medida quantitativa do grau em que um sistema se encontra em relação a um determinado atributo. Indicadores - métrica ou combinação de métricas que fornece uma compreensão de um processo, projeto ou produto. Tipos de métricas: Diretas - custo, esforço, linhas de código (LOC), velocidade de execução, memória utilizada, defeitos reportados etc. Indiretas - qualidade, funcionalidade, complexidade, eficiência, confiabilidade, manutebilidade etc. O planejamento de métricas pode ser feito em etapas. Fase 1 – caracterização dos indicadores Fase 2 – medição Fase 3 – tratamento estatístico Fase 4 – monitoramento e análise Fase 5 – gestão do processo As tendências são mais importantes de serem monitoradas do que qualquer valor absoluto no tempo. As métricas para determinados aspectos do projeto incluem: Métrica
Finalidade
Andamento em termos de tamanho e complexidade
Planejamento de iteração Abrangência
Exemplos de medidas/perspectivas Número de classes SLOC Pontos de função Cenários Casos de teste Essas medidas também podem ser coletadas por classe e por pacote Quantidade de retrabalho por iteração (número de classes)
Estabilidade em termos Convergência de taxa de mudança nos requisitos ou implementação, tamanho ou complexidade
Adaptabilidade
Convergência "Retrabalho" de software
Modularidade em termos do escopo de mudança
Convergência "Retalhamento" de software
Número e tipo de mudanças (erro versus melhoria; interface versus implementação) Essa medida também pode ser coletada por iteração e por pacote Quantidade de retrabalho por iteração
Média de pessoa-horas/mudança Essa medida também pode ser coletada por iteração e por pacote
Qualidade em termos Planejamento de iteração da quantidade e do tipo Indicador de retrabalho de erros Critério de release
13
Número de classes/categorias modificadas por mudança Essa medida também pode ser coletada por iteração Número de erros Taxa de detecção de defeitos Densidade de defeitos Profundidade da herança Acoplamento de classes Tamanho da interface (número de operações) Número de métodos substituídos Tamanho do método
TI para concursos Métrica
Finalidade
Exemplos de medidas/perspectivas Essas medidas também podem ser coletadas por classe e por pacote
Maturidade em termos da freqüência de erros
Perfil de despesas do projeto versus despesas planejadas
1.4
Adequação/cobertura de teste Resistência para uso Visão financeira Planejado versus real
Falha/horas de teste e tipo de falha Essa medida também pode ser coletada por iteração e por pacote Pessoa-dias/classe Equipe em tempo integral por mês Porcentagem do orçamento já gasta
Métodos de gerenciamento do tempo do projeto Existem métodos que objetivam formas de comprimir as durações das atividades sem alteração no escopo do projeto. Crashing é usado para diminuir a duração total do cronograma do projeto pelo menor custo adicional, como redução das durações ou aumento da atribuição de recursos nas atividades do cronograma. Paralelismo ou fast tracking é usado para tentar programar atividades em paralelo (simultâneas), mas costuma gerar retrabalho e aumenta os riscos. É uma técnica de compressão do cronograma de um projeto específico que altera a lógica de rede para sobrepor fases que normalmente seriam realizadas em seqüência, como a fase de projeto e a fase de construção, ou para realizar atividades do cronograma em paralelo. Uma simulação do projeto utiliza um modelo que traduz as incertezas especificadas em um nível detalhado do projeto para seu impacto potencial nos objetivos do projeto. As simulações são normalmente realizadas usando a técnica de Monte Carlo. Em uma simulação, o modelo do projeto é calculado muitas vezes (iterado), sendo os valores das entradas randomizados a partir de uma função de distribuição de probabilidades (por exemplo, custo dos elementos do projeto ou duração das atividades do cronograma) escolhida para cada iteração a partir das distribuições de probabilidades de cada variável. Uma distribuição de probabilidades (por exemplo, custo total ou data de término) é calculada.
1.5
14
Exercícios 1.
(ICMS-SP 2009) A respeito dos conceitos aplicados aos Projetos, segundo o PMBOK, é INCORRETO 1 afirmar: (a) A equipe do projeto, como uma unidade de trabalho, raramente sobrevive ao projeto. xx (b) Um projeto é um esforço contínuo que visa manter um serviço em funcionamento. (c) Geralmente, o termo "temporário" não se aplica ao produto, serviço ou resultado criado pelo projeto. (d) Pode ser classificado como projeto aquele que é do tipo de pesquisa que desenvolve um conhecimento. (e) Os projetos podem criar uma capacidade de realizar um serviço.
2.
(ICMS-SP 2009) São entradas para o processo de Planejamento da Qualidade (PMBOK): (a) Fatores ambientais da empresa, Ativos de processos organizacionais e Declaração do escopo do xx projeto. (b) Análise de custo-benefício, Projeto de experimentos e Métricas de qualidade. (c) Plano de melhorias no processo, Linha de base da qualidade e Métricas de qualidade. (d) Plano de melhorias no processo, Fatores ambientais da empresa e Listas de verificação da qualidade. (e) Plano de gerenciamento da qualidade, Fatores ambientais da empresa e Análise de custo-benefício.
3.
(ICMS-SP 2009) No PMBOK, a técnica que compara as realizações técnicas durante a execução do projeto com as do cronograma do plano de gerenciamento do projeto, podendo usar parâmetros técnicos importantes do produto desenvolvido pelo projeto como uma métrica de qualidade, sendo que os valores 3 medidos fazem parte das informações sobre o desempenho do trabalho, é denominada (a) Critical Chain Method. (b) Probability and Impact Matrix. (c) Work Performance Information. (d) Performance Measurement Baseline. xx (e) Technical Performance Measurement.
2
TI para concursos
15
4.
(ICMS-SP 2009) Planos mais exatos e completos, resultantes de sucessivas iterações do processo de planejamento e estimativas mais exatas, elaboradas à medida que o projeto se desenvolve, são produtos da técnica aplicada para melhoria e detalhamento contínuos dos planos. Essa técnica, no PMBOK, é 4 denominada (a) Loop de rede. xx (b) Elaboração progressiva. (c) Estrutura Analítica dos Recursos. (d) Gerenciamento de Portfólios. (e) Estimativa paramétrica.
5.
Segundo o PMBOK, as etapas de iniciação, planejamento, execução, monitoração/controle e encerramento 5 representam apenas o (a) ciclo de vida dos projetos ou ciclo de gerenciamento de projetos. (b) grupo de processos dos projetos ou ciclo de gerenciamento de projetos. (c) grupo de processos dos projetos ou ciclo de vida dos projetos. (d) grupo de processos do gerenciamento de projetos ou ciclo de vida dos projetos. (e) grupo de processos do gerenciamento de projetos ou ciclo de gerenciamento de projetos.x
6.
Os processos do PMBOK: criação da estrutura analítica do projeto (EAP) e verificação do escopo do projeto 6 devem ser realizados, respectivamente, nas etapas de (a) planejamento e execução. xx (b) planejamento e monitoração/controle. (c) iniciação e execução. (d) iniciação e monitoração/controle. (e) iniciação e encerramento.
7.
Considere a seguinte definição com respeito à gerência de projetos: Ferramenta de decomposição do trabalho do projeto em partes manejáveis. É uma estrutura em forma de árvore exaustiva, hierárquica (de mais geral para mais específica ) de deliverables e tarefas que precisam ser feitas para completar um projeto. 7 Tal é a definição de (a) Histogram. (b) Workflow. (c) Timesheet. xx (d) Work Breakdown Structure. (e) Flowchart.
8.
Um instrumento facilitador do planejamento de projeto que o desmembra em atividades menores que podem 8 ser mais facilmente dimensionadas em relação a tempo de execução, recursos e custos, é o (a) Flowchart. (b) Organization Chart. (c) Workflow. (d) Histogram. xx (e) Work Breakdown Structure.
9.
De acordo com o corpo de conhecimento da gerência de projetos, as simulações para análise de risco de 9 prazos são possíveis utilizando (a) o Arrow Diagramming Method. xx (b) a técnica Monte Carlo. (c) o modelo WBS. (d) a análise de custo/benefício. (e) o Project Charter.
10.
O WBS, Word Breakdown Structure, é a principal ferramenta de gerenciamento de (a) escopo do projeto.xx (b) integração dos elementos do projeto. (c) pessoal envolvido com o projeto. (d) comunicação das informações do projeto. (e) qualidade do projeto.
11.
Considere a seguinte figura: No contexto da gerência de projetos de software, o diagrama parcialmente mostrado na figura representa, 11 tipicamente, (a) um PERT. (b) um gráfico de Gantt. xx (c) uma Work Breakdown Structure. (d) um Project Charter. (e) um Flowchart.
10
TI para concursos
16
12.
De acordo com o corpo de conhecimento da gerência de projeto, a necessidade de traduzir as necessidades 12 implícitas em necessidades declaradas, através da gerência do escopo do projeto, é xx (a) um aspecto crítico da gerência da qualidade, no contexto do projeto. (b) objeto de avaliação da gerência do custo do projeto. (c) dispensada se for elaborado um planejamento de respostas aos riscos. (d) destacada durante a medição de desempenho. (e) um aspecto crítico da análise de precedência de tarefas.
13.
De acordo com o corpo de conhecimento da gerência de projeto, para estimar os custos totais, quando ainda existe uma quantidade limitada de informações detalhadas sobre o projeto (por exemplo, nas fases iniciais), é 13 freqüentemente (a) elaborado um modelo paramétrico. xx (b) usada uma estimativa por analogia. (c) usada uma estimativa bottom-up. (d) elaborada uma análise de precedência. (e) elaborada uma análise da variação.
14.
Existem métodos que objetivam formas de comprimir as durações das atividades sem alteração no escopo do projeto. Um deles é usado para quando existem negociações de agenda e custos para determinar como (e se) fazer a maior compressão para o menor custo. Outro é usado para tentar programar atividades em paralelo (simultâneas), mas costuma gerar retrabalho e aumenta os riscos. São usual e respectivamente 14 denominados de métodos (a) crashing e what-if. (b) de Monte Carlo e what-if. (c) fast tracking e de Monte Carlo. xx (d) crashing e fast tracking. (e) what-if e crashing.
15.
Para um gerenciamento de projeto de informática bem sucedido, a ordem de execução das atividades deve 15 ser (a) planejamento, integração, organização, medição e revisão. xx (b) planejamento, organização, integração, medição e revisão. (c) organização, planejamento, integração, medição e revisão. (d) organização, planejamento, medição, integração e revisão. (e) planejamento, organização, medição, revisão e integração.
16.
(ARCE FCC 2006) O fator de máximo desempenho de um projeto está diretamente relacionado ao fator de (a) escopo limitado. (b) escopo genérico. (c) tempo reduzido. xx (d) custo alto. (e) tempo excessivo.
17.
(CVM FCC 2006) Dentre os fatores que afetam os projetos, o fator performance se aproxima do máximo, ou 17 ponto ótimo, quando relacionado ao fator xx (a) custo alto. (b) tempo reduzido. (c) tempo excessivo. (d) escopo limitado. (e) escopo genérico.
18.
Duas atividades de um projeto podem ocorrer simultaneamente quando o inter-relacionamento das mesmas 18 é do tipo (a) início para início (SS) ou término para início (FS). (b) término para término (FF) ou término para início (FS). xx (c) início para início (SS) ou término para término (FF). (d) início para término (SF) ou término para término (FF). (e) término para início (FS) ou início para término (SF).
19.
Os produtos a serem entregues no mais baixo nível da estrutura do projeto (WBS) geralmente são xx (a) pacotes de trabalho. (b) planos do projeto. (c) fases do projeto. (d) recursos disponíveis. (e) cronogramas do projeto.
20.
Segundo o uso universal dos conceitos de gerenciamento de projetos, um programa é (a) um empreendimento não repetitivo de eventos numa seqüência clara e lógica, com início, meio e fim. (b) parte de um projeto ou subdivisão tática de fácil gerenciamento e controle. (c) um subprojeto, desvinculado de um projeto, que pode ser terceirizado. xx (d) um conjunto integrado de projetos que tem missões e objetivos comuns. (e) um conjunto de subprojetos, que podem ter vidas próprias isoladamente.
20
19
16
TI para concursos
17
21.
No ciclo da vida de um projeto, são aplicáveis todos os nove processos componentes da área de 21 gerenciamento de projetos somente na fase de (a) iniciação. (b) finalização. xx (c) planejamento. (d) execução. (e) controle.
22.
Na determinação de cronogramas utilizando os modelos PERT e CPM, o caminho crítico representa (a) a estimativa de tempo mais provável para o conjunto de tarefas do projeto. (b) o término mais breve da cada tarefa do projeto. (c) os limites de tempo que definem o início e o término da cada tarefa. xx (d) uma cadeia de tarefas que determina a duração do projeto. (e) uma rede de todas as tarefas desde o começo até o final de um projeto.
22
TI para concursos
2
Gestão de Processos de Negócio (BPM) O Business Process Management (BPM) ou Gerenciamento de Processos de Negócio é um conceito que une gestão de negócios e tecnologia da informação com foco na otimização dos resultados das organizações através da melhoria dos processos de negócio. São utilizados métodos, técnicas e ferramentas para analisar, modelar, publicar, otimizar e controlar processos envolvendo recursos humanos, aplicações, documentos e outras fontes de informação. 4 Um processo de negócio é uma sequência de tarefas que, ao serem executadas, transforma insumos em um resultado com valor agregado. Distingue-se do conceito de BI (business intelligence), pois este monitora as informações que dão suporte ao negócio, enquanto aquele monitora os processos que o compõe. O BI é uma ferramenta útil à gestão de processos de negócios.
2.1
BPMN - Modelagem de processos O Business Process Modeling Notation, em português Notação de Modelagem de Processos de Negócio, é uma notação da metodologia de gerenciamento de processos de negócio e trata-se de uma série de ícones padrões para o desenho de processos, o que facilita o entendimento do usuário. A modelagem é uma etapa importante da automação, pois é nela que os processos são descobertos e desenhados. É nela também que pode ser feita alguma alteração no percurso do processo visando a sua otimização. A notação também pode ser utilizada para a modelagem de Arquitetura de Processos. O objetivo do BPMN é de apoiar a gestão de processos de negócios tanto para usuários técnicos e usuários de negócios, fornecendo uma notação que é intuitiva para os usuários corporativos ainda capaz de representar a semântica complexa do processo.
2.1.1
Elementos A modelagem em BPMN é feita através de diagramas simples, com um pequeno conjunto de elementos gráficos. Isto facilita que os usuários de negócio, bem como os desenvolvedores, entendam o fluxo e o processo. As quatro categorias básicas de elementos são as seguintes: Objetos de Fluxo – definem o comporatmento do fluxo. Fazem a movimentação das informações através de ações. Eventos – Qualquer coisa que acontece durante o fluxo. Ações (trigger) que interferem no fluxo (result), tipicamente prazos, também podendo ser uma chamada de um sistema externo (web service) ou alguma alteração no banco de dados (watching). Representado por um círculo. Há três tipos de eventos: início, intermediário e fim. Atividades – Ações (sub-processos ou tarefas) realizadas pelos usuários, chamados de atores, normalmente por tela de algum programa de computador. Representada por um retângulo arredondado. Gateways – Controla a convergência e divergência da sequência de fluxos e atividades no fluxo. Determina ramificações (branch), bifurcações (forking), mistura (merging) e junções (join) de caminhos. Representado por um losango. Objetos de Conexão Fluxo de Sequência – seta em linha contínua ligando dois objetos, indica a ordem de execução dos objetos. Fluxo de Mensagem – seta em linha tracejada indicando o fluxo de mensagens entre participantes Associação – linha ou seta em linha pontilhada indicando uma ligação entre uma informação, normalmente uma anotação, e um artefato. Swim lane – uma área de agrupamento de objetos de fluxo representado por uma faixa que vai da esquera à direita da página, com um nome para a faixa em seu lado esquerdo. Pool – indica um participante, setor, departamento ou qualquer lugar onde se encontram os atores. Um pool pode apresentar detalhes internos do processo (white box) ou pode ter nenhum processo (black box). A interação entre pools é feita através de fluxos de mensagens. Nenhum fluxo de sequência pode ser associado a black boxes, mas os fluxos de mensagem podem ligá-los. Lane – subdivisão de uma pool.
4
http://pt.wikipedia.org/wiki/Business_Process_Management
18
TI para concursos
Dados – possuem informações que os objetos de fluxo necessitam para serem realizadas Objetos de dados – informações armazenadas Dados de entrada – informações solicitadas Dados de saída – informações produzidas em uma atividade ou evento Armazenamento – gravação dos dados Artefatos – informações adicionais sobre o fluxo Grupo – agrupamento de elementos de uma mesma categoria para fins de entendimento, sem efeito sobre o fluxo. Representado por um retângulo arredondado tracejado. Anotação – uma observação para facilitar o entendimento do fluxo para o leitor. Represnetado por uma linha de associação terminada por um colchete e o texto. Mensagem – informação enviada entre dois participantes. Representado por ícone de uma carta. Estas quatro categorias de elementos nos dão a oportunidade de fazer um diagrama de processos de negócio simples (BPD).
Ilustração 2 Exemplo de Fluxo utilizando pool, lanes, evento de início e fim, tarefas e gateway
Ilustração 3 Símbolos BMPN utilizados no MS Visio
19
TI para concursos
2.2
Técnicas de análise de processos
2.2.1
Automação de processos Realizada pelos BPMS, divide-se em modelagem, simulação, execução, controle e otimização. Um aplicativo do tipo BPMS, tipicamente, inclui o mapeamento dos processos de negócio ponta-aponta, desenho dos fluxos e formulários eletrônicos, definição de workflow, regras de negócio, integradores, monitoração em tempo real das atividades e alertas. É uma poderosa ferramenta de gestão, para garantir que os processos estão sendo efetivamente executados como modelados, contribuindo para os objetivos da organização. A modelagem de processos é feita no próprio BPMS. Alguns destes seguem a notação mais usada atualmente, o BPMN (Business Process Modeling Notation). Esta notação trata-se de uma série de ícones padrões para o desenho de processos, o que facilita o entendimento do usuário. A modelagem é uma etapa importante da automação pois é nela que os processos são descobertos e desenhados. É nela também que pode ser feita alguma alteração no percurso do processo visando a sua otimização. Após o desenho e o estabelecimento dos usuários responsáveis pela conclusão de cada tarefa, pode ser feita uma simulação, onde se pode testar se as regras pré-estabelecidas estão de acordo com o objetivo da empresa e se as tarefas estão sendo encaminhadas para as pessoas corretas. A execução do processo ocorre após as etapas anteriores já terem sido realizadas. O BPMS utilizado faz com que as tarefas sejam enviadas para os seus devidos responsáveis, controlando o seu tempo de execução por pessoa e pelo processo em geral. Podem ser utilizadas também regras de negócio (Business Rules) pré-estabelecidas. O controle ideal de BPM é aquele que está presente durante todas as etapas do processo: antes, durante e depois. Desde o início da modelagem até a análise pós-conclusão da execução, o controle deve ser realizado. Um tipo de controle que existe em alguns BPMS são relatórios de fluxos em andamento, onde é fornecido o status do fluxo, com quem está parado, há quanto tempo está parado, etc. Isso é importante para evitar que os erros sejam encontrados somente quando o processo é concluído. Há também relatórios de fluxos concluídos, onde se pode ter uma noção geral de como se desenvolveu o processo. Alguns softwares apresentam gráficos e relatórios com bastantes detalhes dos processos. A otimização tem crucial importância quando se trata de BPM. É essencial para que sejam feitas melhorias nos processos de modo a alcançar resultados positivos mais rapidamente, melhorando o serviço aos clientes e, possivelmente, com menores custos. Depende, obviamente, das etapas anteriores, principalmente do controle, onde deve haver uma busca pela perfeição.5
2.2.2
Fluxograma Diagrama que descreve a sequência de atividades de um processo empresarial através de uma simbologia padronizada, utilizando retângulos para representar atividades, losangos para pontos de decisão e setas para indicar o fluxo. Estes simbolos vêm acompanhado de textos explicativos. Fácil de utilizar, mas pouco apropriado para representar processos de grande complexidade e divergências. O fluxograma considera o processo do ponto de vista da empresa.
2.2.3
Service blueprint Técnica de mapeamenteo de serviços derivado do fluxograma que considera o aspecto de interação com o cliente. É um mapa de todas as transações que constituem o processo de entrega do serviço. Divide-se em duas regiões separadas por uma linha, chamada de linha de visibilidade. Na parte de cima da linha, é a área de evidências físicas percebida pelo cliente, as suas ações e interações com os empregados. Na parte de baixo, encontram-se as ações dos empregados e os processos de suporte que são invisíveis para o cliente. As evidências físicas, mostradas na parte de cima, identificam elementos que o cliente pode usar como indicador da qualidade do serviço. Cada conexão vertical através da linha de interação indica um ponto
5
http://pt.wikipedia.org/wiki/Gest%C3%A3o_de_processos_de_neg%C3%B3cio
20
TI para concursos
de contato. Estes pontos funcionam como o “momento da verdade” de cada serviço e podem ser usados como pontos de potencial falhas no sistema de serviço.
Fonte: http://www.lgti.ufsc.br/public/luciano.pdf Apesar de ser mais evoluido do que os fluxogramas, também não consegue representar uma descrição completa da experiência com o cliente. O foco está na tarefa e não no cliente.
2.2.4
Mapa do serviço Forma visual de três elementos críticos de serviços: processso de entrega de serviço, os papéis dos clientes e empregados e elementos visíveis de serviço. A criação do mapa requer a identificação de evidências físicas do serviço, indicadores de qualidade, as pessoas envolvidas e o fluxo operacional de atividades de entrega de serviços. Foca os serviços do ponto de vista do consumidor. É uma evolução do service blueprint. Logo acima da linha de visibilidade, há uma linha horizontal que indica o contato do cliente com os empregados de atendimento. Abaixo da linha de visibilidade há outra que indica a relação entre o suporte e o processso de entrega de serviço. Mais abaixo, outra linha separa a gerência do suporte.
O mapa pode ser lido horizontalmente para entender as ações ou passos realizados pelos clientes e empregados, ou lido verticalmente para compreender as ações de suporte, os processos e estruturas.
2.2.5
IDEF Família de métodos de estruturar e analisar uma empresa. Utilizam-se de diagramas para representar os processos.
21
TI para concursos
Cada tarefa é representada por um retângulo. Cada lado representa uma informação de entrada, saída de produtos e/ou informações, recursos disponíveis e condições para ativação. A ênfase não está na sequência, mas no conteúdo das atividades e nos recursos envolvidos no processo. Exemplo: Controle
Entradas
Processo
Saídas
Mecanismo
2.2.5.1
IDEF0 Método de modelagem funcional usado para processos associados a decisões, ações e atividades.
2.2.5.2
IDEF1 Método de modelagem de informação, para expressão dos requisitos de um sistema.
2.2.5.3
IDEF3 Método de captura da descrição do processo, que relaciona causa e efeito entre processos.
2.2.5.4
IDEF4 Método de desenho orientado a objeto, que auxilia no projeto de sistemas orientados a objetos.
2.2.5.5
IDEF5 Método de identificação de ontologias associadas aos processos e informações.
2.2.5.6
IDEF9 Método para auxiliar na identificação de restrições associadas a um sistema ou processo.
2.2.6
Estrutura de processamento de clientes Modelo genérico de atividades-chave que são comuns à maioria dos processos de serviços. Visa especificamente o fluxo de clientes, indicando apenas atividades com eles. São identificadas sete atividades-chave: seleção, cliente decide a escolha ponto de entrada, contato com a operação escolhida tempo de resposta, tempo de espera para que o sistema responda ponto de impacto, cliente é atendido prestação de serviço, o serviço é prestado ponto de partida, o cliente sai do processo acompanhamento, atividades sobre o cliente após a conclusão do serviço
2.2.7
Walk-through-audit Método de auditoria, que consiste em uma série de questões dirigidas aos clientes, e gerentes de serviços, para avaliação sistemática da visão do cliente sobre o serviço prestado. Utilizam-se questões estruturadas que avaliam cada etapa do processo em uma escala de um a cinco, respondidas durante ou imediatamente após o serviço, ou aplicadas em clientes da concorrência.
22
TI para concursos
Além de avaliar a percepção do cliente, também permite analisar a lacuna entre a opinião do cliente e da gerência e entre a empresa e a concorrência. Funciona em conjunto com alguma outra técnica gráfica.
2.2.8
Análise da transação de serviço (STA – Service Transaction Analysis) Método de avaliação do processo do ponto de vista do cliente, combinando quatro elementos: o conceito do serviço, o processo do serviço, a avaliação da qualidade em cada transação e a interpretação do serviço pelo cliente. Utiliza um formulário denominado “folha de análise da transação de serviço”. Pessoas fazendo papel de clientes caminham ao longo do processo para analisar como o cliente poderia avaliar cada transação, usando uma mensagem curta e uma escala de três pontos: (-) insatisfeito, (0) satisfeito ou (+) muito satisfeito.
2.3
23
Exercícios 23.
(ICMS-SP 2009) No diagrama de fluxos de negócio (BPMN), para estabelecer "quem faz o que" devem ser 23 representados os fluxos de negócio agrupados em (a) processes e tasks. (b) events e gateways. xx (c) pools e lanes. (d) pools e processes. (e) lanes e tasks.
24.
(ICMS-SP 2009) Na modelagem de processos de negócio (BPMN), NÃO se aplica um End Event no tipo de 24 trigger (a) Exception. (b) Link. (c) Message. (d) Multiple. xx (e) Timer.
TI para concursos
25.
24
(ICMS-SP 2009) Na modelagem de processos de negócio (BPMN), os Fluxos de Mensagem devem ser 25 desenhados (a) entre white boxes. xx (b) entre black boxes. (c) entre tasks. (d) dentro de tasks. (e) dentro de black boxes.
TI para concursos
3
Gerência de Serviços de TI
A administração moderna de tecnologia de informação busca fundamentos em boas práticas de gerenciamento alinhadas com objetivos do negócio. Prática é uma maneira de trabalhar. Melhores práticas são atividades ou processos que tenham sido utilizados com sucesso. O conceito de Governança Tecnológica, do termo em inglês IT Governance, define que a TI é um fator essencial para a gestão financeira e estratégica de uma organização. Governança Tecnológica é a metodologia (e seus processos integrados) de gestão corporativa dos recursos de TI.6 A governança de TI trata da integração e uso de processos corporativos suportados pelos pacotes de gestão, por exemplo: BI (Business Intelligence), CRM (Customer Relationship Management), ERP (Enterprise Resource Planning) e SCM (Supply Chain Management). De acordo com a ISO/IEC 38500, são seis princípios para governança de TI:7 Responsabilidade – papéis e responsabilidades bem definidos na entrega de TI aos clientes e na sua aquisição, e garantia de autoridade compatível para o exercício desses papéis. Estratégia – O desenvolvimento da estratégia de negócio considera a as capacidades atuais e futuras de TI e o planejamento de TI busca atender às necessidades atuais e continuadas do negócio da organização (alinhamento). Aquisições – As aquisições de TI são adequadamente motivadas por meio de análises apropriadas e continuadas e de decisões claras e transparentes, de modo a garantir o alcance de equilíbrio adequado entre benefícios, oportunidades, custos e riscos, tanto no curto como no longo prazo. Desempenho – A TI é estruturada para suportar adequadamente a organização e dispor serviços com os níveis e com a qualidade necessários para responder aos requisitos atuais e futuros do negócio. Conformidade – A TI está em conformidade com a legislação e regulamentos aplicáveis. As políticas e as práticas estão claramente definidas, encontram-se implementadas e são aplicadas. Comportamento Humano – As políticas, práticas e decisões relativas ao uso e gestão da TI consideram e respeitam o comportamento humano e incluem as necessidades atuais e a evolução das necessidades de todas as pessoas envolvidas no processo. ITIL é um framework, ou uma estrutura de gerência de serviços de TI. Em sua versão 2, o foco era a própria prestação de serviços. Na versão 3, o ITIL mudou seu foco para a o alinhamento dos objetivos de serviços de TI com os do negócio, mudando da abordagem operacional para uma visão mais estratégica do uso da tecnologia. O COBIT é um guia de boas práticas para a gestão de tecnologia, não apenas serviços.
6
http://www.trainning.com.br/download/Apostila_ITIL_Cobit.pdf
7
http://www.geraldoloureiro.com/wiki/images/9/98/WGov_Palestra_ClaudioCruz.pdf
25
TI para concursos
3.1
Fundamentos da ITIL V2 Estrutura abstrata (framework) de serviços de TI. Orienta o “como fazer” das funções do gerente de tecnologia, dividindo estes serviços em dois grandes grupos – suporte a serviços e entrega de serviços – unidos por uma central de atendimento (service desk).
3.1.1
Suporte a serviços O suporte a serviços tem foco nos usuários da instituição, administrando incidentes, suas origens (problema) e definindo formas de tratamento e de alterações necessárias para resolução.
3.1.1.1
Central de serviços (service desk) Suporte de primeiro nível. Atendimento ao usuário.
3.1.1.2
Gerenciamento de incidentes (apaga incêndio) Restaurar o serviço o mais rápido possível, para minimizar o impacto nos negócios e para garantir o melhor nível de serviço, no tocante qualidade e disponibilidade. Um incidente é um evento que não faz parte da operação padrão do serviço e que causa, ou poderá causar uma interrupção, ou uma redução na qualidade do serviço.
3.1.1.3
Gerenciamento de problemas (desenvolvimento de soluções) Buscar a causa raiz do incidente e sua conseqüente solução e prevenção. Um Problema é um erro de causa desconhecida que pode causar um ou mais incidentes. Um Problema poderá ser um Erro Conhecido (Known Error) quando a causa raiz (root cause) tornar conhecida e uma Solução de Contorno (work-around) ou permanente for identificada e aplicada. As soluções são registradas na gerência de configuração e as mudanças necessárias são requisitadas à gerência de mudanças.
3.1.1.4
Gerenciamento de mudanças (implementação) A partir de requisições de mudanças dos usuários ou do gerenciamento de problemas, implementa mudanças aprovadas, de maneira eficiente, em um custo efetivo, com um mínimo risco à infra-estrutura de TI existente e à nova.
3.1.1.5
Gerenciamento de liberação (implantação) Libera e distribui a alteração autorizada. Implanta.
26
TI para concursos
3.1.1.6
Gerenciamento de configuração (controle da infra-estrutura) Gerenciar o banco de dados de todos os componentes necessários para fornecer serviços
3.1.2
Entrega de Serviço A entrega de serviços volta-se para o cliente, preocupando-se em garantir uma qualidade ótima em função da estratégia do negócio, além da efetividade do serviço prestado como resultado de uma gestão de recursos tecnológicos (ativos) e financeiros.
3.1.2.1
Gerenciamento de nivel de serviço A partir de um acordo do nível de serviço entre a TI e os usuários, contendo os requisitos do usuário, gerencia a qualidade dos serviços oferecidos, procurando a maior qualidade em consonância com o negócio da empresa.
3.1.2.2
Gerenciamento financeiro Como JUSTIFICAR o orçamento? Necessidades da TI para o negócio planejados a partir dos processos (Mudança, Nível, Capacidade e Disponibilidade) compõe o orçamento e acompanhamento financeiro.
3.1.2.3
Gerenciamento de disponibilidade Análise de riscos, oportunidades, satisfação, produtividade e tempo de manutenção e indisponibilidade.
3.1.2.4
Gerenciamento de capacidade Confronto entre capacidade, demanda e satisfação do cliente. Taxa de utilização de recursos humanos e sistemas.
3.1.2.5
Gerenciamento de continuidade de serviços de TI Todo o esforço possível para evitar interrupções. Implementação de medidas preventivas, testes para operar em ambientes de crise, redução do impacto dos incidentes, seguros.
27
TI para concursos
3.2
Fundamentos de ITIL V38 O núcleo do ITIL V3 é composto de cinco processos baseados no ciclo de vida dos serviços: Estratégia do serviço (Service Strategy) Projeto de serviço ou Desenho de serviço (Service Design) Transição do serviço (Service Transition) Operação do serviço (Service Operation) Melhoria contínua do serviço (Continual Service Improvement)
Ilustração 4 Ciclo de vida do serviço - Núcleo do ITIL V3
3.2.1
Estratégia do serviço (Service Strategy) Como ponto de origem do ciclo de vida de serviço ITIL, estratégia do serviço orienta sobre como tornar mais claro e priorizar investimentos sobre provimento de serviços, desenhar, desenvolver e implementar o gerenciamento de serviços. Processos: geração de estratégia, gerenciamento de portfólio de serviços, gerenciamento de demandas, gerenciamento financeiro de TI.
3.2.2
Desenho de serviço (Service Design) O desenho de serviço fornece orientações para o desenvolvimento de serviços e processos de gerenciamento de serviços, incluindo mudanças e melhorias para aumentar ou manter o valor, para a continuidade dos serviços, para o atingimento de níveis de serviço e para a conformidade às normas. O trabalho de projetar um serviço de TI é agregado em pacote de projeto de serviços (Service Design Package - SDP). Processos de gerenciamento de: nível de serviço (Service Level Management - SLM) disponibilidade
8
http://pt.wikipedia.org/wiki/ITILv3
28
TI para concursos
3.2.3
capacidade continuidade de serviços segurança da informação fornecedores catálogo de serviços.
Transição do serviço (Service Transition) Este volume é direcionado à entrega dos serviços necessários ao negócio no uso operacional, e geralmente englobam o "projeto". Processos: Planejamento de transição e suporte Avaliação Teste e validação Gerenciamento de configurações e ativos de serviço Gerenciamento de liberação e implantação (release and deployment) Gerenciamento de mudança (Change Management) Gerenciamento de conhecimento
3.2.4
Operação do serviço (Service Operation) Parte do ciclo de vida onde serviços e valor são entregues diretamente. Assim, monitoramento de problema e balanceamento entre disponibilidade de serviço e custo são considerados. Processos: Cumprimento de requisição. Gerenciamento de eventos. Gerenciamento de incidentes. Gerenciamento de problemas. Gerenciamento de acesso, (service desk). Funções: Central de serviços Gerenciamento técnico Gerenciamento de aplicativos Gerenciamento de operações de TI
3.2.5
Melhoria de serviço continuada (Continual Service Improvement) A meta do CSI é ajustar e reajustar serviços de TI às mudanças contínuas do negócio através da identificação e implementação de melhorias aos serviços de TI que apoiam processos negociais. Utiliza um sistema cíclico de revisão baseado no modelo PDCA (Plan Do, Check and Act). Processos: Medição de serviço Relato de serviço Sete passos de melhoria
3.3
Fundamentos de COBIT O COBIT – Control Objectives for Information and Related Technology, tem por missão explícita pesquisar, desenvolver, publicar e promover um conjunto atualizado de padrões internacionais de boas práticas referentes ao uso corporativo da TI para os gerentes e auditores de tecnologia. A metodologia COBIT foi criada pelo ISACA – Information Systems Audit and Control Association através do IT Governance Institute, organização independente que desenvolveu a metodologia considerada a base da governança tecnológica. O COBIT funciona como uma entidade de padronização e estabelece métodos documentados para nortear a área de tecnologia das empresas, incluindo qualidade de software, níveis de maturidade e segurança da informação.
29
TI para concursos
Os documentos do COBIT definem Governança Tecnológica como sendo uma estrutura de relacionamentos entre processos para direcionar e controlar uma empresa de modo a atingir objetivos corporativos, através da agregação de valor e risco controlado pelo uso da tecnologia da informação e de seus processos”. COBIT é um guia de boas práticas, que podem servir como um modelo de referência para gestão da TI. Inclui um sumário executivo, um "framework", controle de objetivos, mapas de auditoria, ferramentas para a sua implementação e um guia com técnicas de gerenciamento. Os domínios do COBIT são integrados da seguinte forma: A informação de uma empresa é gerada/modificada pelas atividades de TI. Esta informação é requisito para o domínio de Planejamento e Organização (PO). Os requisitos de saída do PO são requisitos de entrada de informação para o domínio de Aquisição e Implementação (AI), As saídas de AI definem os requisitos de entrada para o domínio de Entrega e Suporte (DS). O domínio de Monitoração (M) utiliza as informações do DS nos seus processos e atividades relacionadas. Os requisitos da informação são dados por: efetividade, eficiência, confidencialidade, integridade, disponibilidade, conformidade e confiabilidade. Os recursos de TI são classificados como: pessoas, sistemas aplicativos, tecnologia, infraestrutura e dados. COBIT cobre os quatro domínios, os quais possuem 34 processos (dois objetivos de controle para cada processo).
3.3.1
Planejar e Organizar Uso de informação e tecnologia e como isso pode ser usado para que a empresa atinja seus objetivos e metas. A forma organizacional e a infra-estrutura da TI deve ser considerada. PO1 Definir um Plano Estratégico de TI e Orientações PO2 Definir a Arquitetura de Informação PO3 Determinar o Gerenciamento Tecnológico PO4 Definir os Processos de TI, Organização e Relacionamentos PO5 Gerenciar o Investimento em TI PO6 Comunicar os Objetivos de Gerenciamento e Orientar PO7 Gerenciar os Recusos Humanos de TI PO8 Gerenciar a Qualidade PO9 Estimar e Gerenciar os Riscos de TI PO10 Gerenciar Projetos
3.3.2
Adquirir e Implementar Requisitos de TI, aquisição de tecnologia e implementação dentro dos processos de negócios da companhia. Desenvolvimento do plano de manutenção que a companhia adota para prolongar a vida do sistema de TI e seus componentes. AI1 Identificar Soluções Automatizadas AI2 Adquirir e Manter Software de Aplicação AI3 Adquirir e Manter Infraestrutura de Tecnologia AI4 Habilitar Operação e Uso AI5 Obter Recursos de TI AI6 Gerenciar Mudanças AI7 Instalar e Credenciar Soluções e Mudanças
3.3.3
Entregar e Dar Suporte Entrega de tecnologia da informação. Cobre a execução de aplicações dentro do sistema de TI e seus resultados, assim como o suporte dos processos, que incluem questões de segurança e treinamento e habilitam a execução.
30
TI para concursos
3.3.4
DS1 DS2 DS3 DS4 DS5 DS6 DS7 DS8 DS9 DS10 DS11 DS12 DS13
Definir e Gerenciar Níveis de Serviço Gerenciar Serviços de Terceiros Gerenciar Performance e Capacidade Assegurar Serviço Contínuo Assegurar Segurança de Sistema Identificar e Alocar Recursos Treinar Usuários Gerenciar Serviços de Escritório e Incidentes Gerenciar a Configuração Gerenciar Problemas Gerenciar Dados Gerenciar o Ambiente Físico Gerenciar Operações
Monitorar e Avaliar Estimativa estratégica das necessidades da companhia. Avalia se o atual sistema de TI atinge os objetivos para o qual ele foi especificado e controla os requisitos para atender objetivos regulatórios. Estimativa e capacidade de atingir os objetivos de negócio, controlando os processos internos da companhia através de auditores internos e externos. M1 Monitorar os processos M2 Assegurar avaliação dos controles internos M3 Obter avaliação independente M4 Prover auditoria independente
3.4
31
Exercícios 26.
(ICMS-SP 2009) NÃO se trata de elemento que deve ser considerado como parte do controle de mudanças 26 no gerenciamento de configuração: xx (a) revisões e auditoria das mudanças. (b) confiabilidade das instalações das modificações. (c) análise de impacto de mudanças. (d) conjunto de modificações. (e) pedido de modificações.
27.
(ICMS-SP 2009) A rastreabilidade ou a história das mudanças de cada software, incluindo quem fez o que, por que e quando, pode ser realizada no gerenciamento de configuração de software por meio do seu 27 componente: (a) Acordo de nível de serviço. (b) Configuração da construção. (c) Identificação do item de software. xx (d) Controle de versão. (e) Controle de mudanças.
28.
(ICMS-SP 2009) Os objetivos de controle detalhados do COBIT estão diretamente associados (a) aos domínios de governança. (b) aos processos de TI. xx (c) às atividades de TI. (d) aos recursos de TI. (e) aos critérios de informação.
29.
(ICMS-SP 2009) O processo Gerenciamento de Configurações está definido no COBIT dentro do domínio (a) Monitoração & Avaliação. (b) Verificação & Controle. (c) Aquisição & Implementação. (d) Planejamento & Organização. xx (e) Entrega & Suporte.
30.
(ICMS-SP 2009) NÃO se trata de um princípio de governança de TI: (a) Responsabilidade corporativa. xx (b) Objetivos do negócio. (c) Prestação de contas. (d) Transparência. (e) Equidade.
28
30
29
TI para concursos
32
31
31.
Gerenciar Projetos, segundo o COBIT, é um processo de TI pertencente ao domínio de xx (a) Planejamento e Organização. (b) Planejamento e Controle. (c) Aquisição e Implementação. (d) Entrega e Suporte. (e) Monitoração e Controle.
32.
(ICMS-SP 2009) No gerenciamento de serviços de TI, segundo o ITIL v.2, tem foco operacional o processo: xx (a) configuration management. (b) capacity management. (c) availability management. (d) service level management. (e) customer relationship management.
33.
(ICMS-SP 2009) No gerenciamento de serviços de TI, segundo o ITIL v.2, tem foco tático ou estratégico o 33 processo: (a) problem management. (b) incident management. (c) release management. xx (d) continuity management. (e) change management.
34.
(ICMS-SP 2009) O processo de gerenciamento de serviços Service Desk, segundo o ITIL v.2, NÃO 34 gerencia (a) os contatos entre o provedor de serviços e os usuários. (b) a comunicação com os usuários. (c) os incidentes nos serviços. xx (d) os acordos de serviços. (e) as requisições de serviços.
35.
O processo de Gerenciamento de Problemas, segundo o ITIL, deve ser executado no estágio do ciclo de vida 35 de serviços denominado (a) estratégia de serviços. (b) projeto de serviços. (c) transição de serviços. xx (d) operação de serviços. (e) melhoria contínua de serviços.
32
TI para concursos
4
Engenharia de Software Engenharias da sistemas é um campo interdisciplinar da engenharia que foca no desenvolvimento e organização de sistemas artificiais complexos. As técnicas de Engenharia de Sistemas podem ser utilizadas em desenvolvimento de softwares. Engenharia de produção é o ramo da engenharia que dedica-se à concepção, melhoria e implementação de sistemas que envolvem pessoas, materiais, informações, equipamentos, energia e maior de conhecimentos e habilidades, para especificar, prever e avaliar os resultados obtidos por tais sistemas. A Engenharia de processos é um ramo da engenharia que se preocupa, entre outras coisas, em elaborar e executar projetos e estudos de formas de aproveitamento de mão-de-obra, máquinas e equipamentos, para melhorar processos, para o aumento da qualidade do produto, redução de perdas e maior produtividade. Neste contexto, a engenharia de software aproveita diversas técnicas de engenharia de sistemas, de produto e de processos para a produção de aplicativos com maior eficiência e eficácia. Nos anos 40, grande parte dos esforços e custos era concentrada no desenvolvimento do hardware. À medida que a tecnologia de hardware foi sendo dominada, as preocupações se voltaram, no início dos anos 50, para o desenvolvimento dos sistemas operacionais e de linguagens de programação de alto nível, como FORTRAN e COBOL. No início dos anos 60, com o surgimento dos sistemas operacionais com características de multiprogramação, a eficiência e utilidade dos sistemas computacionais tiveram um considerável crescimento, surgindo a necessidade de desenvolver grandes sistemas de software em substituição aos pequenos programas aplicativos utilizados até então. Desta necessidade, surgiu um problema chamado de “crise do software”, que permitiu o nascimento do termo “Engenharia de Software”. Atualmente, o custo de desenvolvimento de software corresponde a uma percentagem cada vez maior no custo global de um sistema informatizado. A principal razão para isto é que a tecnologia de desenvolvimento de software implica em grande carga de trabalho, envolvendo muitas pessoas num prazo relativamente longo de desenvolvimento.
4.1
Software9 Software é um conjunto de instruções, estruturas de dados e documentação destinados a resolver um problema. Em Engenharia de Software, o software deve ser visto como um produto a ser “vendido”. Em sistemas simples, onde o usuário é o próprio autor, a documentação é pequena ou inexistente e a preocupação com a existência de erros de execução não é um fator muito relevante, pode não haver grandes dificuldades na detecção e correção de falhas, nem preocupação como a portabilidade, a flexibilidade e a possibilidade de reutilização. Um produto de software é destinado ao uso por pessoas outras que os seus programadores, a sua interface é importante, reforçada com uma documentação rica em informações para que todos os recursos oferecidos possam ser explorados de forma eficiente. Produtos de software devem passar normalmente por uma exaustiva bateria de testes, dado que os usuários não estarão de detectar e corrigir os eventuais erros de execução. o software é concebido e desenvolvido como resultado de um trabalho de engenharia e não manufaturado no sentido clássico; o software não se desgasta, não aumenta a possibilidade de falhas à medida que o tempo passa; a maioria dos produtos de software é concebida inteiramente sob medida, sem a utilização de componentes pré-existentes. Em função destas características diferenciais, o processo de desenvolvimento de software pode desembocar um conjunto de problemas, os quais terão influência direta na qualidade do produto. O processo de desenvolvimento de software procura responder:
9
http://jalvesnicacio.files.wordpress.com/2010/03/engenharia-de-software.pdf
33
TI para concursos
4.2
por que o software demora tanto para ser concluído? por que os custos de produção têm sido tão elevados? por que não é possível detectar todos os erros antes que o software seja entregue ao cliente? por que é tão difícil medir o progresso durante o processo de desenvolvimento de software?
Ciclo de vida do software O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até ficar sem uso algum.10 Quatro fases que são delimitadas por eventos típicos em diversos ciclos de vida. Cada fase inclui um conjunto de atividades ou disciplinas que devem ser realizadas pelas partes envolvidas. Definição Desenvolvimento Operação Retirada
4.2.1
Fase de Definição A fase de definição do software ocorre em conjunto com outras atividades como a modelagem de processos de negócios e análise de sistemas. Nesta atividade, diversos profissionais buscam o conhecimento da situação atual e a identificação de problemas para que possam elaborar propostas de solução de sistemas computacionais que resolvam tais problemas. Dentre as propostas apresentadas, deve-se fazer um estudo de viabilidade, incluindo análise custo-benefício, para se decidir qual solução será a escolhida. O resultado desta atividade deve incluir a decisão da aquisição ou desenvolvimento do sistema, indicando informações sobre hardware, software, pessoal, procedimentos, informação e documentação. Caso seja decidido pelo desenvolvimento do sistema, no escopo da engenharia de software, é necessário elaborar o documento de proposta de desenvolvimento de software. Esse documento pode ser a base de um contrato de desenvolvimento. Profissionais de engenharia de software atuam nesta atividade com o objetivo de identificar os requisitos de software e modelos de domínio que serão utilizados na fase de desenvolvimento. Os requisitos são também fundamentais para que o engenheiro possa elaborar um plano de desenvolvimento de software, indicando em detalhes os recursos necessários (humanos e materiais), bem como as estimativas de prazos e custos (cronograma e orçamento). Não existe um consenso sobre o que caracteriza o final da fase de definição. Isto varia de acordo com o modelo de processo adotado. Em algumas propostas, a fase de definição é considerada concluída com a apresentação da proposta de desenvolvimento apenas. Outros modelos de processo, considera que o software apenas está completamente definido com a especificação de requisitos e com a elaboração do plano de desenvolvimento de software. De acordo com o modelo de processo adotado, pode-se iniciar atividades da fase de desenvolvimento mesmo que a fase de definição não esteja completamente concluída.
4.2.2
Fase de Desenvolvimento A fase de desenvolvimento ou de produção do software inclui todas as atividades que tem por objetivo a construção do produto. Ela inclui principalmente o design, a implementação e a verificação e validação do software.
4.2.2.1
Design A atividade de design compreende todo o esforço de concepção e modelagem que têm por objetivo descrever como o software será implementado. O design inclui: Design conceitual Design da interface de usuário Design da arquitetura do software Design dos algoritmos e estruturas de dados
10
http://engenhariadesoftware.blogspot.com/2007/02/ciclo-de-vida-do-software-parte-1.html
34
TI para concursos
O design conceitual envolve a elaboração das idéias e conceitos básicos que determinam os elementos fundamentais do software em questão. Por exemplo, um software de correio eletrônico tradicional inclui os conceitos: mensagem, caixa de entrada, caixa de saída, etc. A mensagem, por sua vez, inclui os conceitos de para, cc, bcc, assunto, corpo, etc. Embora seja um design adotado pela maioria dos software, novos modelos conceituais podem vir a ser adotados. O conceito de conversação do Gmail é um exemplo. O design conceitual exerce influência na interface de usuário e na arquitetura do software. O design da interface de usuário envolve a elaboração da maneira como o usuário pode interagir para realizar suas tarefas, a escolha dos objetos de interfaces (botões, menus, caixas de texto, etc.), o layout de janelas e telas, etc. A interface deve garantir a boa usabilidade do software e é um fundamental fator de sucesso do software. O design de arquitetura de software deve elaborar uma visão macroscópica do software em termos de componentes que interagem entre si. O conceito de componente em arquitetura varia de acordo com a visão arquitetônica adotada. São exemplos de visões arquitetônicas, a visão conceitual, visão de módulos, visão de código e visão de execução. Na visão conceitual, os componentes de software são derivados do design conceitual. Estes componentes são abstrações que devem definir outros elementos menos abstratos. Exemplos são arquiteturas cliente-servidor e arquitetura em camadas. Na visão de código, deve-se determinar como as classes e/ou funções estão organizadas e interagindo entre si. Estas classes implementam os componentes abstratos ou conceituais. Na visão de módulos, deve-se determinar quais são os módulos que serão utilizados na implementação e como eles organizam as classes e/ou funções. Na visão de execução, a arquitetura deve descrever os diferentes processos que são ativados durante a execução do software e como eles interagem entre si. Enquanto as anteriores oferecem uma visão estática, esta é uma visão dinâmica do software. O design de algoritmos e estrutura de dados, também conhecido como design detalhado, visa determinar, de maneira independente da linguagem de programação adotada, as soluções algorítmicas e as estruturas de dados associados. Deve-se decidir, por exemplo, como as informações podem ser ordenadas (algoritmo de bolha ou quicksort) e em qual tipo de estrutura de dados (array, lista encadeada) elas vão ser armazenados. 4.2.2.2
Implementação A implementação envolve as atividades de codificação, compilação, integração e testes. A codificação visa traduzir o design num programa, utilizando linguagens e ferramentas adequadas. A codificação deve refletir a estrutura e o comportamento descrito no design. Os componentes arquiteturais devem ser codificados de forma independente e depois integrados. Os testes podem ser iniciados durante a fase de implementação. A depuração de erros ocorre durante a programação utilizando algumas técnicas e ferramentas. É fundamental um controle e gerenciamento de versões para que se tenha um controle correto de tudo o que está sendo codificado.
4.2.2.3
Verificação e validação Verificação e validação destinam-se a mostrar que o sistema está de acordo com a especificação e que ele atende às expectativas de clientes e usuários. A validação visa assegurar se o programa está fazendo aquilo que foi definido na sua especificação (fazendo a coisa certa). A verificação visa verificar se o programa está correto, isto é, não possui erros de execução (fazendo certo a coisa). Existem diferentes formas de verificação e validação. Inspeção analítica e revisão de modelos, documentos e código fonte são formas que podem ser usadas antes mesmo que o programa seja completamente codificado. Os testes de correção, desempenho, confiabilidade, robustez, usabilidade, dentre outros, visam avaliar diversos fatores de qualidade a partir da execução do software. Diferentes técnicas de testes podem ser aplicadas para cada um destes fatores.
4.2.3
Fase de Operação A fase de operação envolve diferentes tipos de atividades: Distribuição e entrega Instalação e configuração Utilização Manutenção
35
TI para concursos
A distribuição e entrega pode ser feita diretamente pelo desenvolvedor (em caso de software personalizado), ou em um pacote a ser vendido em prateleiras de lojas ou para ser baixado pela Internet (em caso de software genéricos). O processo de instalação e configuração, normalmente, pode ser feito com a ajuda de software de instalação disponibilizados pelos fabricantes dos ambientes operacionais. A atividade de utilização é o objeto do desenvolvimento do software. A qualidade da utilização é a usabilidade do software. A manutenção normalmente ocorre de duas formas: corretiva e evolutiva. A manutenção corretiva visa a resolução de problemas referentes a qualidade do software (falhas, baixo desempenho, baixa usabilidade, falta de confiabilidade etc.). A manutenção evolutiva ou adaptativa visa a produção de novas versões do software de forma a atender a novos requisitos dos clientes, ou adaptar-se às novas tecnologias que surgem (hardware, plataformas operacionais, linguagens, etc). Mudanças no domínio de aplicação implicam em novos requisitos e incorporação de novas funcionalidades. Surgimento de novas tecnologias de software e hardware e mudanças para uma plataforma mais avançada também requerem evolução.
4.2.4
Fase de retirada A fase retirada é um grande desafio para os tempos atuais. Diversos software que estão em funcionamento em empresas possuem excelente níveis de confiabilidade e de correção. No entanto, eles precisam evoluir para novas plataformas operacionais ou para a incorporação de novos requisitos. A retirada desses software legados em uma empresa é sempre uma decisão difícil: como abrir mão daquilo que é confiável e ao qual os funcionários estão acostumados, após anos de treinamento e utilização? Processos de reengenharia podem ser aplicados para viabilizar a transição ou migração de um software legado para um novo software de forma a proporcionar uma retirada mais suave.
4.3
Metodologias de desenvolvimento de software.
4.3.1
Modelo caótico11 O produto é construído sem qualquer especificação ou projeto. O produto é retrabalhado quantas vezes forem necessárias para satisfazer o cliente. Este modelo pode funcionar razoavelmente para micro projetos (até 400 homens.hora). No entanto para projetos maiores ele é inadequado.
4.3.2
Modelo Cascata Recomendado para sistemas onde a segurança e a confiabilidade tem grande importância. Orientado para documentação, que abrange representações gráficas e simulações, e com uma abordagem disciplinada, a cada fase são feitos procedimentos de verificação e validação (incluindo testes), são liberadas definições da documentação e todos produtos são formalmente revisados. Uma vez definido o modelo de ciclo de desenvolvimento, existem três abordagens para implementá-lo Cascata Pura Incremental Evolucionária
4.3.2.1
Abordagem Cascata Pura Todas as fases do ciclo de desenvolvimento são executadas em sequência. As fases anteriores são revisitadas para correções de erros ou para adaptações. Esta abordagem é adequada quando : existe um conjunto de Requisitos do Usuário estáveis e de alta qualidade a duração do projeto é pequena o sistema completo deve estar disponível de um única vez
11
http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado.html
36
TI para concursos
4.3.2.2
Abordagem Incremental Nesta abordagem o desenvolvedor executa múltiplas fases de PD, TR e OM. Dentro desta abordagem está a abordagem cascata. A abordagem incremental é adequada quando: a liberação do software deve estar de acordo com um conjunto de prioridades definidas nos Requisitos do Usuário é necessário melhorar a eficiência da integração do software com outra partes de um sistema maior são requeridas antecipadamente evidências de que o produto será aceito
4.3.2.3
RU – Requisitos do usuário RS – Requisitos do software PA – Projeto da arquitetura PD – Projeto detalhado TR – Treinamento OM – Operação e Manutenção
Abordagem Evolucionária Nesta abordagem, o desenvolvimento é formado por múltiplos ciclos da abordagem cascata pura, ocorrendo sobreposição das fases da operação e manutenção do sistema anterior com o novo desenvolvimento. Esta abordagem é adequada quando: é necessário alguma experiência do usuário para refinar e completar requisitos algumas partes da implementação podem depender da existência de tecnologia ainda não disponível existem requisitos do usuário não bem conhecidos alguns requisitos são muito mais difíceis de serem implementados do que outros, decidindo-se não implementá-lo para não atrasar o projeto
4.3.2.4
Modelo Espiral Modelo em cascata onde cada fase é precedida por uma análise de risco e sua execução é feita evolucionariamente (ou incrementalmente). A dimensão radial representa o custo acumulado atualizado e a dimensão angular representa o progresso através da espiral. Cada setor da espiral corresponde a uma tarefa (fase)do desenvolvimento. Um ciclo se inicia com a tarefa "Determinação de objetivos, alternativas e restrições", onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos. Na tarefa "Avaliação de alternativas, identificação e solução de riscos", executa-se uma análise de risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, pode parar o projeto. Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo. Variações do modelo espiral consideram entre três e seis tarefas ou setores da espiral. Por exemplo, as regiões:
37
TI para concursos
4.4
comunicação com o cliente planejamento análise de risco engenharia construção e liberação avaliação do cliente
Desenvolvimento ágil12 Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software. Existem inúmeros frameworks de processos para desenvolvimento de software. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projecto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projecto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projecto. Métodos ágeis enfatizam comunicações em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo ágil deve estar agrupada em uma sala. Isso inclui todas as pessoas necessárias para terminar o software: no mínimo, os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem também se encontrar os testadores, projectistas de iteração, redactores técnicos e gerentes. Métodos ágeis também enfatizam trabalho no software como uma medida primária de progresso. Combinado com a comunicação face-a-face, métodos ágeis produzem pouca documentação em relação a outros métodos, sendo este um dos pontos que podem ser considerados negativos. É recomendada a produção de documentação que realmente será útil. Os princípios do desenvolvimento ágil valorizam: Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais; Softwares funcionais são entregues frequentemente (semanas, ao invés de meses); Softwares funcionais são a principal medida de progresso do projecto; Até mesmo mudanças tardias de escopo no projecto são bem-vindas. Cooperação constante entre pessoas que entendem do negócio e desenvolvedores; Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança. Design do software deve prezar pela excelência técnica; Simplicidade; Rápida adaptação às mudanças; Indivíduos e interações mais do que processos e ferramentas; Software funcional mais do que documentação extensa; Colaboração com clientes mais do que negociação de contratos; Responder a mudanças mais do que seguir um plano. A maioria dos métodos ágeis compartilha a ênfase no Desenvolvimento iterativo e incremental para a construção de versões implantadas do software em curtos períodos de tempo. Métodos ágeis diferem dos métodos iterativos porque seus períodos de tempo são medidos em semanas, ao invés de meses, e a realização é efetuada de uma maneira altamente colaborativa. estendendo-se a tudo. Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata inteiro em cada iteração. Outras equipes, mais especificamente as equipes de Programação extrema, trabalham com atividades simultaneamente.
12
http://pt.wikipedia.org/wiki/Desenvolvimento_Ágil_de_software
38
TI para concursos
A codificação cowboy, também chamada de Modelo Balbúrdia, é a ausência de metodologias de desenvolvimento de Software: os membros da equipe fazem o que eles sentem que é correto. Como os desenvolvedores que utilizam métodos ágeis freqüentemente reavaliam os planos, enfatizam a comunicação face a face e fazem o uso relativamente esparso de documentos, ocasionalmente levam as pessoas a confundirem isto com codificação cowboy. Equipes ágeis, contudo, seguem o processo definido (e freqüentemente de forma disciplinada e rigorosa). Como em todas as metodologias, o conhecimento e a experiência dos usuários definem o grau de sucesso e/ou fracasso de cada atividade. Os controles mais rígidos e sistematizados aplicados em um processo implicam altos níveis de responsabilidade para os usuários. A degradação de procedimentos bem-intencionados e organizados pode levar as atividades a serem caracterizadas como codificação cowboy. De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando três dimensões chaves da organização: cultura, pessoal e comunicação. Em relação a estas áreas inúmeros fatores chave do sucesso podem ser identificados (Cohen et al., 2004):[2] A cultura da organização deve apoiar a negociação. As pessoas devem ser confiantes. Poucas pessoas, mas competentes. A organização deve promover as decisões que os desenvolvedores tomam. A Organização necessita ter um ambiente que facilite a rápida comunicação entre os membros. O fator mais importante é provavelmente o tamanho do projeto. Com o aumento do tamanho, a comunicação face a face se torna mais difícil. Portanto, métodos ágeis são mais adequados para projetos com pequenos times, com no máximo de 20 a 40 pessoas. Ambiente ideal para o desenvolvimento ágil: Baixa criticidade Desenvolvedores senior Mudanças freqüente de requisitos Pequeno número de desenvolvedores Cultura que tem sucesso no caos. Ambiente ideal para o desenvolvimento direcionado ao planejamento: Alta criticidade Desenvolvedores Junior Baixa mudança nos requisitos Grande número de desenvolvedores Cultura que procura a ordem.
4.5
Planejamento e avaliação de iterações Uma iteração é um período de tempo definido dentro de um projeto em que você produz uma versão estável e executável do produto, junto com toda a documentação de apoio, scripts de instalação e similares, necessários para usar a liberação. É também conhecida como ciclo ou tempo definido. A finalidade das iterações é produzir um executável que possa ser avaliado de forma que você possa obter feedback e fazer correções de rumo. Este executável lhe coloca uma etapa mais perto do produto final. As fases fornecem um foco para a equipe chegar a um determinado objetivo da gerência. O OpenUP tem quatro fases, cada uma terminando com respostas a perguntas específicas: Concepção - Nós concordamos com o problema que estamos tentando resolver? Elaboração - Nós concordamos com toda a solução, e compreendemos os riscos, custos e cronograma razoavelmente bem? Construção - Nós concordamos que temos um sistema que atende às principais necessidades dos stakeholders? Transição - Nós concordamos que podemos liberar o sistema e terminar o projeto? Em cada fase, você pode ter uma ou várias iterações, onde cada uma visa produzir os resultados necessários para responder a estas perguntas. Por exemplo, para responder à pergunta da Elaboração, nós necessitamos implementar e testar alguns aspectos chaves do sistema de modo que possamos compreender qual arquitetura é necessária, que componentes comerciais (COTS) necessitaremos, quais os principais riscos que enfrentamos e como direcioná-los, qual a eficácia da
39
TI para concursos
equipe etc. Estas necessidades irão orientar a atribuição das prioridades ao que deve ser feito em uma iteração de Elaboração. Uma das principais vantagens da abordagem iterativa em relação à abordagem em cascata é o fato de as iterações fornecerem marcos naturais para avaliar o progresso e os riscos prováveis. Na iteração, a avaliação do progresso e do risco deverá continuar (se realizada informalmente) para garantir que as dificuldades não desviem o projeto. A Avaliação de Iteração captura o resultado de uma iteração, até que ponto os critérios de avaliação foram respeitados e as mudanças que devem ser feitas. Cada iteração é concluída por uma Avaliação de Iteração, na qual a organização de desenvolvimento para para refletir sobre o que aconteceu, o que foi ou não alcançado e por quê, e as lições aprendidas. Essa avaliação é uma etapa decisiva em uma iteração e não deve ser ignorada. Se a Avaliação de Iteração não for feita corretamente, muitos dos benefícios oferecidos por uma abordagem iterativa poderão se perder. Algumas vezes, o procedimento correto nesta etapa é rever os critérios de avaliação, em vez de retrabalhar o sistema. Às vezes, a vantagem da Avaliação de Iteração está em revelar que um determinado requisito não é importante, é muito caro para ser implementado ou cria uma arquitetura que não pode ser mantida. Nesses casos, uma análise de custo e benefício deve ser feita e uma decisão de negócios deve ser tomada. A métrica deve ser usada como base dessa avaliação. Quase no final de cada iteração, a equipe central do projeto deverá se reunir para avaliar a iteração, enfatizando o seguinte: A iteração obteve êxito no cumprimento de suas metas? Os riscos foram reduzidos ou eliminados? O release cumpriu suas metas de funcionalidade, qualidade, desempenho e capacidade? São necessárias mudanças no projeto e nos planos de iteração futuros? Alguma das descobertas capturadas no artefato, na avaliação da organização de desenvolvimento, foi invalidada pelas mudanças durante a iteração e, como conseqüência, exige mudanças em outros artefatos? Houve alguma dificuldade no processo de desenvolvimento durante a iteração? Que parte do release atual servirá como baseline? Sofrerá retrabalho? Novos riscos foram identificados? Houve mudanças externas (mudanças no mercado, na comunidade de usuários ou nos requisitos)? Avalie os resultados da iteração com relação aos critérios de avaliação que foram estabelecidos para o plano de iteração: funcionalidade, desempenho, capacidade, medidas de qualidade. Use as métricas obtidas nas atividades de teste e no passo coletar métricas como a base da avaliação, quando disponíveis, para quantificá-la. As medidas qualitativas são adequadas para a fase de iniciação e talvez para a iteração inicial, enquanto as fases posteriores de elaboração, construção e transição devem depender de medições de teste específicas para avaliar a qualidade, o desempenho, a capacidade etc. Aborde outros problemas pendentes que foram capturados nas avaliações de status durante a iteração e quaisquer outros problemas na lista de problemas do gerente de projeto. Se todos os riscos tiverem sido reduzidos a níveis aceitáveis, toda a funcionalidade tiver sido implementada e todos os objetivos de qualidade tiverem sido atingidos, o produto estará concluído. O planejamento e a execução eficientes são vitais para isso ocorrer no final da fase de Transição.
4.6
Técnicas de avaliação de software
4.6.1
Análise por Pontos de Função Análise de Pontos de Função (APF) é uma técnica para a medição de projetos de desenvolvimento de software, visando estabelecer uma medida de tamanho, em Pontos de Função (PF), considerando a funcionalidade implementada, sob o ponto de vista do usuário. A medida é independente da linguagem 13 de programação ou da tecnologia que será usada para implementação.
13
http://pt.wikipedia.org/wiki/An%C3%A1lise_de_pontos_de_fun%C3%A7%C3%A3o
40
TI para concursos
Seus objetivos são: medir a funcionalidade solicitada pelo usuário, antes do projeto de software, de forma a estimar seu tamanho e seu custo medir projetos de desenvolvimento e manutenção de software, independentemente da tecnologia utilizada na implementação, de forma a acompanhar sua evolução medir a funcionalidade recebida pelo usuário, após o projeto de software, de forma verificar seu tamanho e seu custo, comparando-os com o que foi originalmente estimado As organizações podem aplicar a Análise de Pontos por Função como: uma ferramenta para determinar o tamanho de pacotes de software adquiridos, através da contagem de todos os Pontos por Função incluídos no pacote uma ferramenta para apoiar a análise da qualidade e da produtividade um mecanismo para estimar custos e recursos envolvidos em projetos de desenvolvimento e manutenção de software um fator de normalização para comparação de software O procedimento para contagem de PFs compreende:14 Determinar o Tipo de Contagem projeto de desenvolvimento aplicações instaladas projetos de manutenção
Identificar o Escopo de Contagem e Fronteira da Aplicação definir a parte do sistema (funcionalidades) a ser contada
Determinar os PFs não ajustados Contagem das Funções dados - arquivos lógicos internos (ALI) e arquivos de interface externa (AIE) transacionais – entradas (EE), saídas (SE) e consultas (CE) externas
Determinar o Fator de Ajuste o fator de ajuste é baseado em quatorze características gerais de sistemas, que avaliam a funcionalidade geral da aplicação que está sendo contada, e seus níveis de influência. O nível de influência de uma característica é determinado com base em uma escala de 0 (nenhuma influência) a 5 (forte influência).
Calcular os PFs Ajustados 4.6.1.1
Contagem das Funções de Dados O primeiro passo para a contagem das funções de dados consiste em identificar arquivos lógicos internos (ALIs) e arquivos de interface externa (AIEs). Cada uma dessas funções de dados deve ser classificada segundo sua complexidade funcional. Essa complexidade é definida com base nos conceitos de registros lógicos e itens de dados. Registros Lógicos são subconjuntos de dados dentro de um ALI/AIE, que foram reconhecidos pelo usuário. Se o usuário não reconhecer subconjuntos de dados em um ALI/AIE, então se deve contar o ALI/AIE como um registro lógico. Um Item de Dados, por sua vez, é um campo reconhecido pelo usuário como único e não repetido. Vale destacar que só devem ser contados os itens de dados utilizados pela aplicação em contagem.
14
http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf
41
TI para concursos
Contando-se os registros lógicos e os itens de dados de um ALI/AIE, pode-se chegar à sua complexidade, utilizando a tabela 1:
4.6.1.2
Número de Itens de Dados Referenciados
Número de Registros Lógicos
1 a 19
20 a 50
51 ou mais
Apenas 1
Simples
Simples
Média
2a5
Simples
Média
Complexa
6 ou mais
Média
Complexa
Complexa
Contagem das Funções Transacionais De maneira análoga à contagem das funções de dados, a contagem das funções transacionais envolve a identificação de funções transacionais (entradas externas, saídas externas e consultas externas) e sua classificação de acordo com a complexidade funcional envolvida (simples, média ou complexa). A definição da complexidade funcional é feita com base no número de arquivos referenciados e dos itens de dados manipulados pela função, utilizando as tabelas 2 para entradas externas e 3 para saídas e consultas externas. Nessas tabelas, um arquivo referenciado pode ser um ALI lido ou mantido pela função transacional, ou um AIE lido pela função transacional. Já o número de itens de dados referenciados é calculado considerando apenas os itens de dados efetivamente referenciados pela função transacional em questão. Tabela 2 para entradas externas: Número de Itens de Dados Referenciados
Número de arquivos referenciados
1a4
5 a 15
16 ou mais
0 ou 1
Simples
Simples
Média
2
Simples
Média
Complexa
3 ou mais
Média
Complexa
Complexa
Tabela 3 para saídas e consultas externas:
4.6.1.3
Número de Itens de Dados Referenciados
Número de arquivos referenciados
1a5
6 a 19
20 ou mais
0 ou 1
Simples
Simples
Média
2 ou 3
Simples
Média
Complexa
4 ou mais
Média
Complexa
Complexa
Cálculo dos Pontos de Função Não Ajustados Uma vez contadas as funções de dados e as funções transacionais, é possível calcular os PFs não ajustados de uma aplicação. Esse cálculo é feito da seguinte forma: 1. Para cada um dos cinco tipos de função (ALI, AIE, EE, SE e CE), são computados os totais de pontos de função (NPFi), segundo a seguinte expressão:
onde NCi,j = número funções do tipo i (i variando de 1 a 5, segundo os tipos de função existentes: ALI, AIE, EE, SE e CE) que foram classificados na complexidade j (j variando de 1 a 3, segundo os valores de complexidade: simples, média e complexa). 42
TI para concursos
Ci,j
= valor da contribuição da complexidade j no cálculo dos pontos da função i, dado pela tabela 4.
Tabela 4 – Contribuição das Funções na Contagem de PFs Não Ajustados. Complexidade Função Simples
Média
Complexa
arquivos lógicos internos - ALI
7
10
16
arquivos de interface externa - AIE
5
7
10
entradas externas - SE
4
5
7
saídas externas - EE
3
4
6
consultas externas - CE
3
4
6
2. O total de pontos de função não ajustados (PFNA) é dado pelo somatório dos pontos das tabelas de função:
sendo que i varia de 1 a 5, segundo os tipos de função existentes (AIL, AIE, EE, SE e CE). 4.6.1.4
Determinação do Fator de Ajuste O fator de ajuste influencia os pontos de função não ajustados em +/- 35%, obtendo-se o número de PFs ajustados. Para se calcular o fator de ajuste, são usadas 14 características gerais dos sistemas, a saber:
Comunicação de Dados Processamento de Dados Distribuído Desempenho Utilização do Equipamento (Restrições de Recursos Computacionais) Volume de Transações Entrada de Dados On-line Eficiência do Usuário Final (Usabilidade) Atualização On-line Processamento Complexo Reusabilidade Facilidade de Implantação
Facilidade Operacional (Processos Operacionais, tais como Inicialização, Cópia de Segurança, Recuperação etc) Múltiplos Locais e Organizações do Usuário Facilidade de Mudanças (Manutenibilidade)
Para cada uma dessas 14 características deve-se atribuir um valor de 0 (nenhuma influência) a 5 (forte influência), dito grau ou nível de influência, que indica o quanto determinada característica tem influência no sistema. Os 14 graus de influência (GIs) informados são somados, resultando no nível de influência total (NIT):
Finalmente, o valor do fator de ajuste (VFA) é determinado, então, pela fórmula:
Considerando que o valor máximo do NIT é 14x5=70 e o mínimo é zero, então, o valor do VFA varia de 0,65 a 1,35.
43
TI para concursos
4.6.1.5
Cálculo dos Pontos de Função Ajustados Uma vez calculados os PF não ajustados e o fator de ajuste, é possível calcular os PFs ajustados. Esse cálculo é feito de formas diferentes para cada tipo de contagem (projeto de desenvolvimento, projeto de manutenção ou aplicações instaladas). Para projetos de desenvolvimento, o cálculo é dado por: PF = PFNA * VFA onde PFNA = Número de PFs não ajustados VFA = valor do fator de ajuste
4.6.2
Método COCOMO O método COCOMO (ou COnstructive COst MOdel) é um modelo de estimativa do tempo de desenvolvimento de um produto. Criado por Barry Boehm. É baseado no estudo de sessenta e três projetos. Os programas examinaram de 2.000 a 100.000 linhas de código em linguagens de programação de Assembly a PL/I.15 A partir de um conjunto de atributos, premissas e modos de desenvolvimento o COCOMO estima os prazos, custos e recursos necessários para cada etapa do ciclo de vida do produto. COCOMO consiste em três implementações: Básico - É um modelo estático que calcula o esforço de desenvolvimento de software e seu custo, em função do tamanho de linhas de códigos desenvolvidas. Cocomo básico é bom por ser rápido em estimativas e custos de software, mas sua exatidão é limitada por causa de sua falta de fatores para explicar as diferenças entre ferramentas, qualidade de pessoal e experiência, uso de ferramentas modernas e técnicas, e outros atributos de projeto que influenciam nos custos de software. Intermediário - Calcula o esforço de desenvolvimento de software em função do tamanho do programa, que inclui custo, avaliação subjetiva do produto, hardware, pessoal e atributos de projeto. O método intermediário é uma extensão do método básico, mas com mais categorias de controle como: atributos do produto, atributos de hardware, atributos pessoais, atributos do projeto. Avançado - São incorporadas características da versão intermediária com uma avaliação de impacto de custo em cada passo de todo o projeto.
4.7
Gerência de Requisitos de Software A engenharia de requisitos16 é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo. O processo de engenharia de requisitos é composto por quatro atividades de alto nível: Identificação. Análise e negociação. Especificação e documentação. Validação. A gestão dos requisitos faz parte deste processo, se incluirmos a fase de manutenção, sendo que as alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças na natureza do negócio. A implementação de boas práticas de gerência de requisitos de software constitui uma das prioridades na implantação de melhoria do processo de software. O principal risco, que atinge 80% dos projetos de software, é o da Evolução de Requisitos. Os indicadores de desempenho são formas de representação quantificáveis de características de produtos e processos, sendo utilizados para acompanhar e melhorar os resultados ao longo do tempo.
15
http://pt.wikipedia.org/wiki/M%C3%A9todo_COCOMO
16
http://pt.wikipedia.org/wiki/Requisitos_de_Software
44
TI para concursos
4.7.1
Conceitos de Requisitos Um requisito é definido como "uma condição ou uma capacidade com a qual o sistema deve estar de acordo".17 Os requisitos do utilizador destinam-se aos vários níveis hierárquicos da organização e são descritos usando apenas linguagem natural, formulários e diagramas muito simples. Neste nível de especificação, surgem algumas dificuldades: Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem tornar a sua descrição muito longa ou de difícil compreensão. Confusão: ainda que possa não ser tão relevante do ponto de vista do cliente, a distinção entre requisitos funcionais/não-funcionais e objetivos do sistema torna-se difícil. Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode ser difícil separar claramente os requisitos, o que leva a que vários requisitos sejam expressos como sendo apenas um. Algumas considerações: Usar o mesmo formato em todos os requisitos para evitar omissões e facilitar a verificação dos requisitos. Distinguir claramente, através do uso de expressões, entre comportamentos esperados "O sistema permitirá criar (...)" ou desejáveis "Deverá ser possível criar (...)". É importante deixar claro o que o sistema tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de expressões de forma consistente ao longo de todo o documento. Usar formatação de texto para salientar determinados aspectos do documento (negrito, sublinhado, itálico). Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando e definindo de uma forma clara quando for absolutamente necessário usá-los. Os requisitos do sistema têm um carácter mais técnico, consistindo numa descrição detalhada dos requisitos do utilizador recorrendo ao uso de linguagens estruturadas e notações gráficas. Estes requisitos destinam-se aos utilizadores do sistema, às equipes de especificação de arquitetura do sistema e de desenvolvimento. O uso de linguagem natural levanta problemas: As mesmas palavras podem, de acordo com a interpretação de cada pessoa, designar conceitos diferentes. O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada pessoa tenha de saber quando é que descrições diferentes se referem ou não a requisitos diferentes.
4.7.1.1
Elicitação Técnica de obtenção de dados junto aos usuários detententores das informações, principalmente para a construção de um sistema ou um produto ou, ainda para melhorar um processo de trabalho.
4.7.1.2
Joint Application Development (JAD)18 Técnica para levantamento de requisitos desenvolvido pela IBM nos anos 70, que organiza reuniões que discutem o processo de levantamento de requisitos gerenciamento do projeto. Os princípios básicos: Ninguém é melhor para explicar um determinado processo do que as pessoas que trabalham com ele. Os profissionais de TI são os mais preparados para identificar as possibilidades que a tecnologia oferece, assim como suas limitações. Sistemas de informação e processos do negócio não são isolados. Os melhores sistemas de informação são resultado do trabalho conjunto de todas as pessoas envolvidas: profissionais de TI, usuários, gestores, analistas de negócio etc. O JAD orienta a condução das sessões a partir de alguns papéis.
17
http://www.wthreex.com/rup/portugues/process/workflow/requirem/co_req.htm
18
http://www.cos.ufrj.br/~targino/engsoft/JAD.pdf
45
TI para concursos
O facilitador é neutro: ele não opina nos assuntos discutidos, mas pode direcionar os assuntos conforme o planejamento inicial. Cabe a ele também evitar que determinados indivíduos dominem reunião. O anotador está dedicado a registrar os assuntos discutidos e decisões tomadas, liberando assim os outros membros a participar das discuss ões sem perder tempo com anotações. O gerenciador de tempo vai evitar que determinadas discussões demorem demasiadamente, evitando assim que outros assuntos não sejam abordados. O quadro do projeto serve para lembrar os assuntos em foco e os que estão fora do foco, impedindo assim discussões infrutíferas. 4.7.1.3
Estudo etnográfico19 Estudo etnográfico é uma técnica, proveniente das disciplinas de Antropologia Social, que consiste no estudo de um objeto por vivência direta da realidade onde este se insere, permitindo analisar a componente social das tarefas desempenhadas numa dada organização tornam-se, no âmbito da Engenharia de Requisitos, extremamente uteis para ultrapassar a dificuldade que existe na coleta dos requisitos derivados de formas rotineiras e tácitas de trabalhar: modo como realmente as pessoas executam as suas funções que muitas vezes difere da forma como as definições dos processos sugerem que elas devem fazer; cooperação e conhecimento das atividades de outras pessoas. Para isso, um sociólogo, externo à organização em causa, passa algum tempo observando e analisando a atividade das pessoas sem que estas necessitem explicar o seu trabalho (interações implícitas), extraindo daí conclusões importantes acerca de fatores sociais e organizacionais. Desta forma, é necessário assumir que as pessoas em estudo são competentes na realização do seu trabalho. Estes estudos têm mostrado que o trabalho das pessoas é, normalmente, mais rico e complexo do que o descrito pelas definições dos processos e pelos modelos dos sistemas. O principal problema da aplicação deste método é fruto da dificuldade na generalização dos resultados. É um método qualitativo que se insere na corrente filosófica do Interpretivismo.
4.7.2
Requisitos Funcionais e Não-Funcionais Os requisitos funcionais especificam ações que um sistema deve ser capaz de executar, sem levar em consideração restrições físicas. Geralmente, isso é melhor descrito em um modelo de casos de uso. Os requisitos funcionais especificam o comportamento de entrada e saída de um sistema. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido. conjuntos de recursos habilidades segurança Requisitos não-funcionais são restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Vários requisitos não são funcionais e descrevem apenas atributos ou ambiente do sistema. Alguns deles podem ser capturados em casos de uso, outros em Especificações Suplementares. Usabilidade
fatores humanos estética consistência na interface do usuário ajuda online e contextual assistentes e agentes documentação do usuário materiais de treinamento
Confiabilidade freqüência e gravidade de falha possibilidade de recuperação possibilidade de previsão 19
http://pt.wikipedia.org/wiki/Estudo_etnogr%C3%A1fico
46
TI para concursos
exatidão tempo médio entre falhas (MTBF)
Desempenho
velocidade eficiência disponibilidade exatidão taxa de transferência tempo de resposta tempo de recuperação uso de recurso
Suportabilidade
possibilidade de teste extensibilidade adaptabilidade manutenibilidade compatibilidade possibilidade de configuração possibilidade de serviço possibilidade de instalação possibilidade de localização (internacionalização)
restrições de design especifica ou restringe o design de um sistema
requisitos de implementação
padrões obrigatórios linguagens de implementação políticas de integridade de banco de dados limites de recursos ambientes operacionais
requisitos de interface um item externo com o qual o sistema deve interagir restrições de formatos, tempos ou outros fatores usados por tal interação
requisitos físicos
material forma tamanho peso
4.8
Gerência de Configuração e Mudança
4.8.1
Conceitos de Gerência de Configuração e Mudança de software Gerência de Configuração de Software é uma área da engenharia de software responsável por fornecer o apoio para o desenvolvimento de software. Suas principais atribuições são o controle de versão, o controle de mudança e a auditoria das configurações.20 Conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas. A Gerência de Configuração e Software é definida por quatro funções básicas: Identificação dos itens de configuração Documentação Controle Auditoria das mudanças
20
http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_Configura%C3%A7%C3%A3o_de_Software
47
TI para concursos
4.8.2
Solicitações de Mudança As mudanças nos artefatos de desenvolvimento são propostas através de Solicitações de Mudança (CRs ou Change Requests), que são usadas para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto. A vantagem das CRs é que elas fornecem um registro das decisões e, devido a seu processo de 21 avaliação, garantem que os impactos das mudanças sejam entendidos no projeto. A necessidade de mudança parece ser inerente aos sistemas de software existentes e em desenvolvimento. O Gerente de Controle de Mudança é responsável pela definição dos procedimentos de Gerenciamento de Solicitações de Mudança e pela manutenção de CRs, garantindo que as mudanças em um sistema sejam efetuadas de maneira controlada, para que seu efeito no sistema possa ser previsto. As CRs podem ser usadas para documentar e controlar todos os tipos de solicitações de mudanças no sistema, inclusive defeitos e solicitações de melhoria. As solicitações de melhoria são usadas pelo Analista de Sistemas para determinar futuros recursos a serem incluídos no produto. Serão usadas como base durante a coleta de solicitações dos principais envolvidos (stakeholders) para que se possa compreender as necessidades dos investidores. Um defeito é uma anomalia ou falha em um produto de trabalho liberado. Alguns exemplos são omissões e imperfeições localizadas durante as fases iniciais do ciclo de vida e sintomas (falhas) de erros contidos em softwares maduros o suficiente para teste e operação. Os defeitos também podem incluir desvios das expectativas ou qualquer questão que precise ser controlada e resolvida. A finalidade de um defeito é comunicar os detalhes da questão, permitindo a ação corretiva, a solução e o acompanhamento. As seguintes pessoas usam as CRs: O Analista de Sistemas usa as CRs identificadas como Solicitações de Melhoria para determinar novos recursos do produto. O Gerente de Projetos usa CRs para atribuir trabalho. Os Testadores usam CRs para identificar e descrever os defeitos localizados no teste. O Implementador usa CRs para analisar o defeito e localizar os erros ou causas das CRs. O Designer de Teste usa CRs a fim de planejar o teste para verificar as CRs solucionadas e analisar um conjunto de defeitos para medir a qualidade do software e do processo. Os seguintes atributos são úteis para tomar uma decisão sobre qualquer CR enviada: Tamanho Que volume de trabalho existente precisará ser alterado? Que volume de trabalho extra precisará ser adicionado? Alternativas Existe alguma? Complexidade A mudança proposta é fácil de ser efetuada? Quais são as possíveis ramificações provenientes dessa mudança? Gravidade Qual é o impacto da não implementação desta solicitação? Há alguma perda de trabalho ou de dados envolvida? Esta é uma solicitação de melhoria? É um problema secundário? Cronograma Quando a mudança é necessária? Ela é viável? Impacto Quais as conseqüências de efetuar a mudança? Quais as conseqüências de não efetuar a mudança?
21
http://www.wthreex.com/rup/process/artifact/ar_crqst.htm
48
TI para concursos
Custo Qual é a economia proveniente desta mudança? Relacionamento com Outras Mudanças Outras mudanças substituirão ou invalidarão esta ou isso depende de outras mudanças? Teste Há algum requisito especial de teste? As práticas de Gerenciamento de Mudanças normalmente são institucionalizadas ou estabelecidas no início do ciclo de vida do projeto. Desse modo, as CRs, que integram o processo de mudança, podem surgir a qualquer momento durante o curso do projeto. A principal origem de defeitos consiste nos resultados da execução dos testes — integração, sistema e desempenho. Contudo, os defeitos podem aparecer em qualquer ponto do ciclo de vida de desenvolvimento do software e abranger a identificação de documentação, casos de teste ou casos de uso ausentes ou incompletos. Qualquer pessoa da equipe de projeto deve ser capaz de efetuar uma CR. No entanto, a CR precisa ser revisada e aprovada pelo supervisor da pessoa que a efetuou. A arbitragem final sobre uma Solicitação de Mudança é realizada por uma Equipe de Revisão ou um Comitê de Controle de Mudança (CCB). O Gerente de Controle de Mudança é responsável pela integridade do defeito, garantindo que: Sejam exatas todas as informações que identificam e descrevem o defeito e indicam como ele foi descoberto. O defeito seja exclusivo ou que não seja outra ocorrência de um defeito já identificado. Os campos e os dados reais necessários para identificar, descrever e controlar defeitos com precisão são variados e dependem do sistema de controle de mudanças, das diretrizes e dos padrões implementados.
4.9
Testes e Avaliação de Qualidade de Software
4.9.1
Qualidade de Software Área de conhecimento da engenharia de software que objetiva garantir a qualidade do software através da definição e normatização de processos de desenvolvimento. Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente. A qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos inicialmente estipulados.22 A engenharia de software objetiva garantir a qualidade através da definição e normatização de processos de desenvolvimento, com um produto final que satisfaça às expectativas do cliente. Os atributos qualitativos previstos na norma ISO 9126 são:
funcionalidade confiabilidade usabilidade eficiência manutenibilidade portabilidade.
Mensurar o bom funcionamento de um software envolve compará-lo com elementos como especificações, outros softwares da mesma linha, versões anteriores do mesmo produto, inferências pessoais, expectativas do cliente, normas relevantes, leis aplicáveis, entre outros. A verificação compara o software com a especificação, enquanto que a validação compara com a expectativa do cliente. A melhoria de processos tem base em modelos tidos como eficientes, como por exemplo os SW-CMM, SE-CMM, ISO 15504 e o mais conhecido CMMI. 4.9.1.1 22
CMM
http://pt.wikipedia.org/wiki/Qualidade_de_software
49
TI para concursos
O "CMM - Capability Maturity Model for Software /SEI" é uma estrutura (framework), que descreve os principais elementos de um processo de desenvolvimento de software. Organizações de software evoluem o seu ciclo de desenvolvimento de software através de sua avaliação contínua, identificação e ações corretivas dentro de uma estratégia de melhoria dos processos. Este caminho de melhoria é definido por cinco níveis de maturidade: inicial, ad hoc, sem ambiente estável de desenvolvimento ou processos estruturados, que excedem prazos e orçamentos. repetitivo, um minimo de disciplina nos processos para repetir sucessos anteriores, podendo utilizar ferramentas de gerência de projetos para administrar custos e prazos, e status do projeto visíveis (marcos e término). definido, um conjunto de processos padrão estabelecidos e melhorados periodicamente gerenciado, com utilização de indicadores de qualidade otimizado, com a procura constante de inovação e a realização de um processo controlado e mensurado para melhoria contínua O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem a organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse. Representação Continua, que possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade (Capability Levels):
Nível Nível Nível Nível Nível Nível
0: Incompleto (Ad-hoc) 1: Executado (Definido) 2: Gerenciado 3: Definido 4: Quantitativamente gerenciado 5: Em otimização
Representação Por Estágios, que oferece uma seqüência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels):
4.9.1.2
Nível Nível Nível Nível Nível
1: Inicial (Ad-hoc) 2: Gerenciado 3: Definido 4: Quantitativamente gerenciado 5: Em otimização
Garantia de qualidade de software A Garantia da Qualidade de Software (GQS) é a área-chave de processo do CMM cujo objetivo é fornecer aos vários níveis de gerência a adequada visibilidade dos projetos, dos processos de desenvolvimento e dos produtos gerados. A GQS atua como “guardiã”, fornecendo um retrato do uso do Processo e não é responsável por executar testes de software ou inspeção em artefatos.23 Obtendo a visibilidade desejada, a gerência pode atuar de forma pontual no sentido de atingir os quatro grandes objetivos de um projeto de desenvolvimento de software, quais sejam, desenvolver software de alta qualidade, ter alta produtividade da equipe de desenvolvimento, cumprir o cronograma estabelecido junto ao cliente e não necessitar de recursos adicionais não previstos. Para conseguir esses objetivos a área-chave de processo GQS estimula a atuação das equipes responsáveis pelo desenvolvimento de software em diversas frentes objetivando internalizar comportamentos e ações, podendo-se destacar: o planejamento do projeto e o acompanhamento de resultados; o uso dos métodos e ferramentas padronizadas na organização; a adoção de Revisões Técnicas Formais; o estabelecimento e a monitoração de estratégias de testes; a revisão dos artefatos produzidos pelo processo de desenvolvimento;
23
http://pt.wikipedia.org/wiki/Qualidade_de_software
50
TI para concursos
a busca de conformidade com os padrões de desenvolvimento de software; a implantação de medições associadas a projeto, processo e produto; a utilização de mecanismos adequados de armazenamento e recuperação de dados relativos a projetos, processos e produtos; a busca de uma melhoria contínua no processo de desenvolvimento de software.
4.9.2
Teste de software O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos. O teste é um processo realizado pelo testador de software, que permeia outros processos da engenharia de software, e que envolve ações que vão do levantamento de requisitos até a execução do teste propriamente dito. Não se pode garantir que todo software funcione corretamente, sem a presença de erros, visto que os mesmos muitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a complexidade. Idealmente, toda permutação possível do software deveria ser testada. Entretanto, isso se torna impossível para a ampla maioria dos casos devido à quantidade impraticável de possibilidades. A qualidade do teste acaba se relacionando à qualidade dos profissionais envolvidos em filtrar as permutações relevantes. Falhas podem ser originadas por diversos motivos. Por exemplo, a especificação pode estar errada ou incompleta, ou pode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software. A implementação também pode estar errada ou incompleta, como um erro de um algoritmo. Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema. Todas as metodologias de desenvolvimento de software têm uma disciplina dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e financeiros. O gerenciamento de projetos define alguns princípios em relação aos testes: 24
Testar é um exercício de gerência de risco Treinamento em teste reduz custos a longo prazo As estimativas de teste devem ser baseadas no risco do negócio A estratégia de teste deve ser elaborada através de um trabalho conjunto entre as áreas envolvidas É melhor encontrar um defeito nas primeiras fases do que em produção
Um plano de testes deve passar por alguns estágios: Planejamento
Estratégia de Teste Cronograma básico Plano de Teste Cronograma final Análise de Risco Análise de Pontos deTeste
Elaboração
Elaborar Cenário de Teste Elaborar Caso de Teste Procedimento de Teste Implementar Teste
Execução Casos de Teste Roteiros de Teste
Controle Relatórios de Defeitos Relatórios de Progresso
24
http://www.iteste.com.br/Portals/0/Palestra%20Gerencia%20de%20Teste_1%20hora.pdf
51
TI para concursos
As pessoas envolvidas nos testes podem assumir os papéis de: Líder ou Gerente de teste, responsável pela liderança de um projeto de teste específico Arquiteto de Teste, responsável pela montagem do ambiente de teste (infra-estrutura) e escolha das ferramentas Analista de Teste, responsável pela modelagem e elaboração dos casos de testes e scripts de teste Testador, responsável pela execução dos casos de teste e scripts de teste
A definição de quem irá executar os testes dependerá do nível ou estágio do teste:
Teste Unitário - Desenvolvedores Teste de Integração - Analistas de Sistemas Teste de Sistema - Analistas de Teste Teste de Aceitação - Usuários e Analistas de Teste
Existem técnicas de testes chamadas de funcionais, que verificam se o sistema faz o que deveria:25 Teste de caixa-branca - Também chamado de teste estrutural ou orientado à lógica, avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados. Teste de caixa-preta - Também chamado de teste funcional, orientado a dado ou orientado a entrada e saída, avalia o comportamento externo do componente de software. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido.
Há, por outro lado, as técnicas não funcionais, que testam como a operação correta do sistema se comporta em situações anormais, como casos de entradas inválidas ou inesperadas. teste de desempenho com teste de carga, verifica se o software consegue processar grandes quantidades de dados nas especificações de tempo de processamento exigidas, o que determina a escalabilidade do software. teste de usabilidade, necessário para verificar se a interface de usuário é fácil de se aprender e utilizar. teste de confiabilidade, usado para verificar se o software é pode assegurar o sigilo dos dados armazenados e processados. teste de recuperação, usado para verificar a robustez do software em retornar a um estado estável de execução após estar em um estado de falha.
4.9.3
Documentos de Teste IEEE 829-1998, também conhecido como o Padrão 829 para Documentação de Teste de Software, é um padrão IEEE que especifica a forma de uso de um conjunto de documentos em oito estágios definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de documento. O padrão especifica o formato desses documentos mas não estipula se todos eles devem ser produzidos, nem inclui qualquer critério de conteúdo para esses documentos.26 Documentação de Teste consiste em um conjunto de documentos relacionados ao teste das diversas classes e seus relacionamentos no sistema. Dentre eles pdemos ter:27 Plano de Teste, que prescreve o escopo, a abordagem, os recursos e o cronograma de testes. No mínimo os seguintes tópicos devem ser tratados: Descrição do programa a ser testado: o que faz; estrutura Objetivo dos testes: por exemplo, se são testes caixa branca ou caixa preta, se são testes de integração ou de unidade Escopo dos testes: que itens serão testados, quais não serão
Projetos de Teste, que detalha o planejamento de testes e identifica os elementos a serem testados. No caso de testes de unidades, cada unidade é um item. Definção das estruturas provisórias (drivers, stubs, arquivos ou bancos de dados criados para os testes, entre outros) que serão usadas nos testes. Casos de Teste especificados no projeto. A descrição de cada caso de teste deve conter os seguintes tópicos:
Identificação do caso de teste Itens a testar Entradas: valores dos campos de entrada Saídas esperadas: valores dos campos de saída
25
http://pt.wikipedia.org/wiki/Teste_de_software
26
http://se.inf.ethz.ch/teaching/ss2005/0050/exercises/REMOVED/IEEE%20Std%20829-1998%20test.pdf
27
http://www.ic.unicamp.br/~eliane/Cursos/Planos_Testes/Documentos/plantestes.doc.
52
TI para concursos
Ambiente: necessidade de hw, sw, ferramentas e estruturas provisórias que sejam específicas desse caso de teste Procedimentos: identificação do procedimento de teste (dentre os já listados na seção anterior) que será usado para executar o caso de teste Dependências: condições prévias para a execução do caso de teste, inclusive outros casos de teste que devam ser executados obrigatoriamente antes deste Saídas observadas: resultados fornecidos pelo item em teste ou anomalias ocorridas durante a execução Impacto: consequências do incidente de teste (evento indesejável que tenha ocorrido durante os testes). Como para a inspeção, classificá-los em categorias: MA: maior. Causa resultados errados/anomalia na execução do programa ME: menor. Causa outro tipo de problema que não afeta a execução do programa
Procedimentos de Teste, que especifica os passos para execução. Definição dos procedimentos associados ao conjunto de testes: Uma identificação do procedimento . O objetivo do procedimento. Os requisitos especiais para a execução do procedimento (por exemplo, usar o arquivo DadosTeste) O fluxo passo a passo do procedimento detalhado o suficiente para que possa ser executado manualmente por um operador ou convertido em um script de teste. Descrição de cada um dos casos de teste gerado.
Resultados do teste, contendo os registros dos testes realizados em ordem cronológica. Relatório de incidentes, contendo o registro dos problemas encontrados durante os testes que mereçam ser investigados. Relatório de resumo dos teste, contendo um resumo dos resultados das atividades projetadas e fornecendo avalições baseadas nestes resultados. O relatório fecha a etapa de testes realizada, permitindo uma avaliação da eficácia dos mesmos, indicação do nível de qualidade do produto, se há necessidade de testes adicionais ou a reconstrução de alguns itens sob teste. O relatório de resumo pode conter: Identificador do relatório resumido Contexto: quais os itens testados, com respectivos números de versão e revisão Variações: descrever as possíveis variações dos testes realizados em relação ao previsto na especificação, justifiando o motivo de tais variações Abrangência: avaliar se a cobertura foi suficiente, conforme o planejado. Indicar possíveis deficiências nos testes, caso existam. Sumário dos resultados: resumir os incidentes ocorridos Avaliação: fornecer uma avaliação global da eficácia dos testes; uma base para isso pode ser o número de defeitos classificados como MA que foram encontrados. Sumário das atividades: para cada item testado, indicar o tempo previsto e os efetivamente gastos para as tarefas de teste Aprovações: indicar se o item testado foi considerado aprovado ou não.
4.10
Exercícios 36.
53
(ICMS-SP 2009) Quanto aos requisitos de software, considere: I. É importante que se estabeleçam práticas para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema. II. Etnografia (observação e análise dos fluxos de trabalho) e sessões de JAD são práticas que podem ser aplicadas na elicitação. III. Elicitar significa descobrir os requisitos de um sistema por meio de entrevistas, de documentos do sistema existente, de análise do domínio do problema ou de estudos do mercado. 36 Está correto o que se afirma em (a) I, apenas. (b) I e II, apenas. xx (c) I, II e III. (d) II e III, apenas. (e) III, apenas.
TI para concursos
37.
(ICMS-SP 2009) Considere: "Os requisitos expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do usuário. Em geral, independem da tecnologia empregada na construção da solução, sendo uma das partes mais críticas e propensas a erros no desenvolvimento de software”. 37 Quanto aos requisitos de software, a descrição acima está (a) incoerente ao afirmar que expressam restrições. (b) incoerente ao afirmar que independem da tecnologia. (c) incoerente ao afirmar que expressam características do ponto de vista de satisfação das necessidades do usuário. xx (d) totalmente coerente. (e) incoerente ao afirmar que os requisitos são uma das partes mais críticas e propensas a erros.
(ICMS-SP 2009) Instruções: Para responder às duas próximas questões, considere: “É necessário que o software calcule os salários dos diaristas e mensalistas e emita relatórios mensais sumariados por tipo de salário. Entretanto, a base de dados deve estar protegida e com acesso restrito aos usuários autorizados. De qualquer forma, o tempo de resposta das consultas não deve superar os quinze segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar que os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente em razão dos adiantamentos e vales que recebem. É fundamental que o software seja operacionalizado usando código aberto. Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a entrega do produto final não pode ultrapassar o prazo de oito meses a contar da data de início do projeto. A frase acima, expressa por um funcionário do cliente, aborda alguns requisitos de software especificados para um sistema de gestão de pessoal.
54
38
38.
(ICMS-SP 2009) No texto, são requisitos não-funcionais: (a) não pode ultrapassar o prazo de oito meses e necessário que o software calcule os salários dos diaristas e mensalistas. (b) os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente e em razão dos adiantamentos e vales que recebem. (c) É fundamental que o software seja operacionalizado usando código aberto e os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente. (d) tempo de resposta das consultas não deve superar os quinze segundos e entrega do produto final não xx pode ultrapassar o prazo de oito meses. (e) pois inviabilizaria todo o investimento nesse sistema e em razão dos adiantamentos e vales que recebem.
39.
(ICMS-SP 2009) No texto, são requisitos funcionais: (a) calcule os salários dos diaristas e mensalistas e os relatórios individuais dos departamentos, nos quais xx constam os salários dos funcionários, devem ser emitidos quinzenalmente. (b) Necessito, ainda, forte gerenciamento de risco, prazo e custo e a base de dados deve estar protegida e com acesso restrito aos usuários autorizados. (c) é fundamental que o software seja operacionalizado usando código aberto e emita relatórios mensais sumariados por tipo de salário. (d) emita relatórios mensais sumariados por tipo de salário e necessito, ainda, forte gerenciamento de risco, prazo e custo. (e) a base de dados deve estar protegida e com acesso restrito aos usuários autorizados e entrega do produto final não pode ultrapassar o prazo de oito meses.
40.
(ICMS-SP 2009) O processo de confirmação que um software vai ao encontro das especificações de 40 software se trata de um conceito-chave de qualidade denominado (a) Validação. xx (b) Verificação. (c) Precisão. (d) Acurácia. (e) Confiabilidade.
41.
(ICMS-SP 2009) Garantir que um ou mais componentes de um sistema combinados funcionam corretamente 41 é o objetivo do tipo de teste (a) de sistema. xx (b) de integração. (c) de configuração. (d) operacional. (e) funcional.
42.
(ICMS-SP 2009) O teste de ameaça normalmente deve ser aplicado dentro de um projeto de software nas 42 etapas de (a) desenvolvimento inicial e desenvolvimento intermediário. (b) desenvolvimento intermediário e teste de aceitação. (c) desenvolvimento intermediário e teste de sistema. (d) teste de integração e teste de aceitação. xx (e) teste de integração e teste de sistema.
39
TI para concursos
43.
(ICMS-SP 2009) Na prática de garantia de qualidade de software, contrapondo com o controle de qualidade 43 de software, se aplica a atividade: (a) executar teste de software. (b) desenvolver casos de testes. xx (c) definir métricas e medição. (d) definir estratégias de testes. (e) definir planos de desenvolvimento de teste.
44.
(ICMS-SP 2009) O processo de engenharia de software denominado ciclo de vida clássico refere-se ao 44 modelo xx (a) em cascata. (b) incremental. (c) evolucionário. (d) prototipagem. (e) de processo unificado
45.
(ICMS-SP 2009) O conceito de sprint aplica-se ao modelo ágil do processo de engenharia de software 45 denominado (a) XP. (b) DAS. (c) DSDM. xx (d) Scrum. (e) Crystal.
46.
(ICMS-SP 2009) A engenharia de software está inserida no contexto (a) da engenharia de sistemas, apenas. (b) das engenharias de processo e de produto, apenas. (c) das engenharias de sistemas e de processo, apenas. (d) das engenharias de sistemas e de produto, apenas. xx (e) das engenharias de sistemas, de processo e de produto.
47.
(FCC - 2008 - TRT) A frase "o tempo médio de resposta do sistema não deve ultrapassar 5 segundos" indica 47
(a) (b) (c) (d) (e)
55
46
uma funcionalidade do sistema. uma atividade do cronograma do sistema. uma função executada pelo usuário do sistema. uma possível definição de requisito não funcional.xx um ponto de controle nas etapas de desenvolvimento do sistema.
48.
(FCC - 2008 – TCE AL) Em um sistema cujo objetivo principal seja emitir guias de cobrança de impostos e 48 fazer o controle de contribuintes, NÃO é um produto inerente ao trabalho de levantamento de requisitos xx (a) uma descrição da relação possível entre as linhas de código com os pontos de função. (b) uma declaração da necessidade e da viabilidade. (c) uma descrição do ambiente técnico do sistema. (d) uma afirmação limitada do escopo do sistema. (e) um conjunto de cenários que fornecem informações sobre o uso do sistema sob diferentes condições de operação.
49.
É correto afirmar que (a) um relatório não é um artefato de sistema. (b) segurança não é um requisito não funcional de sistema. xx (c) um executável é um artefato de sistema. (d) os atributos de uma classe UML são especificações dos seus métodos. (e) confiabilidade é um requisito funcional de sistema.
50.
O modelo FURPS, para melhoria de qualidade de software, representa as dimensões, que são mais 50 relevantes para os clientes: xx (a) Funcionalidade, Usabilidade, Confiabilidade, Desempenho e Suportabilidade. (b) Funcionalidade, Usabilidade, Reusabilidade, Pontualidade e Suportabilidade. (c) Flexibilidade, Usabilidade, Conformidade, Desempenho e Atendimento. (d) Flexibilidade, Usabilidade, Reusabilidade, Performance e Suportabilidade. (e) Integridade, Usabilidade, Conformidade, Portabilidade e Atendimento.
51.
Segundo o modelo CMM, migrar do nível 3 de maturidade para o nível 4 representa uma melhoria da 51 qualidade de processos (a) otimizados para processos gerenciados. (b) definidos para processos repetíveis. xx (c) definidos para processos gerenciados. (d) gerenciados para processos otimizados. (e) repetíveis para processos definidos.
49
TI para concursos
52.
O metamodelo CMMI contínuo define que cada área de processo é avaliada formalmente, com base em 52 metas e práticas específicas, e classificada de acordo com seis níveis de capacitação. O nível 3 é o (a) Quantitativamente gerido. (b) Realizado. xx (c) Definido. (d) Gerido. (e) Otimizado.
53.
NÃO é um dos sete princípios (David Hooker) da Engenharia de Software: (a) manter a coisa simples. xx (b) não especificar requisitos detalhadamente. (c) estar aberto para o futuro. (d) planejar o reúso com antecedência. (e) manter a visão.
54.
NÃO é uma das nove características em um tratamento detalhado das métricas de software (Whitmire) para o 54 modelo de projeto orientado a objeto: xx (a) o custo. (b) o tamanho. (c) a complexidade. (d) o acoplamento. (e) a coesão.
55.
O método que busca medir esforço, prazo, tamanho de equipe e custo necessário para o desenvolvimento do software, desde que se tenha a dimensão do mesmo, por meio de um modelo de estimativa de tamanho de 55 software (Boehm) é o (a) Function Point Analysis. (b) CoCoMo.xx (c) Work Breakdown Structure. (d) Benchmarking. (e) Flowcharting.
53
(ICMS-SP 2009) Instruções: Para responder às três próximas questões, considere a tabela e os dados de referência para os cálculos de pontos de função.
Pontuação por complexidade de função
56
Tipos
Simples
Médio
Complexo
EE
3
4
6
SE
4
5
7
CE
3
4
6
ALI
7
10
15
AIE
5
7
10
TI para concursos
Níveis de Influência: 0 − Nenhuma influência. 1 − Influência mínima. 2 − Influência moderada. 3 − Influência média. 4 − Influência significante. 5 − Influência forte. Características Gerais de Sistema: 1. Comunicação de Dados. 2. Processamento de Dados Distribuído (Funções Distribuídas). 3. Performance. 4. Configuração do equipamento. 5. Volume de Transações. 6. Entrada de Dados On line. 7. Interface com o usuário. 8. Atualização On line. 9. Processamento Complexo. 10. Reusabilidade. 11. Facilidade de Implantação. 12. Facilidade Operacional. 13. Múltiplos Locais. 14. Facilidade de mudanças.
57
56.
(ICMS-SP 2009) Durante o levantamento de requisitos de um sistema, foram apuradas as seguintes 56 informações, base para o cálculo de pontos de função: Complexidade de: − Entrada: 2 complexas , 4 médias e 5 simples. − Saída: 10 médias e 3 simples. − Arquivo mantido dentro da fronteira do sistema: 1 complexo e 2 médios. Sem nenhuma influência, o resultado apurado foi (a) 133 (b) 138 xx (c) 140 (d) 149 (e) 161
57.
(ICMS-SP 2009) Mantida a pontuação bruta obtida na questão de número 22 e considerando que as influências por características gerais do sistema foram estimadas como: − Forte em performance. − Significante em entrada de dados on line e em processamento distribuído. − Demais características sem influência. 57 O resultado final mais aproximado, após o ajuste, foi (a) 98,0 (b) 107,8 (c) 110,6 xx (d) 109,2 (e) 116,0
58.
(ICMS-SP 2009) Após um levantamento mais apurado do sistema referido, funções foram modificadas, adicionadas ou excluídas e, em razão das modificações sugeridas, chegou-se às seguintes e novas informações: Complexidade de: − Consulta: 5 complexas, 10 médias e 11 simples. − Arquivo mantido fora da fronteira do sistema: 1 complexo e 1 médio. − Entrada: 2 complexas, 4 médias e 5 simples. − Saída: 5 complexas, 10 médias e 3 simples. − Arquivo mantido dentro da fronteira do sistema: 3 complexos, 1 médio e 4 simples. As novas influências por características gerais do sistema foram estimadas como: − Forte em performance. − Significante em entrada de dados on line, em processamento distribuído, em facilidade de mudanças e em interface com o usuário. − Mínima em volume de transações. − Moderada em comunicação de dados. − Demais características sem influência. 58 Com base nessas novas informações levantadas, o resultado final mais aproximado, após o ajuste, foi (a) 263,7 (b) 298,9 (c) 300,5 xx (d) 305,3 (e) 432,8
TI para concursos
58
59.
Considere 1952 pontos por função brutos e a aplicação do valor 3 a todos os fatores de ajuste. Os pontos por 59 função ajustados são (a) 1268,80. (b) 1542,08. (c) 1815,36. xx (d) 2088,64. (e) 2635,00.
60.
Durante a medição do grau de complexidade de um sistema foram apurados 550 pontos de função brutos. Considerando que o somatório dos graus atribuídos aos fatores de ajuste foi 30, a medida final em pontos de 60 função foi (a) 520 xx (b) 522,5 (c) 552,5 (d) 580 (e) 585,5
61.
Se em uma seqüência de atividades de um projeto todas elas tiverem retardo de zero dias em relação às 61 suas predecessoras (a) o projeto é inviável. (b) isso indica a ausência de caminho crítico. xx (c) essa seqüência é o caminho crítico. (d) a seqüência está errada. (e) o projeto deve ser desmembrado.
62.
Um Plano de Projeto de Software é um documento gerencial que se destina a um público diverso e NÃO 62 deve conter (a) a comunicação do escopo e dos recursos à administração, aos clientes e à equipe técnica. (b) a definição dos principais requisitos e dos riscos com sugestões técnicas para, respectivamente, atendêlos ou evitá-los. (c) o desenho dos componentes do software para planejar a sua instalação e operacionalização. xx (d) a definição dos custos e dos prazos para as revisões administrativas do projeto. (e) a apresentação de uma abordagem global do desenvolvimento do software para todas as pessoas envolvidas no projeto.
TI para concursos
5
Arquitetura de Software
5.1
Conceitos básicos A arquitetura de software de um sistema consiste dos componentes de software, suas propriedades externas e seus relacionamentos com outros softwares. O termo também se refere à documentação da arquitetura de software do sistema. A documentação da arquitetura do software facilita a comunicação entre os stakeholders, registra as decisões iniciais acerca do projeto de alto nível e permite o reuso do projeto dos componentes e padrões entre projetos.28 A arquitetura de software é organizada em visões, que descrevem a arquitetura na perspectiva de um conjunto de pessoas interessadas, como:
Visão funcional/lógica Visão de código Visão de desenvolvimento/estrutural Visão de concorrência/processo/thread Visão física/evolutiva Visão de ação do usuário/feedback
Várias linguagens para descrição da arquitetura de software foram inventadas, mas nenhum consenso foi ainda alcançado em relação a qual conjunto de símbolos ou sistema representação deve ser adotado. Alguns acreditam que a UML irá estabelecer um padrão para representação de arquitetura de software. Outros acreditam que os desenvolvimentos efetivos de software devem contar com a compreensão única das restrições de cada problema, e notações tão universais são condenadas a um final infeliz porque cada uma provê um notação diferenciada que necessariamente torna a notação inútil ou perigosa para alguns conjuntos de tarefas. Eles apontam a proliferação de linguagens de programação e a sucessão de tentativas falhas para impor uma simples 'linguagem universal' na programação, como uma prova da tendência do software para a diversidade e não para padrões. Há muitas formas comuns de projetar módulos de software de computador e suas comunicações, entre elas:
Cliente-Servidor Computação distribuída P2P Blackboard Criação implícita Pipes e filtros Plugin Sistema Monolítico Modelo em três camadas Analise de sistema estruturada (baseada em módulos, mas usualmente monolíticas em dentro dos módulos) Arquitetura orientada a serviço Arquitetura orientada a busca
5.2
UML A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração que auxilia a visualizar o desenho e a comunicação entre objetos de um sistema de 29 informações. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados (semântica). RUP (Rational Unified Process) é um processo proprietário criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process, que usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML para ilustrar os processos em ação.
28
http://pt.wikipedia.org/wiki/Arquitetura_de_software
29
http://pt.wikipedia.org/wiki/UML
59
TI para concursos
Os objetivos da UML são: especificação, documentação, e estruturação para sub-visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação. A UML é um modo de padronizar as formas de modelagem. O UML se compõe de diversos diagramas, cada um para um tipo diferente de visão. Diagramas Comportamentais Diagrama de Caso de Uso - descreve a funcionalidade proposta para o novo sistema. Um desenho com representação de um ator, humano ou entidade máquina, que interage (relação) com o sistema (casos de uso) para executar um trabalho. Estes relacionamentos podem ser: associações entre atores e casos de uso. Define uma funcionalidade do sistema do ponto de vista do usuário. generalizações entre os atores. Os casos de uso de um ator são também casos de uso do outro, que tem seus próprios casos de uso. generalizações entre os casos de uso. O caso de uso B é um caso de uso A (A é uma generalização de B, ou B é uma especialização de A). Um relacionamento entre um caso de uso genérico para um mais específico, que herda todas as características de seu pai. extensões entre os casos de uso. Um relacionamento extend de um caso de uso B para um caso de uso A indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A (não é essencial). A extensão é inserida em um ponto de extensão do caso de uso A. inclusões entre os casos de uso. Um relacionamento include de um caso de uso A para um caso de uso B indica que B é essencial para o comportamento de A. Pode ser dito também que B is_part_of A ou que A depende de B. Diagrama de transição de estados - representação do estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema. Diagrama de atividade - mostra o fluxo de controle de uma atividade para outra.
Diagramas Estruturais Diagrama de classes - representação da estrutura e relações das classes que servem de modelo para objetos. Uma propriedade, atributo ou operação representada no diagrama de classes, que poderá ser vista e usada apenas pela classe na qual foi declarada, bem como pelas suas classes descendentes, deve ser definida com visibilidade descrita por meio da palavra-chave protected. Diagrama de objetos - mostra os objetos que foram instanciados das classes. Exibe um único conjunto de objetos relacionados uns com os outros em um determinado momento Diagrama de componentes - utilizado para modelar os componentes do código fonte do software. Diagrama de instalação - descreve os componentes de hardware e software e sua interação com outros elementos de suporte ao processamento. Diagrama de pacotes - descreve grupos de classes, de outros elementos ou pedaços do sistema divididos em agrupamentos lógicos mostrando as dependências entre estes. Diagrama de estrutura - descreve a colaboração interna de classes, interfaces ou componentes para especificar uma funcionalidade.
Diagramas de Interação Diagrama de sequência - representa a sequência de mensagens passadas entre objetos num programa de 30 computador. Utiliza-se também o termo cenário associado com diagramas de seqüência. Diagrama de Interatividade – descreve o fluxo de atividades mostrando como elas trabalham em uma sequência de eventos. Diagrama de colaboração ou comunicação - exibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. Diagrama de tempo - apresenta o comportamento dos objetos e sua interação em uma escala de tempo, focalizando as condições que mudam no decorrer desse período.
Também se utiliza de elementos para sua representação: De estrutura:
30
Classe Classe ativa Interface Componente Colaboração Nó (cubo) - objeto físico em tempo de execução que representa um recurso computacional, possuindo, geralmente, pelo menos uma memória, bem como, uma capacidade de processo. Objetos em tempo de execução e componentes podem residir em nó. Graficamente, um Nó é representado pelo desenho de um Cubo.
http://www.macoratti.net/vb_uml2.htm
60
TI para concursos
De comportamento: Casos de uso Iteração Máquina de estados
De agrupamento:
Pacote Modelo Subsistema Framework
De anotação: Notas
De relacionamentos Associação (bidirecional ou unidirecional) Generalização Composição
5.3
GED - Gerenciamento Eletrônico de Documentos e Workflow31 GED é definido como a "tecnologia que facilita o armazenamento, localização e recuperação de informações estruturadas ou não, em formato digital, durante todo o seu ciclo de vida". De forma geral, essas soluções são compostas pelos módulos de Document Imaging, COLD/ERM e Document Management: Document Imaging (DI) – Gerenciamento de Imagens: esse módulo é responsável pela transformação do documento papel em uma imagem digital, permitindo a sua manipulação nesse ambiente. Esse processo abrange três etapas: a digitalização do documento por meio de um scanner, seu armazenamento (gravação em CD-ROM, DVD, Disco Óptico ou Disk Array) e o gerenciamento (consultas, pesquisas etc.) das informações em meio digital.
COLD/Enterprise Report Management - Gerenciamento de Relatórios Corporativos: COLD (Computer Output to Laser Disk) substitui a tecnologia COM (Computer Output to Microfilm) como forma de armazenar grandes volumes de dados provenientes de sistemas computadorizados (arquivos spool). Em vez de serem impressos, os relatórios são gravados em mídia magnética/óptica e disponibilizados aos usuários, para consulta, no vídeo, por meio de um visualizador próprio. Document Management (DM) – Gerenciamento de Documentos: tem por objetivo o controle e armazenamento de documentos produzidos por programas de computador, tais como: Word, Excel, PowerPoint etc. Uma funcionalidade interessante de módulos desse tipo é a utilização de serviços de biblioteca que possibilitam o controle das diversas versões de um documento. Com o crescimento da Internet, surgiu o termo Web Content Management (WCM), que trata do gerenciamento do conteúdo de informações e o que o diferencia do DM, da publicação desse conteúdo na Web. Uma vez organizada a informação na empresa, precisamos conhecer o fluxo do processo do negócio, em outras palavras, o seu Workflow. Este é um conceito antigo que sempre existiu nas organizações. A novidade está na automação do controle do fluxo dos processos e o Workflow funciona como elemento aglutinador das ações pontuais de cada uma das etapas dos processos. O foco principal reside em saber quem fez que parte do trabalho, em que ordem e sob quais condições (os 3Rs do Workflow – Routes /Rotas, Roles/Papéis e Rules/ Regras). Para sua utilização é primordial que o trâmite de documentos, com as etapas e atividades envolvidas, esteja completamente sistematizado. Podemos conceituar Workflow como o elemento responsável por gerenciar o fluxo dos processos da empresa permitindo um controle automático de tarefas, eventos e prazos, com o intuito de atingir os objetivos do negócio. As diversas soluções de Workflow podem ser grupadas nas seguintes classes: Produção: processos de missão crítica de relevante valor agregado, com alto grau de estruturação nas regras de roteamento, controle e acompanhamento e com volume significativo de ocorrências repetitivas.
31
http://www.serpro.gov.br/imprensa/publicacoes/tematec/2001/ttec57
61
TI para concursos
Colaborativo: coordenação das atividades de um grupo de pessoas, trabalhando juntas para a execução de um projeto, porém com regras e fluxos de baixo grau de estruturação. Administrativo: processos administrativos com baixo valor agregado ao negócio e orientados para o roteamento de formulários e de documentos com baixo grau de estruturação. Ad-hoc: processos eventuais com regras e fluxos com baixo grau de estruturação. Enquanto em um sistema tradicional o trâmite do processo necessita de intervenção humana, ou seja, é passivo, em um sistema de Workflow isso é realizado de forma automática. Para tal, os sistemas de Workflow, independente de sua classe, abrangem diversas funções, dentre as quais podemos destacar: Seqüenciamento: controle da seqüência de execução das diversas atividades do processo; Controle de Tempo: estabelecimento de limites de tempo para a realização das tarefas; Roteamento: caminhos alternativos de execução das tarefas (seqüencial, paralelo e condicional); Atribuição de Papéis: capacidade de rotear uma ação para um papel/perfil de usuário quando uma condição for satisfeita ou um prazo se esgotar; Monitoramento: facilidade de acompanhar a situação das tarefas e o trâmite das ações tomadas no processo. Os principais pontos positivos do uso dessas soluções são: o aumento de produtividade, a redução de custo com papel, o aumento da segurança devido à eliminação do trâmite de documentos originais, a redução do espaço de armazenamento, a mobilidade dos arquivos (contingência), a redução do tempo de respostas para acesso às informações e a agilidade no tratamento de exceções (Workflow). No que diz respeito às dificuldades encontradas, elas são referentes a barreiras culturais, à exigência de mudança comportamental dos usuários que não dispõem mais do papel, à falta de sistematização e padronização dos procedimentos da corporação e ao receio do desemprego, principalmente com a implantação de aplicações de Workflow. A utilização da tecnologia de Workflow deve ser considerada na implantação de sistemas tipicamente processuais, cujo trâmite do processo possa ser automatizado, onde haja necessidade de controle do tempo de execução das tarefas e com diversas pessoas participando do processo. O Workflow evoluiu de sistemas que implementavam fluxos de documentos, para funcionar também como integrador. Além disso, existe uma tendência crescente em se utilizar a Web para a entrada de formulários, a distribuição de documentos e o envio de mensagens de alerta por e-mails. Na Internet, onde mecanismos adicionais de segurança são preponderantes, surge a necessidade do uso de criptografia e certificação digital para a execução de determinadas funções do fluxo do processo. O Gerenciamento Eletrônico de Documentos está convergindo para Gerenciamento de Conteúdo Corporativo (Enterprise Content Management), devendo gerir não apenas os documentos da empresa como também os conteúdos provenientes de sistemas legados, bancos de dados, sistemas de imagem, COLD, DM e qualquer outro arquivo digital, através de uma interface única baseada em browser.
5.3.1
62
Exercícios 63.
(ICMS-SP 2009) A tecnologia de armazenamento de relatórios em discos óticos (COLD) envolvida no GED é 63 tratada como sinônimo de (a) DI – Document Imaging. (b) DM – Document Management. (c) FP – Forms Management. xx (d) ERM – Enterprise Report Management. (e) RIM – Records and Information Management.
64.
(ICMS-SP 2009) Workflow é uma tecnologia aplicada no GED que está diretamente envolvida com (a) KM. xx (b) BPM. (c) ERP. (d) CRM. (e) SCM.
64
TI para concursos
5.4
Arquitetura Orientada a Serviço (SOA) Service-oriented architecture (SOA) é um estilo de arquitetura de software cujo princípio fundamental preconiza que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços. Freqüentemente estes serviços são organizados através de um "barramento de serviços" (enterprise service bus, em inglês) que disponibiliza interfaces, ou contratos, acessíveis através de web services ou outra forma de comunicação entre aplicações. A arquitetura SOA é baseada nos princípios da computação distribuída e utiliza o paradigma request/reply para estabelecer a comunicação entre os 32 sistemas clientes e os sistemas que implementam os serviços. Além da perspectiva estritamente técnica, a arquitetura orientada a serviços também se relaciona com determinadas políticas e conjuntos de "boas práticas" que pretendem criar um processo para facilitar a tarefa de encontrar, definir e gerenciar os serviços disponibilizados. A arquitetura orientada a serviços também se insere em um processo de reorganização dos departamentos de tecnologia da informação das organizações, permitindo um melhor relacionamento entre as áreas que dão suporte tecnológico à empresa e as áreas responsáveis pelo negócio propriamente dito, graças a maior agilidade na implementação de novos serviços e reutilização dos ativos existentes.
5.4.1
Serviço Um serviço, do ponto de vista da arquitetura SOA, é uma função de um sistema computacional que é disponibilizado para outro sistema. Um serviço deve funcionar de forma independente do estado de outros serviços, exceto nos casos de serviços compostos (composite services), e deve possuir uma interface bem definida. Normalmente, a comunicação entre o sistema cliente e aquele que disponibiliza o serviço é realizada através de web services.
5.4.2
Processos A Arquitetura Orientada a Serviços pode ser bem representada a partir do seguinte processo, chamado de "find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolidaexecuta". Tal conceito é análogo a "Ciclo de Deming" aplicado aos serviços, que define o ciclo que envolve o planejamento, a execução, o monitoramento e a tomada de ação pró-ativa para a melhoria da qualidade. Esquema adaptado do paradigma "find-bind-execute", tecnicamente falando, o processo preconiza que os provedores de serviços registrem informações em um registro central, com suas características, indicadores, e aspectos relevantes às tomadas de decisões. O registro é utilizado pelo cliente para determinar as características dos serviços necessários, e se o mesmo estiver disponível no registro central, como por exemplo por um catálogo de serviços, o cliente poderá utilizá-lo, sendo este oficializado através de um contrato que enderece este serviço.
5.4.3
Tecnologia O termo "Service-Oriented Architecture" (SOA) ou Arquitetura Orientada a Serviços expressa um conceito no qual aplicativos ou rotinas são disponibilizadas como serviços em uma rede de computadores (Internet ou Intranets) de forma independente e se comunicando através de padrões abertos. A maior parte das implementações de SOA se utilizam de Web services (SOAP , REST e WSDL). Entretanto, uma implementação de SOA pode se utilizar de qualquer tecnologia padronizada baseada em web.
5.4.4
Definições de SOA O SOA coloca a prestação de serviço como eixo de todo o negócio, dando destaque à gestão de serviços e ao cliente.
Serviço - É uma função independente, sem estado (stateless) que aceita uma ou mais requisições e devolve uma ou mais respostas através de uma interface padronizada e bem definida. Serviços podem também realizar partes discretas de um processo tal como editar ou processar uma transação. Serviços não devem depender do estado de outras funções ou processos. A tecnologia utilizada para prover o serviço, tal como uma linguagem de programação, não pode fazer parte da definição do serviço.
Orquestração - Processo de sequenciar serviços e prover uma lógica adicional para processar dados. Não inclui uma representação de dados. 32
http://pt.wikipedia.org/wiki/Service-oriented_architecture
63
TI para concursos
Stateless
Não depende de nenhuma condição pré-existente. Os serviços não devem depender de condições de outros serviços. Eles recebem todas as informações necessárias para prover uma resposta consistente. O objetivo de buscar a característica de stateless dos serviços é possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los em vários fluxos (algumas vezes chamados de pipelines) para executar a lógica de uma aplicação.
Provedor O recurso que executa o serviço em resposta a uma requisição de um consumidor. Consumidor - É quem consome ou pede o resultado de um serviço fornecido por um provedor. Descoberta - SOA se baseia na capacidade de identificar serviços e suas características. Conseqüentemente, esta arquitetura depende de um diretório que descreva quais os serviços disponíveis dentro de um domínio.
Binding - A relação entre os serviços do provedor e do consumidor deve ser idealmente dinâmica; ela é estabelecida em tempo de execução através de um mecanismo de binding.
5.4.5
Web Services Web Service é um componente de software identificado por uma URI – Identificador de Recursos Uniforme, uma cadeia de caracteres compacta usada para identificar ou denominar um recurso na Internet – que independe de implementação ou de plataforma e pode ser descrito, publicado e invocado sobre uma rede por meio de mensagens padrão XML. As mensagens XML são transportadas usando protocolos padrões da Internet. Com web service é possível realizar a integração entre sistemas desenvolvidos em diferentes linguagens e plataforma, e disponibilizar serviços interativos na Web. é uma tecnologia de padrão aberto e padronizada pelo W3C. A arquitetura do Web Service é constituída por três componentes básicos: o servidor de registro (broker server ou service registry) o provedor de serviços (service provider) o solicitante de serviços (service requestor). As interações entre esses componentes são de busca, publicação e interação de operações. Na operação de publicação o provedor publica a descrição do serviço de tal forma que um solicitante possa localizá-la. Na operação de busca o solici-tante obtém a descrição do serviço diretamente ou consulta o servidor de registro procurando pelo tipo de serviço desejado. Essa operação pode ser executada em duas fases distintas: desenvolvimento ou execução. Na operação de interação o solicitante chama ou inicia uma interação com o provedor, em tempo de ex-ecução, utilizando os detalhes contidos na descrição do serviço para lo calizar, contactar e chamar o serviço. A figura 26.1 mostra os componentes e a interação entre eles. O provedor de serviços representa a plataforma que hospeda o web service permitindo que os clientes acessem o serviço. O provedor de serviços fornece o serviço e é responsável por publicar a descrição do serviço que provê. O solic-itante de serviços é a aplicação que está procurando, invocando uma interação com o web service, ou seja, requisita a execução de um serviço. O solicitante de serviço pode ser uma pessoa acessando por meio do browser ou uma aplicação realizando uma invocação aos métodos descritos na interface do web service. O servidor de registro é um repositório central que contém a descrição (informação) de um web service, e é por meio do servidor de registro que essas descrições são publicadas e disponibilizadas para localização.
Figura 26.1: Componentes básicos da arquitetura do Web Service Os clientes buscam por serviços no servidor de registro e recuperam informações referentes à interface de comunicação para os web service durante a fase de desenvolvimento ou durante a execução do cliente, denominadas in-teração estática (static bind) e interação dinâmica (dinamic bind), respecti64
TI para concursos
vamente. Na interação estática, o cliente recupera a assinatura do serviço, necessária à codificação. Na interação dinâmica, o cliente recupera os valores de parâmetros e a localização do serviço. O ciclo de vida de um web service compreende quatro estados distintos, figura 26.2: Publicação processo, opcional, por meio do qual o fornecedor do web services dá a conhecer a existência do seu serviço, efetuando o registro do mesmo no repositório do web service; Descoberta processo, opcional, por meio do qual uma aplicação cliente toma conhecimento da existência do web services pretendido pesquisando num repositório UDDI; Descrição processo pelo qual o web service expõe a sua API (documento WSDL). Desta maneira a aplicação cliente tem acesso a toda a interface do web service, onde encontram descritas todas as funcionalidades por ele disponibilizadas; Invocação (Mensagens) processo pelo qual o cliente e o servidor interagem, por meio do envio de mensagens; A conjugação desses quatro estados permite constituir o ciclo de vida de um web service: O fornecedor constrói o serviço utilizando a linguagem de programação que entender; De seguida, especifica a interface/assinatura do serviço que definiu em WSDL; Após a conclusão dos dois primeiros passos, o fornecedor registra o serviço no UDDI; O utilizador (aplicação cliente) pesquisa num repositório UDDI e encontra o serviço; A aplicação cliente estabelece a ligação com o web service e estabelece um diálogo com este, via mensagens SOAP.
Figura 26.2: Ciclo de vida do web service A interação entre os web services se dá sob vários protocolos abertos, em diferentes níveis de abstração. Os protocolos utilizados para realizar a comu-nicação são o: UDDI (Universal Description Discovery and Integration), WSDL (Web Services Description Language), XML, SOAP (Simple Object Access Pro-tocol) e o HTTP, conforme figura 26.3.
Figura 26.3: Protocolos de comunicação de Web services As mensagens trocadas são formatadas no protocolo SOAP, o que permite a interoperabilidade entre diferentes plataformas, em um processo denominado serialização XML. Porém, antes que as mensagens SOAP sejam trocadas, suas características são explicitadas por meio de documentos WSDL, que descrevem quais dados estarão sendo trocados, e como estes dados estarão organizados nas mensagens SOAP. Adicionalmente, os serviços dos web services podem ser publicados através de UDDI, que é um formato utilizado para seu armazenamento em repositórios disponíveis na Internet. Assim, se um desenvolvedor precisar resolver uma determinada tarefa, pode encontrar o web service que mais se adequar à sua necessidade. Como os firewalls convencionais e proxies não bloqueiam a porta utilizada pelo protocolo HTTP, não existem grandes restrições para o uso deste tipo de aplicação em redes de longa distância.
65
TI para concursos
Pode-se definir, resumidamente, o web service como sendo um serviço de software disponibilizado na Internet, descrito com um arquivo WSDL, registrado via UDDI, acessado utilizando SOAP e com dados representados em XML sendo transmitidos via HTTP. A disseminação no uso de web services nos últimos anos incentivou o mercado a oferecer uma grande variedade de ferramentas e aplicações para prover suporte a essa tecnologia. Atualmente, as principais plataformas para web services são: Sun Microsystems, IBM, BEA, Apache, Systinet e Microsoft.
5.4.6
SOAP Simple Object Access Protocol é um protocolo leve para troca de informações em um ambiente descentralizado e distribuído que permite comunicação entre aplicações de forma simples e completamente independente de sistema operacional, linguagem de programação ou plataforma. É o protocolo de comunicação para os Web Services. A comunicação é realizada por meio de trocas de mensagens, transmitidas em formato XML, incluindo os parâmetros usados nas chamadas, bem como os dados de resultados. Também pode ser utilizado para invocar, publicar e localizar web services no registro UDDI. Parte da sua especificação é composta por um conjunto de regras de como utilizar o XML para representar os dados. Outra parte define o formato de mensagens, convenções para representar as chamadas de procedimento remoto (RPC – Remote Procedure Calls) utilizando o SOAP, e associações ao protocolo HTTP. O protocolo HTTP é o único protocolo padronizado pelo SOAP, mas existem algumas implementações que suportam outros protocolos como SMTP, TCP/IP, FTP e etc. Uma mensagem SOAP é um fragmento XML bem formado, encapsulado por um par de elementos SOAP. A mensagem SOAP consiste dos seguintes elementos: Envelope toda mensagem SOAP deve contê-lo. é o elemento raiz do do cumento XML. Define o início e o fim das mensagens; Header é um cabeçalho opcional. Ele carrega informações adicionais, como exemplo, se a mensagem deve ser processada por um nó intermediário. Quando utilizado, o Header deve ser o primeiro elemento do envelope; Body é obrigatório e contém o payload, os dados em XML a serem transportados. O elemento Body possui um campo opcional Fault, usado para car-regar mensagens de status e erros retornadas pelos ”nós”ao pro cessarem a mensagem;
Figura 26.4: Estrutura da mensagem SOAP RPCs ou chamadas remotas de procedimento são chamadas locais a métodos de objetos (ou serviços) remotos. Portanto, pode-se acessar os serviços de um objeto localizado em outro ponto da rede, através de uma chamada local a este objeto. Cada chamada ou requisição exige uma resposta. O pro cesso de uma chamada RPC: Antes de serem enviadas pela rede, as chamadas de RPC (emitidas pela aplicação cliente) são encapsuladas (ou serial-izadas) segundo o padrão SOAP. O serviço remoto, ao receber a mensagem faz o processo contrário, desencapsulando-a e extraindo as chamadas de méto do. A aplicação servidora então processa esta chamada, e envia uma resposta ao cliente. O processo então se repete: a resposta é também serializada e enviada pela rede. Na máquina cliente, esta resposta é desencapsulada e é repassada para a aplicação cliente. A especificação SOAP define as seguintes informações, como necessárias em toda chamada de RPC: A URI do objeto alvo; O nome do método; Os parâmetros do método (requisição ou resposta); 66
TI para concursos
Uma assinatura do método opcional; Um cabeçalho (header) opcional.
5.4.7
WSDL O WSDL (Web Services Description Language) é uma linguagem baseada em XML, utilizada para descrever um web service. Um web service deve definir todas as suas interfaces, operações, esquemas de codificação, o conteúdo das mensagens, onde o serviço está disponível e quais os protocolos de comunicação são usados para conversar com o serviço e entre outros neste documento. Um documento WSDL define um XML Schema para descrever um web service. A descrição de um serviço consiste de duas partes: definição de implementação do serviço e definição da interface do serviço. A separação entre as duas camadas permite que elas sejam utilizadas separadamente.
A parte de definição de interface do serviço descreve o web service, incluindo métodos que são invocados e parâmetros que são enviados. A parte de definição de implementação de serviços descreve como uma interface de serviço é im-plementada por um provedor: onde o serviço está instalado e como pode ser acessado. As descrições dos elementos das duas partes: Binding descreve protocolos, formato de data, segurança e outros atributos para uma interface (portType) em particular; Porttype informa elementos de operações do web service; Message define entrada e saída de dados referentes a operações; Type define tipos de dados complexos em uma mensagem; Service contém uma coleção de elementos port com elementos binding; Port é a combinação de um binding com endereço de rede, fornecendo o endereço alvo para a comunicação dos serviços. Tão logo o cliente tenha acesso à descrição do serviço a ser utilizado, a implementação do Web Service pode ser feita em qualquer linguagem de pro-gramação. Normalmente são utilizadas linguagem construídas para interação com a Web, como exemplo Java Servlets ou ASP, que, em seguida, chamam um outro programa ou objeto. Basicamente, quando o cliente deseja enviar uma mensagem para um deter-minado web service, ele obtém a descrição do serviço (através da localização do respectivo documento WSDL), e em seguida constrói a mensagem, passando os tipos de dados corretos (parâmetros, etc) de acordo com a definição encontrada no documento. As duas partes envolvidas em uma interação web service precisam ter acesso à mesma descrição WSDL para conseguirem entender uma à outra. Em seguida, a mensagem é enviada para o endereço onde o serviço está localizado, a fim de que possa ser processada. O web service, quando recebe esta mensagem valida-a conforme as informações contidas no documento WSDL. A partir de então, o serviço remoto sabe como tratar a mensagem, sabe como processá-la (possivelmente enviando-a para outro programa) e como montar a resposta ao cliente.
5.4.8
UDDI Para que um serviço seja utilizado é necessário que o cliente consiga localizá-lo, e essa localização pode ser feita por meio do UDDI (Universal Description, Discovery and Integration), que é uma especificação técnica para descrever, descobrir e publicar web services. Uma implementação de UDDI corresponde a um registro web service, que provê um mecanismo para busca e publicação de web services. Um registro UDDI contém informações categorizadas sobre os serviços e as funcionalidades que eles oferecem, e permite a associação desses serviços com suas informações técnicas, geralmente definidas usando WSDL.
67
TI para concursos
O UDDI possui um componente central chamado UDDI Project, que ma-nipula um registro global e público chamado business registry. A informação oferecida pelo bussines registry consiste de três componentes: white pages, yel-low pages e green pages. A informação fornecida por um registro UDDI pode ser comparada à uma lista telefônica. As páginas brancas (white pages), fornecem informações tais como nome da organização, contato e identificadores. As páginas amarelas (yellow pages) são compostas por um índice de serviços e pro dutos e as páginas verdes (green pages) contém informações a respeito de transações, descrições de serviço e invocação de aplicações. As informações contidas em arquivos de descrição de serviço (WSDL) com-pletam aquelas que estão no registro. No entanto, UDDI não fornece suporte a vários tipos de descrição de serviço, mas não suporta a criação de descrições WSDL de forma direta. Uma descrição WSDL completa consiste da combinação dos documentos de interface e de implementação de serviço. A primeira é publicada no registro UDDI como businessservice e a segunda como tmodel.
5.4.9
Segurança A segurança no envio de mensagens SOAP é um tópico importante. Em um nível mais baixo, mensagens SOAP podem ser trocadas pela rede utilizando HTTPS ao invés de HTTP. Como HTTPS utiliza SSL no seu transporte, fica garantida a proteção contra possíveis intervenções. Além disso, o cliente e servidor podem verificar cada um suas respectivas identidades. Embora HTTPS resolva o problema de proteção das mensagens contra possíveis invasores, este não ajuda muito quando se necessita da segurança necessária para a autenticação de usuários de web services específicos. Estes serviços irão fornecer algum tipo de combinação de usuário/senha durante a fase inicial de registro no serviço e então esta será utilizada para acessos futuros. Não há ainda um padrão de autenticação para Web services, mas pode utilizar os firewalls, VPNs, NTFS, produtos de single-in para oferecer a autenticação e autorização de usuários.
5.4.10
68
Exercícios 65.
(ICMS-SP 2009) Uma vantagem que o Web Service oferece I. em relação à empresa que desenvolve uma DLL é que não precisa distribuí-lo para todos os clientes, pois estará armazenado em um único lugar de onde será acessado. II. é o acesso a ele, sempre por meio de http, mas internamente existe uma string XML que está empacotada em um protocolo SOAP (Simple Object Access Protocol). III. é ser transparente para o Firewall de uma empresa, pois, como é uma string XML, é interpretado como um arquivo "texto", não precisando pedir autorização do Firewall para entrar. 65 Está correto o que consta em xx (a) I, II e III. (b) I e II, apenas. (c) I e III, apenas. (d) II e III, apenas. (e) II, apenas.
66.
(ICMS-SP 2009) Para uma Web Service síncrona, quem chamou a função (a) deve esperar o retorno para prosseguir e, para uma Web Service assíncrona, não precisa esperar o xx retorno, podendo manter mais uma linha de execução no código. (b) deve esperar o retorno para prosseguir e, para uma Web Service assíncrona, não precisa esperar o retorno, não podendo manter mais uma linha de execução no código. (c) não precisa esperar o retorno, podendo manter mais uma linha de execução no código e, para uma Web Service assíncrona, deve esperar o retorno para prosseguir. (d) não precisa esperar o retorno, não podendo manter mais uma linha de execução no código e, para uma Web Service assíncrona, deve esperar o retorno para prosseguir. (e) não precisa esperar o retorno, tal qual para uma Web Service assíncrona, porém, para a forma síncrona pode manter mais uma linha de execução no código e para a forma assíncrona não pode.
66
TI para concursos
5.5
67.
(ICMS-SP 2009) A Service-Oriented Architecture – SOA trata-se de I. um conjunto de produtos para implementar aplicativos dinâmicos e ágeis, do tipo loosely couple. II. uma meta a ser alcançada, ou seja, disponibilizar uma metodologia de implementação que usa padrões e protocolos de linguagem específicos para execução de aplicativos. III. soluções que não requerem uma renovação completa de tecnologia e de processo de negócios, que devem ser incrementais e baseadas nos investimentos atuais. IV. uma abordagem de design de sistemas que orientam como os recursos do TI serão integrados e quais serviços serão expostos para o uso. 67 Está correto o que consta APENAS em (a) I e II. (b) I e IV. xx (c) III e IV. (d) II e III. (e) II e IV.
68.
(ICMS-SP 2009) O Service-Oriented Architecture – SOA tem foco tanto nos negócios quanto em tecnologia 68 da informação, sendo que o SOA com foco em negócios normalmente inclui (a) pessoas, processo e conectividade. xx (b) pessoas, processos e informações. (c) reusabilidade, pessoas e processos. (d) conectividade, processos e informações. (e) conectividade, reusabilidade e informações.
Portais corporativos e colaborativos Um portal é um site na internet que funciona como centro aglomerador e distribuidor de conteúdo para uma série de outros sites ou subsites dentro, e também fora, do domínio ou subdomínio da empresa gestora do portal.33 Na sua estrutura mais comum, os portais constam de um motor de busca, um conjunto, por vezes considerável, de áreas subordinadas com conteúdos próprios, uma área de notícias, um ou mais fóruns e outros serviços de geração de comunidades e um diretório, podendo incluir ainda outros tipos de conteúdos. Para construir um portal é aconselhável utilizar ferramentas de gestão de conteúdo (CMS) em vez de tradicionais editores de HTML. Estes recursos ajudam a concentrar o trabalho num nível mais abstrato, na medida em que alguns aspectos tecnológicos já são automatizados. Uma das vantagens no uso dessas ferramentas é o fato de, na maior parte dos casos, possibilitar a troca do modelo de página sem que o conteúdo e a sua disposição no site sejam alterados; apenas a aparência é modificada. Os Portais Corporativos têm entre suas características, a funcionalidade de oferecer acesso simplificado às informações e às aplicações, por utilizar o ambiente Web como sua camada de apresentação. Desta forma, a interação com o usuário se torna mais amigável e as informações apresentadas de forma mais simples e compreensível. Os Portais podem oferecer acesso a um grande número de colaboradores às informações estruturadas (informações armazenadas em sistemas e bases de dados, como por exemplo, datawarehouses e sistemas legados), assim como às informações não estruturadas (informações armazenadas em arquivos de texto, planilhas eletrônicas, arquivos de e-mail, dentre outros). O acesso a estas informações estruturadas ou não estruturadas se dá na maioria das vezes através do uso de APIs (Application Program Interfaces), também chamadas de applets, portlets, adaptadores ou conectores, sendo o acesso às informações estruturadas mais facilitado, pois através das linguagens de programação pode-se utilizar de APIs que facilitem ao colaborador acessar as informações através de interfaces intuitivas e amigáveis. Já para acessar as informações não estruturadas, é necessário utilizar, em conjunto com as APIs, métodos de categorização e taxonomia, mecanismos de busca. Os métodos de categorização e taxonomia visam organizar as informações, criando informações sobre as informações (metadados) para assim, os mecanismos de busca retornarem as informações que o usuário deseja de forma mais precisa. Em linhas gerais, os Portais Corporativos (como ambiente de integração de informações e sistemas) facilitam a busca por informações nas diversas fontes disponíveis, agiliza a tomada de decisão e pode gerar mais produtividade com a redução no tempo dispendido na procura pelas informações. O termo Portal Corporativo, em relação à internet, começou a ser utilizado para definir os Portais de pesquisa, como Google e Yahoo. Depois de um certo tempo, os provedores de acesso à internet
33
http://pt.wikipedia.org/wiki/Portal_(internet)
69
TI para concursos
passaram a oferecer conteúdo para seus assinantes, na tentativa de ter algum diferencial, já que o acesso discado era “commodity”.34 Existem quatro tipos de portais: Portais Informativos - Portais que levam informações ao usuários; Portais Colaborativos - Portais que habilitam as equipes de trabalho estabelecerem áreas de projetos virtuais ou comunidades através de ferramentas de colaboração; Portais Especialistas - Portais que conectam pessoas com base em suas experiências, interesses e informações que precisam; Portais do Conhecimento - Portais que combinam todas as características dos anteriores para prover conteúdo personalizado com base no que cada usuário faz.. Um Portal Corporativo ou um Enterprise Information Portal é um conceito para um website que serve como interface ou canal único para a informação de uma companhia e sua base de conhecimento para seus colaboradores e, possivelmente, para clientes, parceiros de negócios e também para o público em geral. Para se classificar um software como Portal Corporativo é necessário ter:
Access/search (poderosos sistemas de busca e indexação); Categorization (categorização do conhecimento); Collaboration (aplicações para colaboração); Personalization (cada usuário é um usuário diferente); Expertise and profiling (perfis de acordo com competências); Application integration (integração com demais aplicações); Security (segurança para todas as aplicações e login único).
Outra característica muito comum em um Portal Corporativo, são os Portlets ou Gadgets, que são utilizados para integração de aplicações ou para personalização. Cada Portlet pode ser um “pedaço” de página e nele é possível aplicar configurações de segurança, personalização, etc. Colaboração é a palavra de ordem em Intranets e Portais Corporativos. Um Portal Colaborativo é um portal corporativo com forte exploração de recursos colaborativos, ou seja, de recursos que permitem a colaboração entre funcionários de uma ou mais empresas. Um ambiente de colaboração deve permitir que pessoas que não se conheçam e que mesmo vivam em países diferentes possam trabalhar de forma colaborativa usufruindo de recursos do portal colaborativo. Portlets de Colaboração geralmente estão disponíveis em boas ferramentas de gerenciamento de Intranets e Portais Corporativos. Os mais comuns são: enquetes, forums, chats, workplaces, wikis, dentre outros. Também softwares sociais e comunidades virtuais contribuem para a colaboração corporativa. Os softwares de portais corporativos devem fornecer soluções colaborativas e permitir a integração de aplicativos corporativos que promovam e construam a colaboração corporativa. Um portal corporativo pode ser considerado um portal colaborativo quando o uso de seus recursos colaborativos supera o uso do conteúdo e páginas de conteúdo. O módulo de gerenciamento de conteúdo ou mesmo o gerenciador de conteúdo pode contribuir na produção de conteúdo colaborativo ou pelo menos suportar a colaboração através do gerenciamento de conteúdo aliado aos portlets (componentes) colaborativos.
5.6
Exercícios 69.
34
(ICMS-SP 2009) As ferramentas de modelagem de análise, que utilizam a notação UML, fornecem 69 capacidade de desenvolver modelos baseados em (a) cenários, fluxos e dados. (b) cenários, classes e dados. xx (c) cenários, classes e objetos. (d) classes, fluxos e objetos. (e) classes, fluxos e dados.
http://www.portalcolaborativo.com.br/midias-sociais/home/comunidades-em-portais.html
70
TI para concursos
71
70.
(ICMS-SP 2009) No bloco de back-office da arquitetura de sistema encontram-se os pacotes integrados de gestão empresarial, cujos dados são armazenados nas formas transacionais, com ênfase na integração de 70 processos, identificados pela sigla (a) CRM. (b) SAF. (c) PRM. (d) SCM. xx (e) ERP.
71.
(ICMS-SP 2009) A área de BI – Business Intelligence está diretamente envolvida com os projetos de 71 implementação das aplicações de (a) B2B, B2C e BSC. (b) EAI, B2B e B2C. (c) EAI, CRM e ERP. xx (d) CI, KMS e BSC. (e) CRM, PRM e ERP.
72.
(ICMS-SP 2009) A utilização de ferramentas de groupware e de workflow, cujas informações gerais são apresentadas sob a forma de textos, memorandos, gráficos, e-mails, boletins informativos, páginas Web e 72 arquivos multimídia, caracterizam o tipo de portal de (a) informações empresariais. (b) suporte à decisão. (c) especialista. (d) conhecimento. xx (e) cooperação.
73.
(ICMS-SP 2009) As empresas que implementam portais corporativos por meio dos quais estabelecem relacionamentos de negócios, com um certo nível de acoplamento eletrônico entre os seus sistemas de 73 compras, vendas, logística, distribuição e outros, adotam uma forma de e-Business conhecida por (a) B2C. (b) B2G. xx (c) B2B. (d) C2B. (e) C2C.
74.
(FCC – TRT – SP/2008 - Analista) Na UML, a multiplicidade (a) é aplicada aos atributos, somente. (b) aplicada a uma classe é o número de instâncias que esta pode ter.xx (c) indica a quantidade de atributos herdados por uma classe-filha em uma hierarquia de classes. (d) aplicada nas associações entre classes indica o número de atributos comuns às classes envolvidas. (e) aplicada a uma classe concreta é o número de operações que esta pode ter.
75.
Dos diagramas definidos na UML 2.0, é aplicado na modelagem do comportamento de uma interface, classe 75 ou colaboração, o Diagrama de (a) Componente. (b) Objeto. (c) Estrutura Composta. (d) Pacote. (e) Estado de Máquina.xx
76.
Em (a) (b) (c) (d) (e)
um diagrama de Caso de Uso são admitidos os relacionamentos dependência, somente. dependência e generalização, somente. dependência, generalização e associação.xx associação, somente. dependência e associação, somente.
77.
Em (a) (b) (c) (d) (e)
um Caso de Uso, um relacionamento de inclusão é a estereotipação dos Casos de Uso aos quais se relaciona. de uma Generalização. de uma Extensão. de uma Agregação. xx de um relacionamento de dependência.
78.
No diagrama de casos de uso da UML, o relacionamento de generalização acontece entre (a) atores, somente. (b) casos de uso, somente. (c) casos de uso e entre atores.xx (d) casos de uso e atores, somente. (e) casos de uso incluídos e estendidos, somente.
74
76
77
78
TI para concursos
72
79
79.
Um diagrama de objetos (a) tem a mesma função que um diagrama de atividades diferenciando deste apenas na representação gráfica. (b) capta um conjunto de abstrações como um grupo de interesse e em tal contexto expõe sua semântica e seus relacionamentos com outras abstrações existentes nesse grupo da mesma forma que em um diagrama de classes xx (c) exibe um único conjunto de objetos relacionados uns com os outros em um determinado momento. (d) mostra a seqüência de execução de atividades entre objetos relacionados, no tempo, e a duração de cada objeto por meio de linhas de vida. (e) exibe diversos conjuntos de objetos relacionados uns com os outros em um determinado momento.
80.
Uma propriedade, atributo ou operação representada no diagrama de classes da UML, que poderá ser vista e usada apenas pela classe na qual foi declarada, bem como pelas suas classes descendentes, deve ser 80 definida com visibilidade descrita por meio da palavra-chave (a) package. (b) public. (c) private. xx (d) protected. (e) local.
81.
A representação gráfica de um diagrama de seqüências da UML é baseada em I. uma dimensão horizontal que representa as mensagens trocadas no decorrer de um tempo de vida. II. uma dimensão vertical que representa os objetos participantes das interações. III. mensagens que correspondem a chamadas de serviços ou de operações dos objetos. IV. objetos representados por retângulos alinhados no topo do diagrama, dos quais partem as linhas de vida destes objetos. 81 Está correto o que consta em (a) I, II, III e IV. (b) I, II e IV, apenas. (c) I, II e III, apenas. xx (d) III e IV, apenas. (e) I e II, apenas.
82.
Um cubo, graficamente na UML, é um elemento físico existente em tempo de execução que representa um recurso computacional com pelo menos alguma memória, e, freqüentemente, com capacidade de 82 processamento. Trata-se de (a) pacote. (b) nó.xx (c) interface. (d) objeto. (e) nota.
83.
Na UML um nó é um elemento físico que existe em tempo de execução e representa um recurso 83 computacional. Graficamente, ele é representado por (a) um losango. (b) um cubo.xx (c) um quadrado. (d) uma seta vasada (triângulo). (e) uma elipse.
84.
A identificação do documento XML, como uma mensagem SOAP, está contida no elemento da estrutura 84 SOAP denominado (a) root. (b) body. (c) envelope.xx (d) fault. (e) header.
85.
NÃO é uma informação requerida para invocar um serviço de Web e encapsulada pelo WSDL na forma de 85 um documento XML: (a) O local do serviço. (b) As operações que o serviço apoia. (c) Os parâmetros que o serviço espera. (d) Os detalhes das mensagens do serviço. (e) Os meios para publicar e localizar o serviço.xx
TI para concursos
6
Banco de Dados
6.1
Conceitos básicos Dentre diversas definições, dado é tudo que pode ser processado e as informações são dados que descrevem um domínio físico ou abstrato. Registros são informações produzidas como subprodutos de 35 atividades comerciais ou transações e retidas em virtude do seu valor. Entidade é qualquer coisa do mundo real, abstrata ou concreta, na qual se deseja guardar informações. Atributo é tudo o que se pode relacionar como propriedade da entidade. Domínio é o conjunto de valores possíveis do atributo. Em banco de dados, fisicamente, entidades são tabelas, atributos são as colunas e domínio é o tipo de dado contido na coluna. Um atributo é dito obrigatório quando não puder ter seu valor omitido. Ele é identificador quando for capaz de identificar uma linha única da tabela, caso em que é chamado de chave candidata. Uma tabela deve possuir pelo menos uma chave candidata para poder ser gerenciada, caso em que a coluna será chamada de chave primária. Se houver mais do que uma chave candidata, uma deverá ser escolhida para se a chave primária, enquanto que as outras serão chamadas de chaves alternativas. Bancos de dados (ou bases de dados) são conjuntos de registros dispostos em estrutura regular que possibilita a reorganização dos mesmos e produção de informação, usualmente mantido e acessado 36 por meio de um software conhecido como Sistema Gerenciador de Banco de Dados (SGBD). Modelo de dados é forma como os dados são armazenados, que pode determinar a forma como as informações podem ser processadas. O modelo plano ou tabular consiste de tabelas, que são matrizes simples, bidimensionais, compostas por elementos de dados: caracteres, números inteiros, reais etc. Este modelo plano é a base das planilhas eletrônicas. O modelo em rede permite que várias tabelas sejam usadas simultaneamente através do uso de apontadores (ou referências). Algumas colunas contêm apontadores para outras tabelas ao invés de dados. Assim, as tabelas são ligadas por referências, o que pode ser visto como uma rede. Uma variação particular deste modelo em rede, o modelo hierárquico, limita as relações a uma estrutura semelhante a uma árvore (hierarquia - tronco, galhos), ao invés do modelo mais geral direcionado por grafos.
6.2
Modelagem de Dados Relacional No modelo relacional, todos os dados estão guardados em tabelas. Toda sua definição é teórica e baseada na lógica de predicados e na teoria dos conjuntos. Consiste, principalmente, de três componentes: uma coleção de estruturas de dados, nomeadamente relações ou tabelas; uma coleção dos operadores, a álgebra e o cálculo relacionais; uma coleção de restrições da integridade, definindo o conjunto consistente de estados de base de dados e de alterações de estados. As restrições de integridade podem ser dos tipos: domínio – indica os valores possíveis para os dados nulo ou atributo vazio – determina se o valor do dado pode ser indeterminado chave – define uma coluna ou grupo de colunas que caracterizam uma linha única de uma tabela chave primária – chave que identifica uma linha da própria tabela e não pode ter valor repetido nesta chave estrangeira – chave que identifica uma linha de outra tabela, que pode ser repetida nesta, mas deve existir – o que se chama de integridade referencial – e não pode se repetir na outra tabela
Toda informação tem de ser representada como dados e qualquer tipo de atributo (coluna) representa relações entre conjuntos de dados (linhas). As bases de dados relacionais permitem aos utilizadores (incluindo programadores) escreverem consultas (queries) que não foram antecipadas por quem projetou a base de dados. Como resultado, bases de dados relacionais podem ser utilizadas por várias aplicações em formas que os projetistas originais não previram, o que é especialmente importante em bases de dados que podem ser utilizadas durante décadas. Isto tem tornado as bases de dados relacionais muito populares no meio empresarial.
35
http://pt.wikipedia.org/wiki/Informa%C3%A7%C3%A3o
36
http://pt.wikipedia.org/wiki/Banco_de_dados
73
TI para concursos
6.2.1
Normalização A normalização de dados é uma série de passos que se segue no projeto de um banco de dados que permite um armazenamento consistente e um eficiente acesso aos dados em um banco de dados relacional. Esses passos reduzem a redundância de dados e as chances dos dados se tornarem 37 inconsistentes. No entanto, muitos SGBDs relacionais não têm separação suficiente entre o projeto lógico da base de dados e a implementação física do banco de dados, e isso tem como conseqüência que as consultas feitas a um banco de dados totalmente normalizado têm um mau desempenho. Nestes casos, usa-se por vezes a desnormalização para melhorar o desempenho, com o custo de menores garantias de consistência. Dizemos que duas colunas de uma tabela têm dependência funcional quando a valor de uma determina o valor da outra. Por exemplo, uma coluna com o número de matrícula e outra com o nome de um aluno. Um número de matrícula só pode corresponder a uma aluno, portanto há dependência funcional entre estas duas colunas. Chamamos de chave a um conjunto de colunas que identifica unicamente cada linha da tabela. No exemplo anterior, o número de matrícula do aluno é campo chave da tabela, supondo não poder haver uma pessoa com dois números de matrícula. Em uma tabela contendo o número de matrícula do aluno, o código da disciplina, a nota e frequência do aluno, as duas primeiras colunas formam uma chave da tabela. Se nossa tabela de exemplo contiver a coluna CPF e RG do aluno, teremos três números que identificam de forma única nosso aluno, três chaves. Dizemos que o número de matrícula, o RG e o CPF são chaves candidatas. Se escolhermos uma delas para identificar o aluno, esta será chamada de chave primária. Tirando as chaves, os demais campos são chamados de descritores. Ao imprimir a lista de notas finais dos alunos, podemos ter: Núm Matrícula
Nome
Núm Disc
Disciplina
123456
Funalo de Tal
12
Matemática
Prova 1 5,0
Prova 2 7,0
Média 6,0
Frequência 95%
123456
Funalo de Tal
13
Português
8,0
9,0
8,5
100%
234567
Cicrano da Silva
12
Matemática
6,0
9,0
7,5
80%
234567
Cicrano da Silva
13
Português
3,0
8,0
5,5
70%
A chave da tabela é composta das colunas Núm Matrícula e Núm Disc. Dizemos que há dependência parcial entre o nome a uma das colunas chave, entre o código e o nome da disciplina também. Poderíamos preferir imprimir a lista sem repetir o nome de cada aluno: Núm Matrícula Nome 123456 Funalo de Tal
234567
Cicrano da Silva
Núm Disc Disciplina
Prova 1 Prova 2 Média Frequência
12 Matemática
5,0
7,0
6,0
95%
13 Português
8,0
9,0
8,5
100%
12 Matemática
6,0
9,0
7,5
80%
13 Português
3,0
8,0
5,5
70%
Onde, para cada linha de um aluno, teríamos uma lista de disciplinas e notas. Dizemos que os campos número de matrícula e nome possuem valores atômicos, um só valor por linha. Os demais campos são chamados de multivalorados, pois são listas de valores para uma mesma linha da tabela. Diz-se que uma tabela num banco de dados relacional está numa certa forma normal se satisfaz certas condições. Considera-se que as bases de dados estão normalizadas se aderirem à terceira forma normal. Primeira Forma Normal (ou 1FN) requer que todos os valores de colunas em uma tabela, sejam atômicos (um número é um átomo, enquanto uma lista ou um conjunto não o são). A normalização elimina grupos repetidos pondo-os cada um em uma tabela separada, conectando-os com uma chave primária ou estrangeira. Por exemplo, pessoas têm diversos números de telefones. Uma tabela conterá as pessoas e outra tabela os telefones, ligadas pelo código da pessoa.
37
http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_de_dados
74
TI para concursos
Segunda Forma Normal (ou 2FN) requer que não haja dependência funcional não-trivial de um atributo que não seja a chave, em parte da chave candidata. Por exemplo, uma tabela de pedidos com o código do pedido, chave primária, código do produto, chave estrangeira, e descrição do produto, campo dependente funcional do código do produto, que não é chave primária. O correto é levar a descrição e código do produto para outra tabela e deixar somente o código do produto na tabela de pedidos. Terceira Forma Normal (ou 3FN) requer não haver dependências funcionais não-triviais de atributos que não sejam chave, em qualquer coisa exceto um superconjunto de uma chave candidata. Por exemplo, uma coluna preço total, que é resultado do produto do valor da coluna quantidade pelo preço unitário e não depende do código do pedido, chave primária. A coluna preço total deve ser eliminada, sendo o valor calculado quando for necessário em relatórios. Forma Normal de Boyce-Codd (ou BCNF) requer que não exista nenhuma dependência funcional não-trivial de atributos em algo mais do que um superconjunto de uma chave candidata. Neste estágio, todos os atributos são dependentes de uma chave, de uma chave inteira e de nada mais que uma chave (excluindo dependências triviais, como A->A). Quarta Forma Normal (ou 3FN) Uma relação está na 4ª forma normal, se está na Boyce-Codd, e se não existem dependências multivalor Forma Normal (ou 3FN) Uma relação está na 5ª forma normal, se está na 4ª FN, e se não existem dependências de junção.
As quarta e quinta formas normais são raras e difíceis de detectar. Frequentemente considera-se que uma relação na 3ª forma normal ou Boyce-Codd está num nível de normalização aceitável.
6.2.2
Etapas de modelagem A construção de modelos relacionais envolve as etapas:38 Modelo conceitual - Representa as regras de negócio sem limitações tecnológicas ou de implementação:
Visão Geral do negócio Facilitação do entendimento entre usuários e desenvolvedores Possui somente as entidades e atributos principais Pode conter relacionamentos n para m.
Modelo Lógico - Leva em conta limites imposto por algum tipo de tecnologia de banco de dados:
Deriva do modelo conceitual Possui entidades associativas em lugar de relacionamentos n:m Define as chaves primárias das entidades Normalização até a 3a. forma normal Adequação ao padrão de nomenclatura Entidades e atributos documentados
Modelo Físico - Leva em consideração limites imposto pelo SGBD (Sistema Gerenciador de Banco de dados) e pelos requisitos não funcionais dos programas que acessam os dados. Características:
6.2.3
Elaborado a partir do modelo lógico Pode variar segundo o SGBD Pode ter tabelas físicas Pode ter colunas físicas
Relacionamentos As tabelas podem ser relacionadas para compor uma consulta de informações, desde que a chave primária de uma seja uma coluna da outra, onde será chamada de chave estrangeira. No modelo lógico, este relacionamento pode se dar de três formas: A chave primária da primeira é chave estrangeira na segunda tabela, de forma que podem haver diversas ocorrências de registros da primeira tabela na segunda, mas para cada linha da segunda tabela só existirá uma linha correspondente na primeira. Chamamos isto de cardinalidade um para ene (1:n). Por exemplo, uma tabela de clientes com o código do cliente e o nome, pode ser relacionada com uma outra tabela de telefones contendo o código do telefone, o código do cliente e o número do telefone. As chaves primárias de duas tabelas podem formar uma terceira tabela, criando uma nova entidade chamada de relacionamento. Assim, diversas linhas da primeira tabela podem se relacionar com outras linhas da segunda, em uma cardinalidade ene para eme (n:m). Por exemplo, uma tabela de
38
http://www.macoratti.net/cbmd1.htm
75
TI para concursos
disciplinas, com o código da matéria e nome, pode se relacionar com uma tabela de alunos, com código do aluno e nome, através de uma terceira tabela de matrículas com os dois códigos. Um aluno pode se matricular em diversas matérias e uma matéria pode ter vários alunos. A chave primária de uma tabela pode compor duas colunas de uma tabela de relacionamento, formando uma auto-relacionamento. Por exemplo, uma tabela de empregados pode se relacionar com ela mesmo através de uma tabela de chefia, com o código do empregado na coluna subordinado e de outro empregado, como chefe do primeiro, na coluna superior.
6.2.4
Transação Conjunto de procedimentos que é executado num banco de dados, que para o usuário é visto como uma única ação. A integridade de uma transação depende de 4 propriedades, conhecidas como ACID. Atomicidade - Todas as ações que compõem a unidade de trabalho da transação devem ser concluídas com sucesso, para que seja efetivada. Qualquer ação que constitui falha na unidade de trabalho e a transação deve ser desfeita (rollback). Quando todas as ações são efetuadas com sucesso, a transação pode ser efetivada (commit). Consistência - Nenhuma operação do banco de dados de uma transação pode ser parcial. O status de uma transação deve ser implementado na íntegra. Por exemplo, um pagamento de conta não pode ser efetivado se o processo que debita o valor da conta corrente do usuário não for efetivado antes, nem vice-versa. Isolamento - Cada transação funciona completamente à parte de outras estações. Todas as operações são parte de uma transação única. O principio é que nenhuma outra transação, operando no mesmo sistema, pode interferir no funcionamento da transação corrente (é um mecanismo de controle). Outras transações não podem visualizar os resultados parciais das operações de uma transação em andamento. Durabilidade - Os resultados de uma transação são permanentes e podem ser desfeitos somente por uma transação subseqüente. Controle de concorrência é um método usado para garantir que as transações são executadas de uma forma segura e segue as regras ACID. Os SGBD devem ser capazes de assegurar que nenhuma ação de transações completadas com sucesso (committed transactions) seja perdida ao desfazer transações abortadas (rollback). Uma transação é uma unidade que preserva consistência.
6.3
Modelo Entidade Relacionamento Modelo de Entidades e Relacionamentos é um modelo abstrato cuja finalidade é descrever, de maneira conceitual, os dados a serem utilizados em um Sistema de Informações ou que pertencem a um domínio. A principal ferramenta do modelo é sua representação gráfica, o Diagrama Entidade Relacionamento. Normalmente o modelo e o diagrama são conhecidos por suas siglas: MER e DER.39 Existem muitas notações para Diagrama de Entidades e Relacionamentos. A notação original foi proposta por Chen e é composta de entidades (retângulos), relacionamentos (losangos), atributos (círculos) e linhas de conexão (linhas) que indicam a cardinalidade de uma entidade em um relacionamento. Chen ainda propõe símbolos para entidades fracas e entidades associativas. Toda a notação moderna tem como característica importante definir a cardinalidade mínima e máxima em uma relação, não utilizar um símbolo especial para relacionamentos, mas sim a linha, e descrever atributos dentro do símbolo de entidades. Diagrama entidade relacionamento é um modelo diagramático que descreve o modelo de dados de um sistema com alto nível de abstração. Ele é a principal representação do Modelo de Entidades e Relacionamentos. É usado para representar o modelo conceitual do negócio. Uma relação entre duas tabelas é chamada de binária, três tabelas de ternária, enquanto que um autorelacionamento, em que uma entidade se relaciona com ela mesma, é também chamado de relação unária. Os tipos de relações utilizadas neste diagrama são: Relação 1..1 (lê-se relação um para um) - indica que as tabelas têm relação unívoca entre si. Você escolhe qual tabela vai receber a chave estrangeira; Relação 1..n (lê-se um para muitos) - a chave primária da tabela que tem o lado 1 vai para a tabela do lado N. No lado N ela é chamada de chave estrangeira;
39
http://pt.wikipedia.org/wiki/Modelo_de_Entidades_e_Relacionamentos
76
TI para concursos
Relação n..n (lê-se muitos para muitos) - quando tabelas têm entre si relação n..n, é necessário criar uma nova tabela com as chaves primárias das tabelas envolvidas, ficando assim uma chave composta, ou seja, formada por diversos campos-chave de outras tabelas. A relação então se reduz para uma relação 1..n, sendo que o lado n ficará com a nova tabela criada.
6.4
Modelagem de Dados Multidimensional Na modelagem multidimensional os dados são de-normalizados e estruturados em diversas dimensões.40 A finalidade de bases de dados multidimensionais (alguns autores chamam de dimensionais) é fornecer subsídio para realização de análises. Para tanto, sua arquitetura e terminologia empregada são distintas das utilizadas para bancos de dados transacionais. O fato de existirem diversas informações a serem cruzadas (dimensões) permite a realização de pesquisas. As análises sobre dados históricos envolvem uma série de possibilidades de cruzamentos e agrupamentos de informações, com o uso dos seguintes termos: Dimensões: estabelecem a organização dos dados, determinando possíveis consultas/cruzamentos. Por exemplo: região, tempo, canal de venda,... Cada dimensão pode ainda ter seus elementos, chamados membros, organizados em diferentes níveis hierárquicos. A dimensão tempo, por exemplo, pode possuir duas hierarquias: calendário gregoriano (com os níveis ano, mês e dia) e calendário fiscal (com os níveis ano, semana e dia); Medidas: são os valores a serem analisados, como médias, totais e quantidades; Fatos: são os dados a serem agrupados, contendo os valores de cada medida para cada combinação das dimensões existentes. O tamanho da tabela que contém os fatos merece atenção especial do analista; Agregações: totalizações calculadas nos diversos níveis hierárquicos. Esta forma de armazenamento é conhecida como ROLAP, ou Relational OLAP. Uma vez que os dados já se encontram em um modelo apropriado, chamado multidimensional, basta processar as agregações. Com isso obtém-se ganho de espaço de armazenamento, uma vez que os dados permanecem apenas na base de origem (multidimensional), embora a criação de grandes quantidades de agregações possa incorrer em explosão de dados. Outra forma de armazenamento, cujo modelo matemático denomina-se hipercubos, apresenta a característica de possuir armazenamento e indexação em estruturas de dados que otimizam consultas ao invés de atualizações. Esta forma é erroneamente chamada MOLAP, ou Multidimensional OLAP. O erro está no fato de que bases ROLAP também são multidimensionais. Quando o modelo multidimensional é processado, nova base é gerada, desta vez contendo tanto os dados quanto as agregações em formato próprio, utilizando-se de estruturas apropriadas para pesquisas. Aplicações analíticas possuem peculiaridades tais como manipulação de grandes volumes de dados e baixa taxa de atualização. Essas características favorecem este modelo estrutural, mais rápido. Por exemplo, Business Intelligence (BI) é um processo de gerenciamento de informações que pode ser obtido por qualquer artefato, seja tecnológico ou não, que permita a extração de conhecimento a partir de análises do negócio. A efetividade destas análises será maior se os dados estiverem disponíveis de modo consistente e, preferencialmente, consolidado. 41 Soluções informatizadas de BI geralmente contém sistemas analíticos, que podem ser de diversos tipos, dependendo do objetivo das análises e do perfil do usuário: Decision Support Systems (DSS), ou Sistemas de Apoio a Decisão (SAD): são baseados em relatórios analíticos, normalmente utilizados por usuários de nível operacional; Management Information Systems (MIS), ou Sistemas de Informações Gerenciais (SIG): permitem análises mais profundas, com a realização de simulações de cenários. São utilizados por analistas de negócio no nível tático; Executive Information Systems (EIS), ou Sistemas de Informações Executivas (SIE): são voltados para profissionais que atuam no nível estratégico das empresas, como diretores e presidência. Oferecem, para tanto, um conjunto de indicadores chave de desempenho (KPI, ou Key Performance Indicators).
40
http://pt.wikipedia.org/wiki/Modelagem_multidimensional
41
http://msdn.microsoft.com/pt-br/library/cc518031.aspx
77
TI para concursos
A Microsoft desenvolveu uma ferramenta em SQL Server, o MDX (Multidimensional Expressions), que permite que você consulte objetos multidimensionais, como cubos, e retorna conjuntos de células multidimensionais que contêm dados do cubo.
6.4.1
Sistemas Transacionais X Sistemas Analíticos Sistemas transacionais, também conhecidos como sintéticos ou ainda OLTP – Online Transactional Processing - são baseiados em transações. Por exemplo, Sistemas Contábeis, Aplicações de Cadastro, Sistemas de Compra, Estoque, Inventário, ERPs, CRMs etc. Os sistemas transacionais se caracterizam pela alta taxa de atualização, grande volumes de dados e acessos pontuais, ou seja, pesquisas cujo resultado seja de pequeno volume. Já os sistemas analíticos, ou OLAP – Online Analytical Processing – se caracterizam por fornecer subsídio para tomadas de decisão, a partir de análises realizadas sobre bases de dados históricas, por vezes com milhões de registros a serem totalizados. As atualizações não precisam ser tão freqüentes. As análises geralmente agrupam informações, sendo tais agrupamentos mais importantes neste contexto do que os dados detalhados. As ferramentas OLAP (do inglês, Online Analytical Processing) são geralmente desenvolvidas para trabalhar com banco de dados denormalizados, embora existam ferramentas que trabalham com 42 esquemas especiais de armazenamento, com dados (informações) normalizados. Essas ferramentas são capazes de navegar pelos dados de um Data Warehouse, possuindo uma estrutura adequada tanto para a realização de pesquisas como para a apresentação de informações. Nas ferramentas de navegação OLAP, é possível navegar entre diferentes níveis de granularidades (detalhamento) de um cubo de dados. Através de um processo chamado Drill o usuário pode aumentar (Drill down) ou diminuir (Drill up) o nível de detalhamento dos dados. Por exemplo, se um relatório estiver consolidado por países, fazendo um Drill down, os dados passarão a ser apresentados por Estados, cidades, bairros e assim sucessivamente até o menor nível de detalhamento possível. O processo contrário, o Drill up, faz com que os dados sejam consolidados em níveis superiores de informação. Outra possibilidade apresentada pela maioria das ferramentas de navegação OLAP é o recurso chamado Slice and dice. Esse recurso é usado para criar visões dos dados por meio de sua reorganização, de forma que eles possam ser examinados sob diferentes perspectivas.
6.5
Conceitos de Datawarehouse e ETL Um Data Warehouse é uma base de dados, geralmente relacional, que consolida as informações empresariais. Sua construção é um processo normalmente moroso e complexo, por diversos fatores, dentre os quais a grande quantidade de dados, diversas fontes de informações com bases heterogêneas e muitas vezes inconsistentes, envolvimento de várias áreas ou departamentos da empresa. Um dos maiores desafios na construção do DW é a extração e consolidação dos dados operacionais, pois:
Pode haver várias fontes; Os dados precisam ser limpos; A granularidade precisa ser ajustada; Pode ser necessário resumir dados; Deve haver valores default e tratamento de NULL; É necessário componente temporal; Os relacionamentos nos dados de entrada precisam ser claros.
Algumas situações comuns entre as fontes de dados:
Mesmos dados, nomes diferentes; Dados diferentes, mesmo nome; Dados exclusivos de uma aplicação; Chaves diferentes, mesmos dados.
Como métodos de construção, existem formalmente dois: Top-down, no qual é realizada a modelagem integral do DW, seguida pelas extrações de dados. A principal vantagem é a criação de um modelo único. O revés fica por conta do maior tempo de projeto; 42
http://pt.wikipedia.org/wiki/OLAP
78
TI para concursos
Bottom-up, onde o foco é em uma área por vez, com o crescimento gradual do DW. A vantagem é a obtenção de resultados a intervalos mais curtos, garantindo muitas vezes sustentação ao projeto. A desvantagem é a maior dificuldade de se consolidar informações entre as diversas áreas. Uma alternativa às estratégias acima, denominada Middle-out, é aproveitar as vantagens de cada uma por meio do desenvolvimento iterativo do DW: O modelo de dados corporativo é o primeiro a ser desenvolvido e é o responsável pela integração dos demais; As primeiras tabelas da área de interesse escolhida são povoadas: primeiras análises; Povoamento de mais tabelas com dados históricos; Alguns dados passam a compor o DW, saindo da base operacional; Surgimento dos data marts (a seguir nesta seção); O ciclo se repete até que o DW esteja completo. Bases de produção contêm apenas dados operacionais.
Outro fator crítico para o sucesso de um DW é o gerenciamento do volume. Embora o conceito de DW se aplique a grandes quantidades de dados, chegando atualmente a ordem de TB, sua capacidade não é infinita, devendo ser utilizada sabiamente. Apenas dados relevantes deveriam constar do DW. Pode ser que o horário de uma determinada transação seja importante quando o foco for o curto prazo, mas que apenas um contexto de agrupamento seja suficiente para dados de cinco anos atrás. Questões como essa devem ser consideradas durante o planejamento do DW, pois ajudam a dimensioná-lo. A remoção de dados do DW é um assunto tratado com receio pelos DBAs e pelos analistas de negócio. A rigor, tão importante quanto saber que dados armazenar, é saber quando e quais dados remover do DW. Algumas estratégias são: Resumir dados mais antigos; Armazenar os dados antigos em meio mais barato (fita); Remover os dados do DW. Tais estratégias não são excludentes, podendo ser utilizadas em conjunto. A importância da remoção de dados está em manter o DW o mais enxuto possível, embora isso possa parecer contraditório ao conceito de DW. Com relação à granularidade, as bases de dados operacionais trabalham com o maior nível de detalhe possível, ou seja, a maior granularidade. Já no DW pode haver diversos graus de agregação e resumo dos dados. Por exemplo, os dados do ano corrente podem ser detalhados por item de pedidos, de um a cinco anos, por total de cada pedido e, após isso, por total de pedidos por dia. A correta determinação da granularidade exerce papel fundamental no planejamento de capacidade e desempenho do DW. Ao contrário do que ocorre com as bases operacionais, o DW, por conter dados históricos, não demanda alta taxa de atualização. Desse modo, pode ser atualizado a cada 24 horas ou até mesmo uma vez por semana. Além disso, por sofrer poucas modificações, e de forma controlada (por aplicações específicas para esse fim), seus relacionamentos podem ser implementados através de entidades, embora isso não seja freqüente. Data Marts (DM), são bancos de dados multidimensionais específicos por área de negócio para realização de análises. Alguns conceitos sobre Data Marts não estão muito bem claros para o mercado.
79
TI para concursos
Um DW construído iterativamente possui porções agrupadas por segmento de negócio, região ou qualquer outra forma que seja adequada à empresa. Essas porções alimentam os Data Marts, que podem ser então consultados por ferramentas de análise.
6.5.1
ETL Extract, Transform and Load (Extração, Transformação e Carga) são ferramentas de software cuja função é a extração de dados de diversos sistemas, transformação desses dados conforme regras de negócios e carga dos dados em um data mart ou um data warehouse. É considerada uma das fases mais críticas do Data Warehouse e/ou Data Mart. Os projetos de data warehouse consolidam dados de diferentes fontes. A maioria dessas fontes tendem a ser bancos de dados relacionais ou flat files (texto plano), mas podem existir outras fontes. Um sistema ETL tem que ser capaz de se comunicar com as bases de dados e ler diversos formatos de arquivos utilizados por toda a organização. Essa pode ser uma tarefa não trivial, e muitas fontes de dados podem não ser acessadas muito facilmente. Existem ferramentas ETL, mas ETL não são ferramentas, mas sim uma metodologia.
6.6
Conceitos de desenvolvimento em banco de dados SQL Server e Oracle
6.6.1
SQL Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL, é uma linguagem de pesquisa declarativa para banco de dados relacional (base de dados relacional). Muitas das características originais do SQL foram inspiradas na álgebra relacional.43 Uma consulta SQL especifica a forma do resultado e não o caminho para chegar a ele. Padronizado pela ANSI e ISO, possui muitas variações e extensões produzidos pelos diferentes fabricantes de sistemas gerenciadores de bases de dados. Tipicamente a linguagem pode ser migrada de plataforma para plataforma sem mudanças estruturais principais. O padrão do SQL (ANSI) utiliza operadores, funções de agregação e comandos, que dividem-se em cinco subconjuntos. Os comandos podem ser escritos e executados por linhas de comando dentro de algum aplicativo do próprio gerenciador de banco de dados, por lotes de comandos definidos dentro do banco de dados (procedures) ou lotes de comandos por qualquer aplicativo com conexão com o banco de dados. A Microsoft oferece o MS SQL Server e a Oracle seu gerenciador de banco de dados de mesmo nome obedecendo aos padrões ANSI e adicionando mais recursos para administração eficiente de dados.
6.6.1.1
DML - Linguagem de Manipulação de Dados A DML (Data Manipulation Language) é um subconjunto da linguagem usada para inserir, atualizar e apagar dados. INSERT - insere registros (linhas ou tuplas) UPDATE - altera valores de dados DELETE - remove linhas (registros ou tuplas)
6.6.1.2
DDL - Linguagem de Definição de Dados DDL (Data Definition Language) permite definir tabelas e elementos associados. CREATE - cria um objeto (tabela, index, view etc.) dentro da base de dados. DROP - apaga um objeto do banco de dados ALTER TABLE - altera a estrutura de uma tabela, não é aceito por todos os gerenciadores de banco de dados
6.6.1.3
DCL - Linguagem de Controle de Dados DCL (Data Control Language) controla os usuários e direitos de acesso aos objetos dentro do banco de dados. GRANT - autoriza ao usuário executar ou setar operações. REVOKE - remove ou restringe a capacidade de um usuário de executar operações. ALTER PASSWORD - altera senha
43
http://pt.wikipedia.org/wiki/SQL
80
TI para concursos
CREATE SYNONYM - cria sinônimos, nomes alternativos para os objetos 6.6.1.4
DTL - Linguagem de Transação de Dados DTL (Data Transaction Language) define blocos de comandos – transações – que podem ser efetivados ou não. BEGIN WORK (ou START TRANSACTION) - usado para marcar o começo de uma transação. COMMIT - confirma todas as ações, desde o comando begin, permanentemente. ROLLBACK faz com que os comandos de mudanças nos dados sejam descartados. COMMIT e ROLLBACK interagem com áreas de controle como transação e locação. Ambos terminam qualquer transação aberta e liberam qualquer bloqueio ligado a dados. Na ausência de um BEGIN WORK ou uma declaração semelhante, a semântica de SQL é dependente da implementação.
6.6.1.5
DQL - Linguagem de Consulta de Dados DQL (Data Query Langage) possui apenas um comando, para selecionar dados. SELECT - especifica uma consulta ("query") como uma descrição do resultado desejado. Esse comando é composto de várias cláusulas e opções, possibilitando elaborar consultas das mais simples às mais elaboradas. As cláusulas são condições de modificação utilizadas para definir os dados que deseja selecionar ou modificar em uma consulta. FROM - Utilizada para especificar a tabela que se vai selecionar os registros. WHERE – Utilizada para criar uma restrição, isto é, especificar as condições que devem reunir os registros que serão selecionados. GROUP BY – Utilizada para separar os registros selecionados em grupos específicos. HAVING – Utilizada para expressar a condição que deve satisfazer cada grupo, criar uma restrição para o grupo. ORDER BY – Utilizada para ordenar os registros selecionados com uma ordem especifica. DISTINCT – Utilizada para selecionar dados sem repetição. JOIN – utilizada para criar junções entre a tabelas, criando restrições ou atendendo a critérios, e permitindo a seleção de colunas das tabelas envolvidas. O join pode ser definido de diversas formas: Sem a utilização da cláusula join, colocando os nomes das tabela logo depois da clausula from separados por vírgulas, e com uma restrição de relacionamento após a cláusula where.
6.6.1.6
Operadores Lógicos Operadores lógicos relacionam elementos de uma expressão lógica. AND – Avalia os termos e devolve um valor verdadeiro caso ambos sejam corretos. OR – Avalia termos e devolve um valor verdadeiro se algum for correto. NOT – Devolve o valor contrário da expressão.
6.6.1.7
Operadores Relacionais Os operadores estabelecem critérios para uma expressão lógica. < – Menor que > – Maior que <> – Diferente de <= – Menor ou Igual que >= – Maior ou Igual que = – Igual a BETWEEN – Utilizado para especificar um intervalo de valores. LIKE – Utilizado na comparação de um modelo e para especificar registros de um banco de dados."Like" + extensão % vai significar buscar todos resultados com o mesmo início da extensão.
6.6.1.8
Funções de Agregação As funções de agregação, dentro de uma cláusula SELECT com cláusula GROUP BY, devolve valores agregados de um grupo de registros. AVG – calcular a média dos valores de um campo numérico determinado.
81
TI para concursos
6.6.1.9
COUNT – devolve o número de registros da seleção. SUM – devolve a soma de todos os valores de um campo numérico determinado. MAX – devolve o valor mais alto de um campo especificado. MIN – devolve o valor mais baixo de um campo especificado.
Conjuntos de dados Os dados de uma ou mais tabelas podem ser agrupados em um único conjunto de dados através de operações de seleção (select) de diversos tipos: Junção – dois conjuntos de dados são concatenados de acordo com uma determinada condição de relação e seleção. Restrição – condição que limita a seleção das linhas de uma relação. Projeção – uma ou mais colunas de uma relação são selecionadas formando um subconjunto vertical. União – são selecionadas todas as linhas que aparecem em ambas as relações Intersecção – são selecionadas apenas aquelas linhas que existem em ambos os conjuntos.
6.6.1.10 Componentes de um banco de dados Um banco de dados pode apresentar mais do que tabelas e dados em sua estrutura. Pode possuir módulos programados e objetos que melhoram a manipulação dos dados. Tabelas – modelo abstrato de armazenamento de dados em forma de registros e campos em banco de dados relacional. Cada tabela armazena informações de uma entidade modelada do banco de dados. Views - ajuda a encapsular uma consulta em uma entidade relacional e facilita a visão de um dado de uma ou mais tabelas em um banco de dados. Restrição - define regras a respeito de valores permitidos em colunas e é um mecanismo que executa a integridade de dados Índices - oferece rápido acesso ao dado de uma tabela baseado em valores classificados em ordem crescente ou decrescente. A chave primária de uma tabela é automaticamente indexada. Funções - pedaço de código que opera como uma unidade lógica. Uma função pode retornar tanto uma tabela quanto um valor escalar. Qualquer código que deve executar a lógica incorporada em uma função pode chamar a função, em vez de repetir a função lógica. Procedimento (Procedure) – lote (texto) de comandos (código) armazenado no banco de dados. Gatilho (Trigger) - procedimento que é executado quando ocorre um evento qualquer previsto para um registro, campo ou para a própria tabela.
6.6.2
Arquitetura de um Servidor Oracle Um banco de dados Oracle é composto por uma ou mais tablespaces. Uma tablespace contém um ou mais arquivos no nível de sistema operacional. Cada tablespace pode ter um ou mais segmentos. Um segmento é adicionado na tablespace quando uma tabela ou um índice é criado, ou seja, um segmento é associado a cada objeto de banco de dados. é possível que um objeto seja atribuído a mais de um segmento, mas, para isso, o usuário deverá particionar explicitamente o objeto. Várias tabelas ou índices podem ser incluídos em um mesmo segmento através da criação de um objeto conhecido como cluster. A medida que um objeto de banco de dados necessita de mais espaço, é necessário que o segmento aloque mais dados. O banco de dados procura, nos arquivos do tablespace, áreas contíguas de tamanho pré-determinado para o armazenamento de novos dados. Essa área contígua é conhecida como extensão (extent), que por sua vez é formada por diversos blocos de banco de dados. Cada bloco de banco de dados possui um tamanho fixo determinado nos parâmetros de configuração, esse tamanho fixo deve ser múltiplo do tamanho de um bloco do nível do sistema operacional. O tamanho extent também pode ser configurado pelo usuário ou determinado automaticamente pelo Oracle. A criação de um banco de dados pode ser realizada através de uma ferramenta gráfica conhecida como Database Configuration Assistant. Com essa ferramenta também é possível configurar opções de um banco de dados existente, deletar um banco de dados e gerenciar gabaritos de banco de dados. Os tipos de usuários (papéis) variam de acordo com o lugar, mas podem ser divididos em administadores de banco de dados, responsáveis pela segurança, administradores de rede, desenvolvedores de aplicação, administradores de aplicação e usuários do banco de dados.
82
TI para concursos
PL/SQL (Procedural Language/SQL) é uma extensão da linguagem padrão SQL para o Oracle. Permite que a manipulação de dados seja incluída em unidades de programas. Blocos de PL/SQL são passados e processados por uma PL/SQL Engine que pode estar dentro de uma ferramenta Oracle ou do Server. A PL/SQL Engine filtra os comandos SQL e manda individualmente o comando SQL para o SQL Statement Executor no Oracle Server, que processa o PL/SQL com os dados retornados do Server. É a linguagem básica para criar programas complexos e poderosos, não só no banco de dados, mas também em diversas ferramentas Oracle.44 A unidade básica em PL/SQL é um bloco. Todos os programas em PL/SQL são compostos por blocos, que podem estar localizados uns dentro dos outros. Geralmente, cada bloco efetua uma ação lógica no programa. Um bloco tem basicamente a seguinte estrutura: DECLARE Seção (opcional) para declaração de variáveis,tipos e subprogramas locais. BEGIN Seção Executável, nesta seção ficam as instruções procedurais e SQL. Esta é a única seção do bloco que é indispensável e obrigatória. EXCEPTION Seção/Setor (opcional) onde ficam as instruções de tratamento de erro. END
6.6.3
Arquitetura de um Servidor SQL Server Um banco de dados no SQL Server 2005 se refere a um grupamento físico de um conjunto de objetos de esquema de um banco de dados em um ou mais arquivos físicos. Os bancos de dados podem ser classificados como bancos de dados de sistemas e bancos de dados dos usuários. Os banco de dados de sistema armazenam dados do sistema e também controlam o armazenamento temporário requerido para os dados de aplicação. Cada instância do SQL Server pode suportar vários bancos de dados. Além disso, pode haver várias instâncias em um mesmo computador. Cada banco de dados pode suportar grupos de arquivos (filegroups), que proveêm a funcionalidade de distribuir os dados fisicamente. Um banco de dados pode possuir vários filegroups, mas o contrário não é possível. Após a criação do banco de dados, os filegroups do banco de dados podem ser adicionados. O SQL Server utiliza a unidade básica de IO fixo (página) em 8KB. Para organizar melhor os dados, essas páginas são agrupadas em uma quantidade de oito contíguas entre si formando as chamadas extensões (extents). O espaço é gerenciado em termos de extensões. Cada página pertence a um objeto de um tipo (dado, índice etc), mas uma extensão pode pertencer a vários objetos. Uma extensão em que as oito páginas pertencem ao mesmo objeto é considerada uma extensão uniforme, caso contrário, trata-se de uma extensão mista. O SQL Server utiliza os filegroups para controlar a alocação das tabelas e dos índices. Os dados contidos em filegroup são proporcionalmente distribuídos entre os arquivos do filegroup. Se os filegroups não estiverem definidos, os objetos do banco de dados serão armazenados em um filegroup padrão que é implicitamente definido durante a criação do banco de dados. Os segmentos utilizados no Oracle não são necessários no SQL Server. Em vez disso, o SQL Server distribui os dados através de RAID suportado em hardware ou software (solução presente no Windows ou em outro software).
44
http://pt.wikipedia.org/wiki/PL/SQL
83
TI para concursos
6.7
84
Exercícios 86.
(ICMS-SP 2009) A arquitetura ANSI/SPARC aplicada aos bancos de dados divide-os em níveis com as seguintes características: I. O que se ocupa do modo como os dados são fisicamente armazenados. II. O que se ocupa do modo como os dados são vistos por usuários individuais. III. Nível lógico de comunidade ou apenas lógico (mais abstrato que o físico e diferente da visão do usuário individual). 86 Em um projeto arquitetural, os itens I, II e III são classificados, respectivamente, como níveis (a) externo, conceitual e interno. (b) externo, interno e conceitual. xx (c) interno, externo e conceitual. (d) interno, conceitual e externo. (e) conceitual, externo e interno.
87.
(ICMS-SP 2009) A independência de dados física e a independência de dados lógica são possibilitadas de 87 forma ideal, respectivamente, por um (a) ou mais mapeamentos conceituais/internos e por um ou mais mapeamentos internos/externos. xx (b) mapeamento conceitual/interno e por um ou mais mapeamentos externos/conceituais. (c) mapeamento interno/externo e por um mapeamento conceitual/interno. (d) ou mais mapeamentos internos/externos e por um mapeamento conceitual/interno. (e) mapeamento conceitual/externo e por um mais mapeamentos conceituais/internos.
88.
(ICMS-SP 2009) O procedimento em que se aplicam os ajustes apropriados na organização do sistema de banco de dados, principalmente na ocorrência das mudanças de requisitos, visando à manutenção constante 88 do melhor desempenho para a empresa, é denominado (a) schema. (b) dumping. (c) mapping. (d) restart. xx (e) tuning.
89.
(ICMS-SP 2009) No ambiente de desenvolvimento com SQL Server, uma sintaxe usada para definir objetos multidimensionais, bem como para examinar e manipular dados multidimensionais, corresponde à 89 linguagem xx (a) MDX. (b) RDL. (c) WQL. (d) XSL. (e) SMDL.
90.
(ICMS-SP 2009) Uma assinatura criada e administrada pelo Publicador, com SQL Server, trata-se de uma 90 assinatura (a) pull. xx (b) push. (c) anônima. (d) de cliente. (e) de servidor.
91.
(ICMS-SP 2009) No SQL Server, uma única dimensão de banco de dados unida à tabela de fatos em uma 91 chave estrangeira diferente, para produzir várias dimensões de cubo, é denominada dimensão (a) de fatos. (b) de referência. (c) compartilhada. xx (d) com função múltipla. (e) muitos para muitos.
92.
(ICMS-SP 2009) No formato de um bloco de dados do Oracle, um overhead é uma referência ao (a) Header. (b) Space free. (c) Table directory. (d) Space free e Row data, coletivamente. xx (e) Header, Table directory e Row directory, coletivamente.
93.
(ICMS-SP 2009) NÃO é um conjunto de extensões do Oracle que contém todos os dados para uma estrutura 93 lógica de armazenamento dentro de uma tablespace: (a) Automatic Undo Management. xx (b) Automatic Storage Management. (c) Temporary Segments. (d) Index Segments. (e) Data Segments.
92
TI para concursos
85
94
94.
(ICMS-SP 2009) Um database Oracle é constituído de um ou mais (a) datafiles, estruturas físicas de armazenamento, e cada datafile consiste de um ou mais tablespaces, unidades lógicas de armazenamento. (b) datafiles, unidades lógicas de armazenamento, e cada datafile consiste de um ou mais tablespaces, estruturas físicas de armazenamento. (c) tablespaces, unidades lógicas de armazenamento, e cada tablespace consiste de um ou mais datafiles, xx estruturas físicas de armazenamento. (d) tablespaces, estruturas físicas de armazenamento, e cada tablespace consiste de um ou mais datafiles, unidades lógicas de armazenamento. (e) tablespaces, unidades lógicas de armazenamento, e cada tablespace consiste de um ou mais datafiles, também unidades lógicas de armazenamento.
95.
(ICMS-SP 2009) Considere a seguinte regra de Codd, aplicada aos bancos de dados relacionais: A descrição do banco de dados é representada no nível lógico da mesma forma que os dados ordinários, permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares. 95 O sentido dessa regra diz respeito à xx (a) formação do catálogo. (b) manipulação, por meio de visões. (c) independência física. (d) independência lógica. (e) independência de distribuição.
96.
(ICMS-SP 2009) Considere a afirmativa a seguir. Uma tabela está na I , se e somente se ela estiver na II e os atributos não-chave forem III . 96 I, II e III podem ser corretamente preenchidos por: (a) FNBC, 1FN, totalmente dependentes da totalidade da chave primária (b) 3FN, 2FN, independentes da chave primária (c) 3FN, 1FN, totalmente dependentes de parte da chave primária (d) 2FN, 1FN, totalmente dependentes de parte da chave primária xx (e) 2FN, 1FN, totalmente dependentes da totalidade da chave primária
97.
(ICMS-SP 2009) Considere a relação 1:N entre cliente e seus pedidos e a necessidade de exclusão de um determinado cliente. A fim de manter informações históricas sobre pedidos já efetuados, independentemente da existência do cliente que os fez, deseja-se que aqueles pedidos já efetuados pelo cliente excluído não sejam apagados. As chaves primárias de ambas e em cada tabela são definidas como única. Em um banco 97 de dados relacional normalizado até a 3FN, o atendimento de tal requisito pode ser obtido por meio de xx (a) restrição de chave estrangeira on delete set null. (b) colocação de uma constante (ex. ‘9999’) nas chaves primárias dos pedidos do cliente excluído. (c) colocação de uma constante (ex. ‘9999’) nas chaves primárias de cada cliente excluído. (d) não limpeza das chaves estrangeiras dos pedidos, existentes na tabela do cliente. (e) restrição de chave estrangeira on delete cascade.
98.
(ICMS-SP 2009) Em um banco de dados multidimensional, considere, por exemplo, que os dados podem ser representados como um array de três dimensões, correspondendo a produtos, clientes e períodos de tempo. Dessa forma, um determinado valor individual em uma célula pode representar a quantidade de um produto 98 vendido a um cliente em um dado momento. De acordo com essa consideração, (a) produtos e clientes são variáveis independentes, e períodos de tempo e quantidade são variáveis dependentes. (b) produtos, clientes e períodos de tempo são variáveis dependentes, e quantidade é uma variável independente. (c) produtos, clientes e períodos de tempo são variáveis independentes, e quantidade é uma variável xx dependente. (d) produtos são variáveis dependentes, e clientes, períodos de tempo e quantidade são variáveis independentes. (e) produtos são variáveis independentes, e clientes, períodos de tempo e quantidade são variáveis dependentes.
99.
(ICMS-SP 2009) As variáveis dimensionais aplicadas em um MOLAP estão frequentemente relacionadas em hierarquias, que determinam meios para agregar dados das células a elas associados. Nesse contexto, os operadores do processador que permitem percorrer (para acesso e não para criação) as hierarquias do nível 99 de agregação mais baixo para o mais alto executam a função (a) snow flake. (b) roll back. (c) drill down. (d) rolap. xx (e) drill up.
TI para concursos
100. (ICMS-SP 2009) Se uma empresa de grande porte, com alto volume de transações e informações, resolver iniciar um projeto usando o conceito de Data Mart (DM) em vez de Data Warehouse (DW), independentemente disso ser ou não a melhor opção, os fatores que a levam a tal decisão podem ser justificados por: I. Possibilidade de extrair e preparar os dados diretamente de fontes de interesse específicas, fornecendo acesso mais rápido pela não necessidade de sincronia com dados de outras fontes. II. Menor risco quanto ao sucesso do projeto. III. Necessidade imediata de informações organizacionais integradas. 100 Está correto o que consta em (a) I, apenas. xx (b) I e II, apenas. (c) I e III, apenas. (d) I, II e III. (e) II e III, apenas. 101. O grande desafio do profissional de TI que gerencia qualquer processo é a análise dos fatos relacionados à função que exerce em uma organização. Essa análise deve ser feita com as ferramentas e os dados disponíveis, permitindo aos executivos e gerentes detectar as tendências e tomar as decisões com eficiência e eficácia. Devido a essa necessidade, surgiu o conceito de Business Intelligence – “BI”. 101 Assinale a alternativa que indique duas características dos atuais sistemas de Business Intelligence. (a) procurar relações de causa e efeito / extrair e integrar dados de múltiplas fontes.xx (b) evitar a utilização de ferramentas automatizadas / desprezar dados contextualizados. (c) extrair e integrar dados de múltiplas fontes / evitar a utilização de ferramentas automatizadas. (d) desprezar dados contextualizados / trabalhar exclusivamente com fatos reais e não hipotéticos. (e) trabalhar exclusivamente com fatos reais e não hipotéticos / procurar relações de causa e efeito. 102. (TRT FCC 2008) No âmbito do OLAP, gráficos de produtos são generalizações da estrutura de ...... apresentada por HRU (Harinarayan, Rajaraman e Ullman), na qual as dimensões podem ter hierarquias 102 associadas. Preenche corretamente a lacuna: (a) tabela. (b) roll-up. (c) data mart. xx (d) hipercubo. (e) drill-down. 103. Uma das funcionalidades do OLAP, utilizada para realizar operações de projeção nas dimensões, compreende a extração de informações sumarizadas de um cubo de dados e extração de um "subcubo", a 103 partir do valor de uma dimensão. Trata-se de (a) sorting. (b) pivot and sorting. (c) drill-up. (d) selection. xx (e) slice and dice. 104. Para eliminar a condição de existência de valores não atômicos em uma coluna de tabela relacional, (a) deve ser aplicada, no mínimo, a primeira Forma Normal.xx (b) devem ser aplicadas, no mínimo, as quatorze regras de Codd. (c) deve ser aplicada, no mínimo, a Forma Normal Boyce-Codd. (d) deve ser aplicada, no mínimo, a terceira Forma Normal. (e) devem ser aplicadas, no mínimo, as regras de integridade referencial. 105. Um (a) (b) (c) (d) (e)
banco de dados relacional normalizado significa que as relações que o compõe atendem à 1FN, no máximo. xx 3FN, no mínimo. 2FN, mas não necessariamente 1FN. 2FN, no máximo. 3FN, mas não necessariamente a 1FN e 2FN.
105
106
106. Uma relação estará na Segunda Forma Normal (2FN) se ela estiver na 1FN e todos os atributos (a) não chave forem dependentes não transitivos da chave primária. xx (b) não chave forem totalmente dependentes da chave primária. (c) chave forem dependentes não transitivos das chaves estrangeiras. (d) chave forem totalmente dependentes das chaves estrangeiras. (e) chave forem totalmente dependentes dos atributos não chave. 107. Em (a) (b) (c) (d) (e)
86
107
um modelo E-R, o tipo de associação unária é aquela em que uma entidade se relaciona unicamente com uma outra entidade. uma entidade se relaciona com ela própria.xx uma entidade não se relaciona com qualquer outra entidade, nem com ela própria. um relacionamento é do tipo 1:1, somente. um relacionamento é do tipo 1:1 ou N:1.
104
TI para concursos
108. Sobre um modelo E-R, considere que uma chave primária I. simples pode ser constituída de um atributo atômico ou de um atributo composto. II. simples pode ser constituída de apenas um atributo atômico. III. composta pode ser constituída de um atributo composto. IV. composta pode ser constituída de dois ou mais atributos atômicos. 108 Está correto o que consta APENAS em (a) III e IV. (b) II e III. (c) II e IV. (d) I e II. xx (e) I e IV. 109. Um sistema de informação que fornece um arquivo para ser tratado pelo sistema objeto da modelagem, 109 utilizando DFD da análise estruturada, é caracterizado como (a) fluxo de dados. xx (b) entidade externa. (c) depósito de dados. (d) processo funcional do sistema. (e) processo do diagrama de contexto. 110
110. Na modelagem funcional xx (a) uma entidade externa pode enviar ou receber um fluxo de dados de uma função. (b) uma função pode enviar, mas não receber um fluxo de dados de um depósito de dados. (c) uma entidade externa representa a mesma coisa que uma entidade no modelo entidade relacionamento. (d) uma entidade externa pode enviar, mas não receber um fluxo de dados de um depósito de dados. (e) uma entidade externa pode receber, mas não enviar um fluxo de dados a um depósito de dados. 111. Quando dois conjuntos de dados são concatenados de acordo com uma determinada condição, representa o 111 resultado da operação relacional (a) junção.xx (b) união. (c) restrição. (d) projeção. (e) intersecção. 112. Um comando SQL executa uma operação que exibe I. certas colunas de uma relação, denominada subconjunto vertical. II. todas as linhas que aparecem em ambas as relações. III. apenas aquelas linhas que existem em ambos os conjuntos. 112 As definições acima correspondem, respectivamente, aos operadores relacionais (a) união, projeção e intersecção. (b) união, intersecção e projeção. (c) intersecção, projeção e união. xx (d) projeção, união e intersecção. (e) projeção, intersecção e união. 113
113. A linguagem PL/SQL, introduzida nos gerenciadores de banco de dados ORACLE, (a) aumenta a capacidade não-procedural da SQL, oferecendo e combinando blocos de construtores procedurais.xx (b) constitui uma interface básica pela qual pode-se entrar e executar comandos SQL para manipulações genéricas de um banco. (c) trata-se de uma linguagem que identifica quais as informações necessárias e não como buscá-las. (d) tem os seus comandos executados pelo executor de SQL do Kernel. (e) tem os seus comandos enviados para serem processados pelo SGBD um por vez. 114. A linguagem PL/SQL é uma estrutura em blocos, compostos basicamente das partes declarativa, executável 114 e manipulação de exceções, as quais são, respectivamente, de uso (a) opcional, para todas as partes. (b) obrigatório, para todas as partes. (c) opcional, obrigatório e obrigatório. (d) obrigatório, obrigatório e opcional. xx (e) opcional, obrigatório e opcional. 115. Um (a) (b) (c) (d) (e)
87
115
bloco PL/SQL que está associado a um evento ocorrido no banco de dados Oracle é do tipo função. xx gatilho. anônimo. procedimento. dinâmico.
TI para concursos
116. A estrutura lógica de armazenamento nas bases de dados Oracle é representada na seqüência hierárquica 116 de (a) segmentos, blocos de dados e extensões. (b) segmentos, extensões e blocos de dados.xx (c) extensões, segmentos e blocos de dados. (d) extensões, blocos de dados e segmentos. (e) blocos de dados, segmentos e extensões. 117
117. Na estrutura lógica do Oracle NÃO estão contidos (a) extents. (b) data blocks. xx (c) data files. (d) schemas. (e) tablespaces.
118. Todos os dados de uma tabela Oracle são armazenados em extents de um xx (a) data segment. (b) index segment. (c) temporary segment. (d) rollback segment. (e) redlog segment.
118
119
119. Quando um banco de dados Oracle é iniciado, será alocado para os processos background (a) um schema. (b) um ou mais redo log files. (c) um ou mais control files. (d) uma tablespace. xx (e) uma área global de sistema. 120. As cláusulas do comando de consulta da linguagem SQL devem ser escritas na seqüência (a) SELECT, HAVING, FROM, WHERE, GROUP BY e ORDER BY. (b) SELECT, HAVING, FROM, WHERE, ORDER BY e GROUP BY. (c) SELECT, FROM, WHERE, ORDER BY, HAVING e GROUP BY. (d) SELECT, FROM, WHERE, GROUP BY, HAVING e ORDER BY.xx (e) SELECT, FROM, WHERE, GROUP BY, ORDER BY e HAVING.
120
121. Para mostrar a composição de peças e respectivos componentes (peças são compostas de peças), em um 121 DER, usa-se (a) o grau de relacionamento quaternário. (b) a cardinalidade ternária. (c) a entidade fraca. (d) a entidade associativa. xx (e) o auto-relacionamento. 122
122. Um relacionamento pode ser representado graficamente no diagrama de Entidade-Relacionamento por (a) uma elipse. (b) um retângulo. (c) um círculo. xx (d) um losango. (e) números da cardinalidade.
123. Considere, as definições abaixo: I. Especificação do número de ocorrências de um objeto que pode ser relacionado ao número de ocorrências de outro objeto. II. Especificação da participação (ou não) do relacionamento de um objeto em particular. 123 Na modelagem de dados estas definições pertencem, respectivamente, a (a) grau e cardinalidade. (b) cardinalidade e grau. xx (c) cardinalidade e modalidade. (d) modalidade e cardinalidade. (e) modalidade e grau. 124. Em um banco de dados relacional, a operação de exclusão sobre a tabela referenciada se propaga para 124 todas as chaves estrangeiras correspondentes quando usada a expressão SQL ANSI on delete (a) set default. (b) spread. (c) propagate. (d) cascade.xx (e) set null.
88
TI para concursos
125. Uma transação executará qualquer operação somente depois que o gerenciador de banco de dados 125 conceder o bloqueio do dado por meio do (a) gerenciador de arquivos. (b) seletor de estratégia. xx (c) controlador de concorrência. (d) gerenciador de recuperação. (e) gerenciador de buffer.
89
TI para concursos
7
Programação de Sistemas
7.1
Lógica de Programação O computador, como todo componente eletrônico, só entende sinais de carga elétrica sequenciadas, um choquinho após o outro. Dividido em diversos tipos de componentes físicos que se comportam de forma diferente ao estímulo elétrico, pode-se determinar a ação de um equipamento eletrônico alterando-se o sequenciamento destas peças pela ação de chaves (componentes eletrônicos) que desviam o fluxo de energia. Esta definição da sequência de chaves, que determina por onde e quando a corrente elétrica vai passar resultando em um comportamento previsto do sistema elétrico, é chamada de programação. Os primeiros programadores definiam e alteravam estas chaves diretamente com fios em placas. A evolução permitiu que a programação pudesse ser feita por sequenciamento lógico de números que poderiam ser transferidos para os computadores através de cartões perfurados ou textos digitados que alteravam o estado das chaves sem o programador ter que manusear o equipamento diretamente. Programas pré-concebidos traduziam palavras (em inglês), textos inteligíveis, em comandos em linguagem da máquina (números). Estes programas são os compiladores. Endereços de memória que contém dados recebem nomes pelo programador (variáveis). Programar passou, então, a ser redigir um texto obedecendo certas regras de sintaxe, submeter o texto a um compilador que faz a tradução para a linguagem que a máquina consegue processar. Por certo tempo, programação consistia em sequenciar comandos e atribuir “endereços” (números ou índices), a eles. Para se repetir uma sequencia de comandos, ou seja, fazer uma iteração, utilizava-se um comando para desviar o processamento para o endereço do primeiro comando da sequencia. Os comandos eram basicamente: leia, armazene na variável, faça a conta, grave (na tela, disco ou impressora) e desvie para o endereço tal, além do comando de condição SE (IF - se o valor for tanto, pule para o endereço tal). Era a programação indexada. Tudo era controlado por números e o programador tinha que pensar como máquina. Um exemplo, era a linguagem Basic: 10 CLS 20 INPUT “DIGITE UM VALOR PARA A: “ A 30 INPUT “DIGITE UM VALOR DIFERENTE PARA B “ B 40 IF A=B GOTO 30 50 IF A>B GOTO 80 60 PRINT “O VALOR A E´ MENOR DO QUE B” 70 GOTO 90 80 PRINT “O VALOR A E´ MAIOR DO QUE B” 90 PRINT “FIM DE PROCESSAMENTO”
Com a criação dos comandos do tipo declaração (statement): enquanto (while), repita-até que (repeat until), caso (case) e para-faça (for do); o sequenciamento de comandos passou a apresentar o formato de uma contrução lógica, dispensando a numeração das linhas de programação. Os comandos passaram a ser agrupados em blocos, chamados de sub-rotinas, ou procedimentos (procedures e functions), que recebem um nome e podem ser utilizados como novos comandos. Esta era a programação estruturada, procedural ou procedimental. O próprio programa passa a ser visto como um grande bloco formado por blocos menores e comandos. Por exemplo, um programa para calcular fatorial em linguagem turbo pascal.
90
TI para concursos
Program Fatorial; Var Numero : integer; Function Calcula_Fatorial(n: integer) : integer; Begin If n>1 then Calcula_Fatorial := n*Calcula_Fatorial(n-1) Else Calcula_Fatorial := 1; End; Begin repeat Clrscr; Write(‘Digite um número inteiro positivo (zero para terminar): ‘); Readln(Numero); If Numero>=0 then Writeln(‘O fatorial de ‘, Numero, ‘ é ‘, Calcula_Fatorial(Numero)) Else Writeln(‘Valor inválido’); Until Numero=0; Writeln(‘Fim de processamento.’); End.
A grande revolução na arte da programação de computadores foi quando alguém percebeu que o homem não deve pensar como máquina para escrever um programa, mas deve fazer o computador comportar-se como gente e compreender comandos humanos. Criou-se uma técnica de raciocínio em que o programa de computador podia ser visto como um objeto que se comporta como aquilo que conhecemos na vida real. Tem qualidades, aspectos, características ou, genericamente, atributos. Tem comportamento. Pode ser móvel ou não, fazer coisas. É formado por objetos menores (até o átomo, ou menor) que possuem também atributos e comportamentos Quando esta técnica se transformou em uma linguagem, criou-se a programação orientada a objetos. Ela utiliza uma nova forma de fazer programas, não jogou fora todos os aspectos positivos da programaçao procedimental e estruturada, mas evoluiu estes conceitos. Os procedimentos e funções são chamados de métodos quando estão dentro de um objeto. As variáveis internas ao objeto são chamadas de propriedades ou atributos. O conjunto de valores das propriedades formam o estado do objeto. Mensagens são ações de dispositivos externos (teclado, mouse, placa de rede, scanner, outros programas) ou de outros objetos que provocam mudanças de estado. Algumas mudanças do estado do objeto podem determinar uma situação em que algum método deve ser executado (ação). Por exemplo, um clique do mouse sobre um objeto botão muda a propriedade “Clicado” de falso para verdadeiro. O seu novo estado pode desencadear uma sequencia de comandos ou métodos. Mudanças de estado que fazem uma ação são chamadas de eventos. Neste exemplo, o clique do mouse aciona um evento chamado “OnClick” (se existir). A partir disto, um programa deixou de ser um simples sequenciamento de comandos para ser uma série de ações que provocam mudanças de estado que podem desencadear outras ações.
7.1.1
Tipos de dados e variáveis Durante o seu processamento, um programa deve necessitar de dados para efetuar cálculos e tratamentos e devolver informação ao usuário. Estes dados são introduzidos por qualquer meio, como digitação, envio de parâmetros por outro objeto ou leitura em um arquivo, depois armazenados em áreas da memória do computador chamadas de variáveis. Os valores armazenados nas variáveis podem ser utilizados através de seu endereço físico na memória (por apontadores ou pointers) ou, mais comum, por um nome atribuído á variável. Da mesma forma que não se somam bananas com maçãs, o programa não costuma misturar tipos diferentes de dados em suas operações. O programador deve ter conhecimento dos tipos possíveis de dados para não provocar erros no processamento. Linguagens de programação são ditas tipadas quando exigem que as variáveis a serem utilizadas sejam pré-definidas como seu nome e tipo, como no pascal. São não tipadas quando as variáveis são definidas no momento de sua utilização, assumindo um determinado tipo de acordo com o valor atribuído a ela.
91
TI para concursos
De forma geral, define-se como numérico os valores que serão utilizados para cálculos algébricos. São de tipo lógico as variáveis que assumem apenas dois estados, verdadeiro ou falso, ou equivalente (0 ou 1, v ou t, sim ou não etc). São alfanuméricas as variáveis que não são destinadas a cálculos, mas somente operações de comparações, buscas, concatenações ou simples exibição. São de tipo apontador, variáveis que armazenam endereços de memória. Dependendo da linguagem de programação, as variáveis numéricas podem se subdividir em reais ou inteiras, e também em outras variações destes dois tipos, como inteiro não negativo, monetário, inteiro longo etc. O tipo alfanumérico também pode receber variações como memorando (texto), ou texto formatado. Existem também outros tipos de armazenamento de dados na memória, que são agrupamentos de variáveis: Vetor – conjunto de variáveis identificado por um nome e números inteiros positivos (começando em zero) para cada elemento. A parte numérica do nome da variável fica entre parênteses ou colchetes à direita do nome. Para se referir a uma posição do vetor, a parte numérica pode ser resultado de uma operação matemática. Um vetor que utiliza mais do que um número (dimensões) para identificar cada uma de suas posições (separados por vírgulas) é chamado de matriz. Registro – grupo de variáveis de vários tipos, identificado por um nome. Cada variável dentro de um registro é chamada de campo. Lista – conjunto de registros ligados por apontadores, usado em conjunto de dados hierárquicos em que a relação entre os dados não precisa ser representada em forma de matrizes, ou para armazenar dados de uma tabela na memória para algum tratamento especial. Fila – sequência de dados ordenados, em que o primeiro dado que entra na fila deve ser o primeiro a sair (FIFO – First in first out ou LILO - Last in last out) Deque – fila em que os elementos podem ser inseridos ou removidos de qualquer extremo. Pilha – sequência de dados em que o último valor adicionado deve ser o primeiro a sair (LIFO - Last in first out ou FILO - First in last out)
7.2
Programação orientada a objetos A análise e o projeto orientados a objetos têm como meta identificar o melhor conjunto de objetos para descrever um sistema de software. O funcionamento deste sistema se dá por meio do relacionamento e troca de mensagens entres os objetos. As linguagens de programação que dão suporte a orientação a objetos são: Smaltalk, Perl, Python, Ruby, PHP, ColdFusion, C++, Object Pascal, Java, JavaScript, ActionScript, Delphi (object pascal) e C#. Os conceitos mais importantes na programação orientada a objetos são: Objetos (instâncias) e encapsulamento Classes Persistência Métodos e propriedades Herança e classes hierárquicas Polimorfismo Interfaces Sobrecarga Para uma linguagem ser considerada verdadeiramente orientada a objetos, a linguagem de programação deve oferecer, no mínimo, as características de: encapsulamento, herança e polimorfismo.
7.2.1
Objetos Objeto é uma abstração do mundo real. Objetos de software são modelados de acordo com os objetos do mundo real, ou seja, possuem estado e comportamento. Um objeto de software armazena seu estado em variáveis e implementa seu comportamento com métodos. Estas variáveis e métodos são formalmente chamados de variáveis de instância e métodos de instância a fim de distingui-los de variáveis e métodos de classe. As variáveis de um objeto fazem parte do seu núcleo (centro). Os métodos envolvem e escondem (empacotam) o núcleo do objeto de outros componentes da aplicação. Empacotar as variáveis de um
92
TI para concursos
objeto sobre proteção de seus métodos é chamado de encapsulamento. O encapsulamento é utilizado para esconder detalhes de implementação. Este é um dos princípios fundamentais da programação orientada a objetos. Às vezes, por razões de eficiência ou implementação, um objeto deseja expor algumas de suas variáveis ou esconder alguns de seus métodos. Esta capacidade de controlar quais componentes podem acessar seus métodos e suas variáveis é chamada de Controle de Acesso. Cada objeto tem sua identidade, o que significa que dois objetos são distintos mesmo que eles apresentem exatamente as mesmas características (atributos iguais). Esta identificação de objeto deve ser única, uniforme e independente do conteúdo do objeto. Em geral, os objetos possuem, pelo menos, dois métodos: Construtor: define o comportamento no momento da criação de um objeto de uma classe; Destrutor: define o comportamento no momento da destruição do objeto de uma classe. Normalmente utilizado para liberar recurso (memória) do sistema.
7.2.2
Classe Objetos podem apresentar métodos e atributos (propriedades) idênticos. Em relação a estes elementos em comum, dizemos que eles pertencem a uma mesma classe. Na programação orientada a objeto, classe é uma abstração, enquanto que, neste contexto, objeto é considerado um elemento fático. Uma classe é um modelo, ou protótipo, que define as variáveis (estado) e os métodos (comportamento) comuns a todos os objetos do mesmo tipo. Na classe são definidas as variáveis e implementados os métodos. Os objetos são criados a partir de suas classes. Dois botões na tela pertencem à classe botão. Espera-se deles que respondam ao clique do mouse, costumam ser cinzas, em alto-relevo e ficam em baixo-relevo ao clicar. Por outro ponto de vista, podemos dizer que uma classe botão, cinza, em alto-relevo, com determinado comportamento ao clicar, pode ter duas instâncias na tela. Definidas as características de um tipo de botão, ao criar (instanciar) um objeto, por uma instrução determina-se que ele fará parte da classe, e isto fará com que ele herde todas as características de um botão típico. Depois de instanciado, ações poderão alterar seu estado, como sua aparência e comportamento. Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento (métodos e eventos) e os estados possíveis (valores dos atributos) de seus objetos, assim como o relacionamento com outros objetos. As classes não são diretamente suportadas em todas as linguagens de objetos, e não são necessárias para que a linguagem seja orientada a objetos. A classe define as características comuns e os objetos são instâncias dessa classe, com estado próprio.
7.2.3
Persistência Alguns objetos são criados, cumprem sua função e são destruidos logo em seguida. Outros objetos continuam por tempo indeterminado e isto é chamado de persistência. Não faz sentido falar de persistência de classes, somente de instâncias (objetos).
7.2.4
Métodos Método é uma sub-rotina interna a um objeto, que pode ser executado por uma ação externa, isto é, ao receber uma mensagem, ou por uma ação interna de um evento.
93
TI para concursos
7.2.5
Atributos Os atributos são os elementos que definem a estrutura de uma classe. Os atributos também são conhecidos como variáveis de classe, e podem ser divididos em dois tipos básicos: atributos de instância e de classe. Os valores dos atributos de instância determinam o estado de cada objeto. Um atributo de classe possui um estado que é compartilhado por todos os objetos de uma classe. Atributos de classe podem ser chamados também de atributos estáticos ou constantes.
7.2.6
Mensagens Objetos modificam seu estado por meio do recebimentos de mensagens. Alguns métodos de um objeto que recebe a mensagem precisam de informações, os parâmetros, para saber exatamente o que fazer. Assim, três componentes fazem parte de uma mensagem: o objeto para onde a mensagem é endereçada; o nome do método a realizar; parâmetro(s) necessários para realizar o método;
7.2.7
Herança A herança é um mecanismo que permite criar novas classes a partir de classes já existentes, aproveitando-se das características existentes na classe a ser extendida. Com a herança é possível criar classes derivadas (sub-classes) a partir de classes bases (superclasses). As subclasses herdam todas as características de suas superclasses, como suas variáveis (estado) e seus métodos (comportamento). Entretanto, as subclasses não estão limitadas ao comportamento herdado de sua super-classe. As subclasses podem adicionar variáveis e métodos a aqueles herdados. As subclasses, também, podem redefinir (override) métodos herdados e oferecer implementações especializadas para estes métodos. O conceito de herança pode ser aplicado para mais de um nível. A árvore de herança, ou hierarquia de classe, pode ser tão profunda quanto necessário. Os métodos e variáveis são herdados por meio dos níveis. Em geral, quanto mais baixa na hierarquia for a posição da classe, mais específico é o seu comportamento. Como benefícios do conceito de herança, podemos citar: Programadores podem definir classes abstratas que determinam comportamentos genéricos. Subclasses oferecem comportamentos especializados a partir de elementos básicos comuns, oferecidos pela superclasse. A utilização de herança promove o reuso e reaproveitamento de código existente, tornando a manutenção do código mais eficiente. A superclasse define e pode implementar parcialmente o comportamento de uma classe, mas a maioria das informações da classe fica indefinida ou não é implementada. A herança múltipla ocorre quando uma classe pode estender características de várias outras classes ao mesmo tempo, ou seja, quando a subclasse possui mais de uma superclasse. Algumas linguagens evitam utilizar este mecanismo, pois pode levar uma codificação confusa o que dificulta a manutenção do código. A linguagem Java não suporta herança múltipla, apenas herança simples. Já a linguagem C++ oferece suporte à herança múltipla. Uma linguagem ao utilizar herança múltipla está sujeita a dois problemas: colisão de nomes (nomes idênticos nas classes superiores) e herança repetida (classe herda de uma classe superior que herda de uma classe comum);
7.2.8
Polimorfismo Segundo a terminologia de orientação a objetos, polimorfismo significa que uma mesma mensagem enviada a diferentes objetos resulta em um comportamento que é dependente da natureza do objeto que está recebendo a mensagem. Ou seja, duas ou mais classes derivadas de uma mesma superclasse podem invocar métodos que têm a mesma assinatura (nome, lista de parâmetros e retorno), mas comportamentos distintos, especializado para cada classe derivada, usando para tanto uma referência a um objeto do tipo superclasse. A decisão sobre qual método deve ser selecionado, de acordo com o tipo da classe derivada, é tomada em tempo de execução por meio do mecanismo de ligação tardia. No caso do polimorfismo, é
94
TI para concursos
necessário que os métodos tenham exatamente a mesma identificação, sendo utilizado o mecanismo de redefinição de métodos. Os benefícios do polimorfismo são: a clareza e manutenção do código, a divisão da complexidade e aplicações flexíveis. Algumas linguagens promovem o polimorfismo principalmente por meio do uso de classes abstratas e interfaces, como é o caso da linguagem Java.
7.2.9
Sobrecarga A sobrecarga é um tipo de polimorfismo que permite a existência de vários métodos de mesmo nome, porém com assinaturas levemente diferentes, ou seja, variando no número e tipo de argumentos e o valor de retorno. Ficará a cargo de o compilador escolher de acordo com as listas de argumento os procedimentos ou métodos a serem executados. Por exemplo: public class Soma { public int Soma (int x, int y) {return x+y;} public String Soma (String x, String y) {return x+y;} public double Soma (double x, double y) {return x+y;} }
7.2.10
Interfaces Interface é a relação de métodos, com seus parâmetros, das propriedades que podem ser acessados por outros objetos e também pode incluir declarações de constantes. Uma interface apresenta somente as definições de métodos, sem sua implementação. A classe que implementa a interface deve implementar todos os métodos definidos na interface.
7.2.11
Pacotes Para tornar as classes mais fáceis de serem encontradas e utilizadas, para evitar conflitos de nomes e para controlar o acesso, pode-se agrupar classes relacionadas em pacotes (packages). Os pacotes organizam as classes e as interfaces relacionadas. Cada pacote criado corresponde a um diretório, ou seja, as classes e as interfaces de um mesmo pacote devem estar em um mesmo diretório. A utilização de pacotes proporciona as seguintes vantagens: Fica mais fácil para outros programadores determinar quais classes e interfaces estão relacionadas. Os nomes das classes de um pacote não irão conflitar com nomes e classes de outros pacotes. Pode-se permitir que classes dentro de um mesmo pacote tenham acesso irrestrito entre si, e restringir o acesso por parte de classes definidas fora do pacote. Apenas os membros (classe, variáveis e métodos) públicos são acessíveis fora do pacote onde foram definidos.
7.3
Programação na WEB Visualizar uma página web ou outro recurso disponibilizado normalmente inicia ou ao digitar uma URL no navegador ou seguindo (acessando) uma hiperligação. Primeiramente, a parte da URL referente ao servidor web é separada e transformada em um endereço IP, por um banco de dados da Internet chamado Domain Name System (DNS). O navegador estabelece então uma conexão TCP-IP com o 45 servidor web localizado no endereço IP retornado. O próximo passo é o navegador enviar uma requisição HTTP ao servidor para obter o recurso indicado pela parte restante da URL (retirando-se a parte do servidor). No caso de uma página web típica, o texto HTML é recebido e interpretado pelo navegador, que realiza então requisições adicionais para figuras, arquivos de formatação, arquivos de script e outros recursos que fazem parte da página. O navegador então renderiza a página na tela do usuário, assim como descrita pelos arquivos que a compõe. A funcionalidade da Web é baseada em três padrões:
45
http://pt.wikipedia.org/wiki/World_Wide_Web
95
TI para concursos
URI, um sistema que especifica como cada página de informação recebe um "endereço" único onde pode ser encontrada. HTTP, um protocolo que especifica como o navegador e servidor web comunicam entre si. HTML, uma linguagem de marcação para codificar a informação de modo que possa ser exibida em uma grande quantidade de dispositivos. Desta forma, programar para Web é escrever páginas em HTML. Para isto, o programador pode escrever um texto em HTML puro e gravar este arquivo em um servidor web. Estes textos são chamados de páginas estáticas. Elas só mudam quando o programador alterar o arquivo. Porém, o servidor web utilizado pode ter instalado programas que geram páginas HTML no momento em que a requisição chega. Neste caso, o texto requisitado não é um texto HTML, mas é um código em alguma linguagem de programação que, ao ser processado pelo servidor, gera um texto HTML dentro das especificações da requisição. Estes textos são chamados de páginas dinâmicas. Estas páginas permitem a interação com o usuário e com gerenciadores de bancos de dados, podendo gerar páginas HTML diferentes a cada instante. Assim, ao projetar um site, o programador decide se vai usar páginas estáticas, dinâmicas ou as duas.
7.3.1
Linguagem HTML HTML (acrônimo para a expressão inglesa HyperText Markup Language, que significa Linguagem de Marcação de Hipertexto) é uma linguagem de marcação utilizada para produzir páginas na Web. Documentos HTML podem ser interpretados por navegadores. A tecnologia é fruto do "casamento" dos padrões HyTime e SGML.46 HyTime é um padrão para a representação estruturada de hipermédia e conteúdo baseado em tempo. Um documento é visto como um conjunto de eventos concorrentes dependentes de tempo (como áudio, vídeo, etc.), conectados por hiper-ligações. O padrão é independente de outros padrões de processamento de texto em geral. SGML é um padrão de formatação de textos. Não foi desenvolvido para hipertexto, mas tornou-se conveniente para transformar documentos em hiper-objetos e para descrever as ligações. Todo documento HTML apresenta tags (tags), elementos entre parênteses angulares (sinais de maior e menor). Esses elementos são os comandos de formatação da linguagem. A maioria das tags tem sua correspondente de fechamento: ...
Isso é necessário porque as tags servem para definir a formatação de uma porção do documento, e assim marcamos onde começa e termina o texto com a formatação especificada por ela. Alguns elementos são chamados “vazios”, pois não marcam uma região de texto, apenas inserem algum elemento no documento: Uma tag é formada por comandos, atributos e valores. Os atributos modificam os resultados padrões dos comandos e os valores caracterizam essa mudança. A estrutura de um documento HTML apresenta os seguintes componentes: Título do Documento texto, imagem, links, ...
De uma maneira geral o HTML é um poderoso recurso, sendo uma linguagem de marcação muito simples e acessível voltada para a produção e compartilhamento de documentos e imagens. As tags HTML não são sensíveis à maiúsculas ou minúsculas, portanto tanto faz escrever , , ou . As tags básicas de HTML, cuja presença é altamente recomendada nas páginas são:
46
http://pt.wikipedia.org/wiki/HTML
96
TI para concursos
: define o início de um documento HTML e indica ao navegador que todo conteúdo posterior deve ser tratado como uma série de códigos HTML. : define o cabeçalho de um documento HTML, que traz informações sobre o documento que está sendo aberto. : define o conteúdo principal, o corpo do documento. Esta é a parte do documento HTML que é exibida no navegador. No corpo podem-se definir propriedades comuns a toda a página, como cor de fundo, margens, e outras formatações. Dentro do cabeçalho podemos encontrar os seguintes comandos: : define o título da página, que é exibido na barra de título dos navegadores. <style>: define formatação em CSS (Cascading Style Sheets), uma linguagem de estilo utilizada para definir a apresentação de documentos escritos em HTML ou XML. <script>: define programação de certas funções em página com scripts (códigos de programa) em diversas linguagens web cliente, como Javascrip, Visual Basic Script, DHTML ou CSS. Applets de Java <link>: define ligações da página com outros arquivos como feeds, CSS, scripts etc. <meta>: define propriedades da página, como codificação de caracteres, descrição da página, autor, etc. São meta informações sobre documento. Tais campos são muitos usados por mecanismos de busca (como o Google) para obterem mais informações sobre o documento, a fim de classificá-lo melhor. Por exemplo, pode-se adicionar o código <meta name="description" content="descrição da sua página" /> no documento HTML para indicar ao motor de busca que texto de descrição apresentar junto com a ligação para o documento. As tags <style> e <script> servem tanto para delimitar o espaço usados pelos códigos na página quanto para invocar códigos existentes em outros arquivos externos. Dentro do corpo podemos encontrar outras várias tags, como por exemplo: <h1>, <h2>,... <h6>: cabeçalhos e títulos no documento em diversos tamanhos. (quanto menor for o número, maior sera o tamanho da letra) <p>: novo parágrafo. <br>: quebra de linha. <table>: cria uma tabela (linhas são criadas com <TR> e novas células com <TD>. Já os cabeçalhos de coluna são criados com a tag <TH>.) <div>: determina uma divisão na página a qual pode possuir variadas formatações. <font>: altera a formatação (fonte, cor e tamanho) de um trecho do texto. <b>, <i>, <u> e <s>: negrito, itálico, sublinhado e riscado, respectivamente. <img>: imagem. <a>: hiper-ligação para um outro local, seja uma página, um e-mail ou outro serviço. <textarea>: caixa de texto (com mais de uma linha); estas caixas de texto são muito usadas em blogs, elas podem ser auto selecionáveis e conter outros códigos a serem distribuídos. <acronym rel="nofollow">: acrônimo (sigla) <cite>: citação <address rel="nofollow">: endereço Uma propriedade importante dos documentos HTML é a possibilidade de fazer hiperligações. Para isso usa-se a tag <a> (do inglês, anchor). Esta tem os atributos: href que define o alvo da hiperligação (que pode ser uma página de Internet, uma parte da mesma página ou um endereço de email) ou name que define um alvo nessa página (a onde se pode fazer uma hiperligação usando a tag a com o atributo href). Exemplos: <a href="http://pt.wikipedia.org/" rel="nofollow">Clique aqui para aceder à página principal da Wikipédia em português.</a> <a name="nome" rel="nofollow">texto</a><br />
<br />
Os caracteres especiais definem-se usando comandos que começam com & e terminam com um ;. Alguns exemplos incluem á (á), à (à), ã (ã), â (â), ä (ä) e ç (ç). Qualquer outra vogal pode ser substituída pelo a destes exemplos, incluindo maiúsculas.<br />
<br />
7.3.2<br />
<br />
Linguagens web de servidor Para a criação de páginas dinâmicas, existem diversas linguagens de programação que podem ser configuradas no servidor, como, por exemplo, CGI (Common Gateway Interface), ASP (Active Server Pages), PHP (Hypertext Preprocesor) ou JSP (Java Server Pages).<br />
<br />
97<br />
<br />
TI para concursos<br />
<br />
7.3.3<br />
<br />
XML O XML (eXtensible Markup Language) é um formato para a criação de documentos com dados organizados de forma hierárquica, como se vê, frequentemente, em documentos de texto formatados, imagens vetoriais ou bancos de dados. É um subtipo de SGML (Standard Generalized Markup Language) capaz de descrever diversos tipos de 47 dados. Seu propósito principal é a facilidade de compartilhamento de informações através da Internet. Pela sua portabilidade, já que é um formato que não depende das plataformas de hardware ou de software, um banco de dados pode, através de uma aplicação, escrever em um arquivo XML, e um outro banco distinto pode ler então estes mesmos dados. Este exemplo demonstra a sintaxe flexível do XML sendo usada para descrever uma receita de pão: <?xml version="1.0" encoding="ISO-8859-1"?> <receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora"> <titulo>Pão simples</titulo> <ingredientes> <ingrediente quantidade="3" unidade="xícaras">Farinha</ingrediente> <ingrediente quantidade="7" unidade="gramas">Fermento</ingrediente> <ingrediente quantidade="1.5" unidade="xícaras" estado="morna">Água</ingrediente> <ingrediente quantidade="1" unidade="colheres de chá">Sal</ingrediente> </ingredientes> <instrucoes> <passo>Misture todos os ingredientes, e dissolva bem.</passo> <passo>Cubra com um pano e deixe por uma hora em um local morno.</passo> <passo>Misture novamente, coloque numa bandeja e asse num forno.</passo> </instrucoes> </receita><br />
<br />
Onde temos na primeira linha: <Receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora"><br />
<br />
"Receita" é o nome principal para o seu documento. Note que a semelhança entre XML e HTML é grande, na 1ª linha abrimos a tag Receita e na última linha a fechamos, como em HTML, assim se estendendo por todo o exemplo. Assim como em HTML, os conteúdos são inseridos entre tags (marcadores) de mesmo nome, sendo que a segunda tag tem uma barra (/) antes do nome. O XML apresenta algumas regras básicas: Letras maiúsculas e minúsculas são diferentes. <passo> é diferente de <Passo><br />
<br />
Nenhuma tag pode ficar aberta. Toda <tag> deve ter uma </tag>. <passo>Misture todos os ingredientes, e dissolva bem.</passo><br />
<br />
As tags não podem ficar sobrepostas. Uma tag aberta dentro de outra tag deve ser fechada antes. <instrucoes> <passo>Misture todos os ingredientes, e dissolva bem.</passo> </instrucoes><br />
<br />
Os atributos devem estar entre aspas. <ingrediente quantidade="3" unidade="xícaras"><br />
<br />
7.4<br />
<br />
Conceitos de linguagem de programação Microsoft .NET No ano de 2000, a Microsoft apresentou ao mundo a plataforma .Net e seu novo ambiente de desenvolvimento, o Visual Studio .Net. A .Net, em sua essência, é muito similar ao J2EE (Java 2 Enterprise Edition). Um compilador .Net gera um código intermediário, e quando é executado, o compilador JIT (Just in Time) traduz este código intermediário para código nativo do processador, com um enorme ganho de performance. A .Net também oferece independência de plataforma, hardware e linguagem de programação.<br />
<br />
47<br />
<br />
http://pt.wikipedia.org/wiki/XML<br />
<br />
98<br />
<br />
TI para concursos<br />
<br />
7.4.1<br />
<br />
arquitetura da .Net Existem termos e conceitos que devem ser entendidos para se utilizar a .Net.<br />
<br />
7.4.2<br />
<br />
Linguagens de programação Esta é a primeira camada da plataforma. Neste nível ficam as ferramentas de desenvolvimento e os respectivos compiladores. A .Net oferece independência de linguagem. Atualmente existem mais de trinta com suporte para .Net. Todas as linguagens .Net obrigatoriamente devem seguir os padrões da plataforma. Quando dizemos que uma linguagem é compatível com .Net, entendemos que ela usa o CLR e a FCL. A Microsoft oferece quatro linguagens com sua plataforma: C# (leia-se C Sharp), com características herdadas do C++ e Java, mas muito mais fácil de aprender e utilizar VB.Net, a versão do Visual Basic que foi reescrito para a plataforma C++ Embedded, a versão C++ da .Net, pouquíssimo usada J# (leia-se Jei Sharp), a versão Java da .Net, também muito pouco usada, cujo objetivo é apenas facilitar a migração dos desenvolvedores Java para a .Net. Oferece total compatibilidade com suas linguagens, onde códigos escritos numa determinada linguagem podem ser executadas em outra sem nenhum problema. Ou seja, é possível escrever uma classe em C#, herdá-la em VB.Net e usá-la no C++ Embedded (a versão C++ da .Net).<br />
<br />
99<br />
<br />
TI para concursos<br />
<br />
7.4.3<br />
<br />
Common Language Specification (CLS) A Microsoft liberou um conjunto de especificações que uma linguagem deve possuir para ser considerada compatível com .Net. Como a IL (ou o assembly .Net) é uma linguagem muito rica, não é necessário que sejam implementadas todas suas funcionalidades, basta uma parte dela para tornar a linguagem compatível. Esta é a razão pela qual muitas linguagens, procedurais ou oop, já estão executando sob o guarda-chuva da .Net. A CLS basicamente determina especificações de desenvolvimento e estabelece certos padrões. Por exemplo, não pode haver declaração de funções globais, acesso a ponteiros, herança múltipla e coisas deste tipo. Um detalhe importante é que, se seu código está dentro das fronteiras estabelecidas pela CLS, é garantido que ele poderá ser utilizado por qualquer outra linguagem da plataforma.<br />
<br />
7.4.4<br />
<br />
Common Type System (CTS) Como a CLS, a Common Type System também é um conjunto de padrões que define os tipos de dados básicos que a IL entende. Toda linguagem .Net deve mapear seus tipos primitivos para estes padrões. Isto possibilita que as linguagens se comuniquem passando/recebendo parâmetros de uma para a outra. Por exemplo, a CTS define um tipo Int32 como um inteiro de 32 bits (4 bytes), o qual é chamado (ou mapeado) em C# como int e em VB.Net como integer. Mas pra .Net ambos são iguais, ou seja, um Int32.<br />
<br />
7.4.5<br />
<br />
Framework Class Library (FCL) A .Net oferece uma gigantesca biblioteca de classes básicas para as tarefas mais comuns e usuais. A FCL contém milhares de classes para acesso a API do Windows e funções em geral, como manipulação de strings, estrutura de dados, entrada/saída, fluxos, segurança, multi-tarefa, programação em rede, Web, acesso a dados, etc. Ela é simplesmente a maior biblioteca padrão já fornecida por qualquer linguagem de programação ou ambiente de desenvolvimento. A melhor parte da FCL são seus padrões de desenvolvimento totalmente OOP, tornando seu acesso e utilização muito simples e previsíveis. Você utiliza estas classes em seus programas como utilizaria qualquer outra, inclusive aplicando herança e polimorfismo nelas. Esta biblioteca é organizada hierarquicamente numa estrutura chamada namespace. Ao desenvolver qualquer software, ele precisa ser estruturado numa namespace para que possa ser usado a partir de outro programa externo (veremos namespaces oportunamente).<br />
<br />
7.4.6<br />
<br />
Camada de apresentação Este nível define o tipo de interação do sistema com o usuário, que pode ser através de uma aplicação Web (utilizando o ASP.Net e Web Forms), Windows (utilizando Windows Forms) ou console (utilizando um prompt de comando, em modo caracter). Na minha opinião, os sistemas para Smart Devices (como Pockets, celulares, etc) também deveriam ser considerados uma camada de apresentação diferente, mas neste esquema eles foram incluídos com os Windows Forms.<br />
<br />
7.4.7<br />
<br />
ADO.Net Esta camada é responsável pela comunicação das aplicações com os banco de dados. Basicamente, o ADO.net trabalha de duas formas: • Modo conectado: utilizando objetos das classes managed provider, que permitem que você se conecte ao banco de dados e execute instruções SQL diretamente; • Modo desconectado: neste modo, você armazena informações de um banco de dados localmente, na memória do computador onde a aplicação está executando. Estas informações são armazenadas em objetos das classes Dataset, que permitem qualquer operação aceita por um banco de dados, também conhecida pela sigla CRUD (Create, Retrieve, Update, Delete) ou seja, criar, recuperar, atualizar e excluir linhas (ou registros). Periodicamente, uma conexão é feita com o banco e as informações são sincronizadas. Deste modo, você pode criar aplicações para Web ou dispositivos móveis (tipo Pocket PC), que não tem uma conexão permanente com o banco, ou mesmo aplicações Windows rodando numa rede local ou remota.<br />
<br />
7.4.8<br />
<br />
.Net Remoting Remoting é o processo no qual programas ou componentes se interagem dentro de certos limites. Estes contextos normalmente são máquinas ou processos diferentes. Na .NET Framework, esta tecnologia fornece a base para aplicações distribuídas, ou seja, ela simplesmente substitui o DCOM. • DCOM é a abreviatura de Distributed Component Object Model, uma extensão do COM (Component Object Model) que permite que objetos se comuniquem em uma rede. Componentes COM tradicionais<br />
<br />
100<br />
<br />
TI para concursos<br />
<br />
somente executam esta comunicação entre processos na máquina local. O DCOM usa o mecanismo RPC para enviar e receber informações entre componentes COM (clientes e servidores) na mesma rede. o RPC é a abreviatura para Remote Procedure Call, um tipo de protocolo que permite que um programa num computador execute outro programa num servidor. Com esta técnica, o desenvolvedor não precisa criar procedimentos específicos para o servidor. O programa cliente envia uma mensagem ao servidor, com os argumentos apropriados, e o servidor retorna uma mensagem contendo o resultado do programa executado. o A rede a que nos referimos pode ser uma LAN, WAN ou a própria Internet (que não passa de uma rede mundial gigantesca). Implementações Remoting geralmente fazem distinção entre objetos remotos e objetos móveis. • Objetos remotos: Remoting fornece a capacidade de executar métodos em servidores remotos, passando parâmetros e recebendo valores de retorno. O objeto remoto sempre fica num servidor e as outras máquinas apenas passam uma referência a ele. • Objetos móveis: Neste caso os dados enviados são serializados (organizados) num formato que pode ser binário ou legível para nós, como XML, e de-serializados no outro contexto envolvendo o processo. Ambos, servidor e cliente, mantém cópias do mesmo objeto. Nestas cópias, os métodos são executados no contexto local e nenhuma mensagem vai trafegar de volta a máquina que originou o objeto. Na verdade, após a serialização e de-serialização os objetos copiados são idênticos aos objetos locais normais, e não há distinção entre um objeto servidor e um objeto cliente. A .NET expande este conceito para incluir a habilidade de definir contextos adicionais dentro de uma aplicação em execução, e o acesso a estes objetos além dos seus limites também passarão pelo .NET Remoting Framework.<br />
<br />
7.4.9<br />
<br />
Common Language Runtime (CLR) O conceito mais importante da .Net Framework é a existência e funcionalidade do Common Language Runtime (CLR), também conhecida como .Net Runtime ou máquina virtual .Net. Ele é uma camada do framework que fica acima do sistema operacional e manipula a execução de todas as aplicações .Net. Nossos programas não se comunicam diretamente com o sistema operacional, apenas através do CLR. Ele é o responsável por chamar o compilador JIT (Just In Time, ou em tempo de execução) e transformar o código MSIL (Microsoft Intermediate Language ou assembly), gerado pelos compiladores .Net, em código nativo da plataforma onde está executando. Ou seja, quando você compila um programa ou dll .Net você obtém um arquivo com a extensão .exe ou .dll mas estes arquivos não executarão se o CLR não estiver instalado. O CLR também contém o Garbage Collector (GC), ou coletor de lixo, o qual executa como uma tarefa de baixa prioridade e verifica por espaços de memória não referenciados, alocados dinamicamente. Se ele encontra algum dado que não é mais utilizado por nenhuma variável/referência, ele libera esta memória para o sistema operacional usá-lo para outros programas, quando necessário. A presença do GC libera o programador da tarefa de administrar estes dados pendendes, e que tanto inferniza a vida dos desenvolvedores C++.<br />
<br />
7.4.10<br />
<br />
Common Language Infrastructure (CLI) A especificação CLI é um padrão internacional para criar ambientes de desenvolvimento e execução no qual linguagens e bibliotecas trabalham juntas. Ela descreve como aplicações escritas em múltiplas linguagens de alto nível podem ser executadas em diferentes ambientes operacionais sem necessidade de se reescrever a aplicação, para levar em conta as características destes ambientes. Na plataforma .Net, a implementação da CLI é exatamente a CLR.<br />
<br />
7.4.11<br />
<br />
Operating System (OS) No último nível, temos o sistema operacional (SO), responsável pela comunicação direta com os dispositivos (hardware) do computador. Para que uma aplicação .Net funcione em vários ambientes operacionais diferentes, deve haver uma CLR específica para cada um deles. Desta forma, uma vez escrita e compilada, uma aplicação pode ser transportada de uma ambiente para outro sem nenhum tipo de modificação (pelo menos, teoricamente).<br />
<br />
7.4.12<br />
<br />
Outros detalhes da .Net • Assembly: Toda aplicação .Net, após compilada, é armazenada fisicamente numa unidade de códigos chamada assembly. Uma aplicação pode ser composta por um ou mais assemblies, os quais aparecem<br />
<br />
101<br />
<br />
TI para concursos<br />
<br />
no sistema operacional como arquivos executáveis com a extensão .exe ou como bibliotecas dinâmicas com a extensão .dll. • Metadados: São conjuntos de instruções geradas no processo de compilação de um programa .Net, junto com o MSIL, e que contém informações específicas da aplicação, que incluem, entre outras: o Descrição de tipos: classes, estruturas, tipos enumerados, etc, que são usados no sistema, seja um executável ou dll; o Descrição dos membros: propriedades, métodos, eventos, etc; o Descrição de cada assembly: que é usado na aplicação e é necessário para sua execução; o Versão: permite que aplicações homônimas, mas com versões diferentes, executem no mesmo computador sem conflitos. Com as informações contidadas nos metadados, podemos dizer que uma aplicação .Net é autoexplicativa, dispensando a utilização do registro do Windows, usado pela maioria dos programas. Desta forma, a não ser que você crie chaves específicas no registro para seu uso, a instalação de um programa .Net se resume em copiar os assemblies da aplicação para a máquina que irá executá-lo.<br />
<br />
7.5<br />
<br />
Exercícios (ICMS-SP 2009) Instruções: Para responder às cinco próximas questões, utilize um computador hipotético que tem um registrador R (valor inicial: R=10) e 5 posições de memória de M1 até M5 (valores iniciais: M1=030, M2=005, M3=020, M4=015 e M5=010), com capacidade de 3 dígitos cada posição para armazenar valores inteiros de −999 e +999, e que reconhece os seguintes tipos de instruções (cada instrução tem um endereço “n” sequencial e termina com um ponto-e-vírgula): INI; (= inicia o programa). FIM; (= termina o programa). IMP; (= imprime o conteúdo de R). LER nnn; (= carrega em R o número “nnn” digitado pelo teclado). CAR Mx; (= carrega em R o conteúdo de Mx). CAR n; (= carrega em R o número “n”). MOV Mx; (= move para Mx o conteúdo de R). SOM Mx; (= soma Mx com R, o resultado fica em R). SOM n; (= soma “n” com R, o resultado fica em R). SUB Mx; (= subtrai Mx de R, o resultado fica em R). SUB n; (= subtrai “n” de R, o resultado fica em R). MUL Mx; (= multiplica Mx por R, o resultado fica em R). DIV Mx; (= divide Mx por R, o resultado fica em R). IRP n; (= ir para a instrução de endereço “n”). SE condição instruções1 SENAO instruções2; (= se “condição” =VERDADEIRA executa “instruções1”, se =FALSA executa “instruções2”). 126. (ICMS-SP 2009) Dado o programa: 1.INI; 2.LER 050; 3.SOM M3; 4.MOV M1; 5.SUB M5; 6.FIM; 126 Ao término da execução, os conteúdos de M1, M3 e M5 são, respectivamente, xx (a) 070, 020 e 010. (b) 070, 070 e 060. (c) 030, 020 e 010. (d) 050, 020 e 010. (e) 050, 070 e 060. 127. (ICMS-SP 2009) Dado o programa: 1.INI; 2.CAR M2; 3.CAR M4; 4.MOV M4; 5.MOV M2; 6.FIM; 127 Ao término da execução, os conteúdos de R, M2 e M4 são, respectivamente, (a) 015, 005 e 015 (b) 015, 015 e 005 xx (c) 015, 015 e 015 (d) 010, 015 e 005 (e) 010, 005 e 015 128. (ICMS-SP 2009) Dado o programa: 1.INI; 2.MOV M1; 3.SE M1=015 IRP 4 SENAO SOM 1 IRP 5; 4.SOM M1; 5.IMP; 6.FIM; 128 Ao término da execução, o conteúdo impresso será igual a (a) 10 xx (b) 11 (c) 15 (d) 25 (e) 30<br />
<br />
102<br />
<br />
TI para concursos<br />
<br />
129. (ICMS-SP 2009) A lógica principal do programa apresentado na questão anterior representa uma estrutura de 129 controle denominada estrutura (a) sequence. (b) de repetição do-until. (c) de repetição do-while. xx (d) de seleção if-then-else. (e) de seleção case. 130. (ICMS-SP 2009) Dado o programa: 1.INI; 2.CAR M1; 3.CAR M2; 4.CAR M3; 5.CAR M4; 6.CAR M5; 7.SUB M5; 8.FIM; 130 O programa que obtém o mesmo resultado final é: (a) 1.INI; 2.SUB M5; 3.CAR M1; 4.CAR M2; 5.CAR M3; 6.CAR M4; 7.CAR M5; 8.FIM; (b) 1.INI; 2.CAR M5; 3.CAR M4; 4.CAR M3; 5.CAR M2; 6.CAR M1; 7.SUB M5; 8.FIM; (c) 1.INI; 2.SUB M5; 3.CAR M5; 4.CAR M4; 5.CAR M3; 6.CAR M2; 7.CAR M1; 8.FIM; (d) 1.INI; 2.SUB M5; 3.CAR M5; 4.FIM; xx (e) 1.INI; 2.CAR M5; 3.SUB M5; 4.FIM; 131. (ICMS-SP 2009) Os valores das propriedades de um objeto em um determinado instante, que podem mudar 131 ao longo do tempo, representam (a) a instância de uma classe. (b) a identidade de um objeto. xx (c) o estado de um objeto. (d) o comportamento de um objeto. (e) as operações de uma classe. 132<br />
<br />
132. (ICMS-SP 2009) Na orientação a objetos, ao nível de classe, são definidos os (a) atributos e os valores dos atributos. (b) atributos e a invocação das operações. xx (c) atributos e os métodos. (d) métodos e os valores dos atributos. (e) métodos e a invocação das operações.<br />
<br />
133. (ICMS-SP 2009) Uma classe é uma abstração que ajuda a lidar com a complexidade e um bom exemplo de 133 abstração é (a) um aluno e as disciplinas que está cursando. (b) um professor e os cursos nos quais ministra aulas. (c) um funcionário e o departamento em que trabalha. xx (d) uma pessoa e o número do seu CPF na Receita Federal. (e) uma casa e a empresa que a projetou e construiu. 134. (ICMS-SP 2009) O método utilizado para inicializar objetos de uma classe quando estes são criados é 134 denominado (a) void. (b) interface. (c) agregação. (d) composição. xx (e) construtor. 135. (ICMS-SP 2009) Sobre a visibilidade dos métodos na orientação a objetos considere: I. Os métodos públicos de uma classe definem a interface da classe. II. Os métodos privativos de uma classe não fazem parte da interface da classe. III. O nome dos métodos é a informação reconhecida como a assinatura dos métodos. 135 Está correto o que consta APENAS em xx (a) I e II. (b) I e III. (c) II e III. (d) II. (e) I. 136. (ICMS-SP 2009) A .NET Framework trata-se de uma arquitetura da estratégia Microsoft .NET I. constituída das partes Common Language Runtime, bibliotecas de classes, ASP.NET e ADO.NET. II. para construir, implementar e executar aplicações e webservices. III. desenvolvida como um componente integral do Windows. 136 Está correto o que consta em (a) I, apenas. (b) II, apenas. (c) I e II, apenas. xx (d) II e III, apenas. (e) I, II e III.<br />
<br />
103<br />
<br />
TI para concursos<br />
<br />
137. (ICMS-SP 2009) NÃO é uma linguagem de programação do pacote Visual Studio 2005 que utiliza o mesmo 137 IDE e as funcionalidades da .NET Framework: (a) Visual Basic. xx (b) Visual FoxPro. (c) Visual C++. (d) Visual C#. (e) Visual J#. 138. (ICMS-SP 2009) A .NET Framework 3.0 é o modelo de programação de código gerenciado da Microsoft, que 138 integra os componentes da .NET Framework 2.0 às novas tecnologias (a) WPF (Windows Presentation Foundation) e WCF (Windows Communication Foundation), apenas. (b) WF (Windows Workflow Foundation) e Windows CardSpace, apenas. (c) WPF, WCF e WF, apenas. (d) WPF, WCF e Windows CardSpace, apenas. xx (e) WPF, WCF, WF e Windows CardSpace. 139. (ICMS-SP 2009) O IDE do Visual Studio 2005 fornece suporte completo para publicação de aplicativos e para atualização de aplicativos implantados por meio diretamente do ClikOnce apenas para projetos criados 139 com xx (a) Visual Basic, Visual C# e Visual J#. (b) Visual Basic, Visual FoxPro e Visual C++. (c) Visual Basic e Visual FoxPro. (d) Visual C# e Visual J#. (e) Visual C# e Visual C++. 140. (ICMS-SP 2009) A opção de escolha no Visual Studio 2005 para usar Web Forms como interface de usuário 140 no desenvolvimento de um aplicativo indica que o aplicativo deverá ser implantado no (a) servidor e que o .NET Framework deverá ser executado tanto no servidor quanto no computador cliente. (b) servidor, que o .NET Framework deverá ser executado no servidor e que o computador cliente exigirá xx apenas um navegador. (c) servidor e que o .NET Framework deverá ser executado apenas no computador cliente e não no servidor. (d) computador cliente e que o .NET Framework deverá ser executado apenas no computador cliente e não no servidor. (e) computador cliente e que o .NET Framework deverá ser executado tanto no servidor quanto no computador cliente. 141. Uma ou mais instruções são executadas ou não, dependendo do resultado do teste efetuado. Esta afirmação 141 define uma estrutura de controle de programação do tipo (a) pilha. (b) seleção.xx (c) fila. (d) repetição. (e) seqüência. 142. A estrutura de dados de iteração na qual uma ação será executada pelo menos uma vez, antes da avaliação 142 da condição, é implementada pelo comando básico (a) condicional. (b) faça enquanto. (c) seqüencial. xx (d) de repetição. (e) de seleção. 143. Em uma hierarquia de classes é possível especificar operações com a mesma assinatura em pontos 143 diferentes da hierarquia. Portanto, essas operações presentes nas classes-filha (a) anulam o comportamento das operações existentes nas classes-mãe.xx (b) herdam os atributos existentes nas classes-mãe. (c) são composições de alguns atributos existentes nas classes-mãe. (d) complementam o comportamento das operações existentes nas classes-mãe. (e) agregam as operações existentes nas classes-mãe. 144. As instâncias de uma classe são (a) seus atributos. (b) suas superclasses. (c) suas operações. (d) seus objetos.xx (e) seus relacionamentos.<br />
<br />
144<br />
<br />
145. A nomenclatura da linguagem C++ para Chamada de Função e Classe Base corresponde, respectivamente, 145 na programação orientada a objetos a (a) Método e Subclasse. (b) Método e Superclasse. (c) Hereditariedade e Subclasse. (d) Mensagem e Subclasse. xx (e) Mensagem e Superclasse. 104<br />
<br />
TI para concursos<br />
<br />
146. Em um diagrama entidade relacionamento, uma situação de composição tal qual "empregado gerencia 146 empregado", geralmente é apresentada como (a) entidade fraca. (b) relacionamento associativo. (c) auto relacionamento.xx (d) relacionamento interativo. (e) relacionamento restritivo. 147<br />
<br />
147. A execução de uma expressão lógica obedece como prioridade a ordem dos operadores (a) Or, And e Not. (b) Not, And e Or.xx (c) And, Not e Or. (d) And, Or e Not. (e) Not, Or e And. 148. Respeitando as ordens de inserção e de retirada dos dados, uma estrutura de (a) fila é também denominada LIFO ou LILO. (b) fila é também denominada FIFO ou FILO. (c) fila é também denominada FIFO ou LIFO. (d) pilha é também denominada FIFO ou FILO. xx (e) pilha é também denominada LIFO ou FILO.<br />
<br />
148<br />
<br />
149. Uma fila dupla que se trata de uma lista linear na qual os elementos podem ser inseridos ou removidos de 149 qualquer extremo denomina-se (a) hashing. (b) grafo. xx (c) deque. (d) lista aberta. (e) lista fechada. 150. Sobre a sintaxe XML, considere: I. Um elemento <CALCULA> deve ter sempre uma tag de fechamento <FIMCALCULA>. II. Uma tag <Lista> é diferente da tag <lista>. III. Um elemento <A> aberto no interior do elemento <B> pode ser fechado fora do elemento <B>. 150 Está correto o que consta APENAS em (a) III. (b) II.xx (c) II e III. (d) I e III. (e) I e II. 151. Em (a) (b) (c) (d) (e)<br />
<br />
151<br />
<br />
XML pode-se definir um atributo, como informação adicional ao elemento, conforme o exemplo abaixo: <funcionario> <sexo> masculino ... <funcionario sexo=masculino> ... <funcionario sexo="masculino">xx... <funcionario> <sexo> "masculino" ... <funcionario <sexo>= "masculino"> ... 152<br />
<br />
152. NÃO é um tipo de dados considerado primitivo: (a) real. (b) inteiro. (c) lógico. (d) caracter. xx (e) matriz.<br />
<br />
105<br />
<br />
TI para concursos<br />
<br />
8<br />
<br />
Segurança da informação<br />
<br />
8.1<br />
<br />
Conceitos básicos Segurança da Informação é a proteção de um conjunto de dados, no sentido de preservar o valor que possuem para um indivíduo ou uma organização. O conceito de Segurança Informática ou Segurança de Computadores inclue a segurança dos dados/informação e a dos sistemas em si.48 Entende-se por informação todo e qualquer conteúdo ou dado que tenha valor para alguma organização ou pessoa. Ela pode estar guardada para uso restrito ou exposta ao público para consulta ou aquisição. Podem ser estabelecidas métricas para a definição do nível de segurança existente e, com isto, serem estabelecidas as bases para análise da situação. A segurança de uma determinada informação pode ser afetada por fatores comportamentais e de uso de quem se utiliza dela, pelo ambiente ou infraestrutura. Os atributos básicos da segurança: Confidencialidade - propriedade que limita o acesso a informação às entidades legítimas, ou seja, àquelas autorizadas pelo proprietário da informação. Integridade - propriedade que garante que a informação mantenha todas as características originais estabelecidas pelo proprietário da informação, incluindo controle de mudanças e garantia do seu ciclo de vida (nascimento, manutenção e destruição). Disponibilidade - propriedade que garante que a informação esteja sempre disponível para o uso legítimo, ou seja, por aqueles usuários autorizados pelo proprietário da informação. O nível de segurança desejado, pode se consubstanciar em uma "política de segurança" que é seguida pela organização ou pessoa, para garantir que uma vez estabelecidos os princípios, aquele nível desejado seja perseguido e mantido. Para a montagem desta política, deve-se levar em conta: Riscos associados à falta de segurança; Benefícios; Custos de implementação dos mecanismos. O suporte para as recomendações de segurança pode ser encontrado em: Controles físicos: são barreiras que limitam o contato ou acesso direto a informação ou a infraestrutura que a suporta, como portas, trancas, paredes, blindagem, guardas etc. Controles lógicos: são barreiras que impedem ou limitam o acesso a informação, que está em ambiente controlado, geralmente eletrônico. Mecanismos de criptografia. Permitem a transformação reversível da informação de forma a torná-la ininteligível a terceiros. Utiliza-se para tal, algoritmos determinados e uma chave secreta para, a partir de um conjunto de dados não criptografados, produzir uma sequência de dados criptografados. A operação inversa é a decifração. Os algoritmos com chave dupla, ou chaves assimétricas, podem usar uma chave pública para criptografar e uma chave diferente, privada, secreta, para decifrar. Assinatura digital. Um conjunto de dados criptografados, associados a um documento do qual são função, garantindo a integridade do documento associado, mas não a sua confidencialidade. Mecanismos de garantia da integridade da informação. Usando funções de "Hashing" ou de checagem, consistindo na adição. Mecanismos de controle de acesso. Palavras-chave, sistemas biométricos, firewalls, cartões inteligentes. Mecanismos de certificação. Atesta a validade de um documento. Integridade. Medida em que um serviço/informação é genuíno, isto é, está protegido contra a personificação por intrusos. Honeypot: É o nome dado a um software, cuja função é detectar ou de impedir a ação de um cracker, de um spammer, ou de qualquer agente externo estranho ao sistema, enganando-o, fazendo-o pensar que esteja de fato explorando uma vulnerabilidade daquele sistema. Protocolos seguros: uso de protocolos que garantem um grau de segurança.<br />
<br />
Existe hoje em dia um elevado número de ferramentas e sistemas que pretendem fornecer segurança. Alguns exemplos são os detectores de intrusões, os anti-vírus, firewalls, firewalls locais, filtros antispam, fuzzers, analisadores de código, etc.<br />
<br />
48<br />
<br />
http://pt.wikipedia.org/wiki/Seguran%C3%A7a_da_informa%C3%A7%C3%A3o<br />
<br />
106<br />
<br />
TI para concursos<br />
<br />
As ameaças à segurança da informação são relacionadas diretamente à perda de uma de suas três características principais, quais sejam: Perda de Confidencialidade: quebra de sigilo de uma determinada informação (ex: a senha de um usuário ou administrador de sistema) permitindo com que sejam expostas informações restritas as quais seriam acessíveis apenas por um determinado grupo de usuários. Perda de Integridade: determinada informação fica exposta a manuseio por uma pessoa não autorizada, que efetua alterações que não foram aprovadas e não estão sob o controle do proprietário (corporativo ou privado) da informação. Perda de Disponibilidade: a informação deixa de estar acessível por quem necessita dela. No caso de ameaças à rede de computadores ou a um sistema, estas podem vir de agentes maliciosos, muitas vezes conhecidos como crackers (hackers não são agentes maliciosos, pois tentam ajudar a encontrar possiveis falhas). Estas pessoas são motivadas para fazer esta ilegalidade por vários motivos. Os principais são: notoriedade, auto-estima, vingança e o dinheiro. De acordo com pesquisa elaborada pelo Computer Security Institute, mais de 70% dos ataques partem de usuários legítimos de sistemas de informação (Insiders) -- o que motiva corporações a investir largamente em controles de segurança para seus ambientes corporativos (intranet). Depois de identificado o potencial de ataque, as organizações têm que decidir o nível de segurança a estabelecer para uma rede ou sistema os recursos físicos e lógicos a necessitar de proteção. No nível de segurança devem ser quantificados os custos associados aos ataques e os associados à implementação de mecanismos de proteção para minimizar a probabilidade de ocorrência de um ataque. Segurança física - Considera as ameaças físicas como incêndios, desabamentos, relâmpagos, alagamento, acesso indevido de pessoas, forma inadequada de tratamento e manuseamento do material. Segurança lógica - Atenta contra ameaças ocasionadas por vírus, acessos remotos à rede, backup desatualizados, violação de senhas etc. De acordo com o RFC 2196 (The Site Security Handbook), uma política de segurança consiste num conjunto formal de regras que devem ser seguidas pelos utilizadores dos recursos de uma organização. As políticas de segurança devem ter implementação realista, e definir claramente as áreas de responsabilidade dos utilizadores, do pessoal de gestão de sistemas e redes e da direção. Deve também adaptar-se a alterações na organização. As políticas de segurança fornecem um enquadramento para a implementação de mecanismos de segurança, definem procedimentos de segurança adequados, processos de auditoria à segurança e estabelecem uma base para procedimentos legais na sequência de ataques. O documento que define a política de segurança deve deixar de fora todos os aspectos técnicos de implementação dos mecanismos de segurança, pois essa implementação pode variar ao longo do tempo. Deve ser também um documento de fácil leitura e compreensão, além de resumido. Algumas normas definem aspectos que devem ser levados em consideração ao elaborar políticas de segurança. Entre essas normas estão a BS 7799 (elaborada pela British Standards Institution) e a NBR ISO/IEC 17799 (a versão brasileira desta primeira). A ISO começou a publicar a série de normas 27000, em substituição à ISO 17799 (e por conseguinte à BS 7799), das quais a primeira, ISO 27001, foi publicada em 2005. Existem duas filosofias por trás de qualquer política de segurança: a proibitiva (tudo que não é expressamente permitido é proibido) e a permissiva (tudo que não é proibido é permitido). Os elementos da política de segurança devem ser considerados: Disponibilidade: o sistema deve estar disponível de forma que quando o usuário necessitar possa usar. Dados críticos devem estar disponíveis ininterruptamente. Utilização: o sistema deve ser utilizado apenas para os determinados objetivos. Integridade: o sistema deve estar sempre íntegro e em condições de ser usado. Autenticidade: o sistema deve ter condições de verificar a identidade dos usuários, e este ter condições de analisar a identidade do sistema. Confidencialidade: dados privados devem ser apresentados somente aos donos dos dados ou ao grupo por ele liberado.<br />
<br />
107<br />
<br />
TI para concursos<br />
<br />
8.2<br />
<br />
Plano de Continuidade de Negócio Business Continuity Plan (BCP) é o desenvolvimento preventivo de um conjunto de estratégias e planos de ação de maneira a garantir que os serviços essenciais sejam devidamente identificados e preservados após a ocorrência de um desastre e até o retorno à situação normal de funcionamento da empresa dentro do contexto do negócio do qual ela faz parte. Além disso, sob o ponto de vista do PCN, o funcionamento de uma empresa deve-se a duas variáveis: os componentes e os processos.49 Os componentes são todas as variáveis utilizadas para realização dos processos: energia, pessoas, telecomunicações, informática, infra-estrutura. Todas elas podem ser substituídas ou restauradas, de acordo com suas características. Já os processos são as atividades realizadas para operar os negócios da empresa. O Plano de Continuidade de Negócios é constituído pelos seguintes planos: Plano de Administração de Crises (PAC) Plano de Recuperação de Desastres (PRD) Plano de Continuidade Operacional (PCO) Todos estes planos têm como objetivo principal a formalização de ações a serem tomadas para que, em momentos de crise, a recuperação, a continuidade e a retomada possam ser efetivas, evitando que os processos críticos de negócio da organização sejam afetados, o que pode acarretar em perdas financeiras. No que diz respeito à necessidade de atualizações, o Plano de Continuidade de Negócios deve ser revisado periodicamente, pois mudanças significativas em componentes, atividades ou processos críticos de negócio podem fazer com que novas estratégias e planos de ação sejam previstos, evitando assim com que eventuais desastres desestabilizem profundamente o andamento regular do negócio da empresa. Desastre pode ser entendido como qualquer situação que afete os processos críticos do negócio de uma organização. Conseqüentemente, algumas ocorrências podem ser caracterizadas como sendo desastres para uma determinada empresa, mas podem não ser caracterizadas como um desastre para outra empresa. As principais etapas de um plano de continuidade são: Analise de riscos - Analisa-se o grau de exposição a que o negócio pode estar exposto. Sejam exposições de ação natural (vendaval, inundação, fogo) ou aquelas da ação do homem (sabotagem, erro ou falha humana). Analise dos impactos no negócio - análise dos impactos da perda no negócio da organização. Neste estudo devem-se identificar as aplicações mais criticas para o negócio e seu tempo de recuperação necessário para a continuidade. Estratégia de recuperação - planejamento do maior número de possibilidades e formas de recuperação, que seja rápida, eficiente e com baixo custo.<br />
<br />
8.3<br />
<br />
Vulnerabilidade A vulnerabilidade na computação significa ter brecha em um sistema computacional, também conhecida como bug. Esta mesma pode ser explorada em um determinado sistema ou serviço vulnerável que esteja rodando na máquina. As vulnerabilidades mais exploradas nos dias de hoje, são as do tipo buffer overflow, que muitas vezes pode dar privilégios de administrador para o invasor, rodar códigos maliciosos remotamente, burlar particularidades de cada sistema, ataques de Negação de Serviços (DDoS), e acesso irestrito ao sistema. Existem ferramentas específicas para se explorar as vulnerabilidades, cada ferramenta para a sua respectiva vulnerabilidade a ser explorada (na maioria das vezes escritas em linguagem C e Assembly), essas ferramentas são chamadas de exploits. Um exploit, em segurança da informação, é um programa de computador, uma porção de dados ou uma sequência de comandos que se aproveita das vulnerabilidades de um sistema computacional – como o próprio sistema operacional ou serviços de interação de protocolos (ex: servidores Web). São geralmente elaborados por hackers como programas de demonstração das vulnerabilidades, a fim de que as falhas sejam corrigidas, ou por crackers a fim de ganhar acesso não autorizado a sistemas. Por<br />
<br />
49<br />
<br />
http://pt.wikipedia.org/wiki/Plano_de_continuidade_de_neg%C3%B3cios<br />
<br />
108<br />
<br />
TI para concursos<br />
<br />
isso muitos crackers não publicam seus exploits, conhecidos como 0days, e o seu uso massificado deve-se aos script kiddies. Até meados dos anos 90, acreditava-se que os exploits exploravam exclusivamente problemas em aplicações e serviços para plataformas Unix. A partir do final da década, especialistas demonstraram a capacidade de explorar vulnerabilidades em plataformas de uso massivo, por exemplo, sistemas operacionais Win32 (Windows 9x, NT, 2000 e XP). Como exemplo temos o CodeRed, o MyDoom, o Sasser em 2004 e o Zotob em 2005. Para um exploit atacar, o sistema precisa ter uma vulnerabilidade, ou seja, um meio de comunicação com a rede que possa ser usado para entrar, uma porta ou uma consola. Um exploit muito usado é no sistema RPC do Windows: o usuário localiza a porta e envia à porta RPC uma sequência de bytes, que são interpretados como dados pelo servidor quando são recebidos, estes dados deixam propositadamente o sistema em pane o sistema passa o controle a estes próprios dados que então são uma sequência de ordem para dominar a CPU.<br />
<br />
Desta forma esta sequência de informações toma conta do PC e abre-o para o hacker que aguarda na outra ponta. Ameaças à segurança das redes que fazem com que os micros infectados por esses tipos de vírus formem redes de computadores "zumbis" que são comandados simultaneamente por seus invasores para enviar mensagens indesejadas (spam), colocar sites fora do ar e promover fraudes são categorizadas como botnet (robôs). Keylogger é um programa capaz de capturar e armazenar as teclas digitadas pelo usuário no teclado de um computador. No sistema Linux, quando existem vulnerabilidades, sempre são publicadas, como já houve no sistema Apache, Samba ou MySQL, que também apresentam vulnerabilidades e possibilita o controle do PC por um hacker remoto. Com isso um hacker pode ter acesso a todos seus arquivos pessoais, Usando o proprio CMD do windows.<br />
<br />
8.4<br />
<br />
Auditoria e conformidade A Auditoria da TI é uma auditoria operacional, analisa a gestão de recursos, com o foco nos aspectos de eficiência, eficácia, economia e efetividade. A abrangência desse tipo de auditoria pode ser o ambiente de informática como um todo ou a organização do departamento de informática:50 Ambiente de informática: <br />
<br />
Segurança dos outros controles; Segurança física; Segurança lógica; Planejamento de contingências; Operação do centro de processamento de dados.<br />
<br />
Organização do departamento de informática: Aspectos administrativos da organização; Políticas, padrões, procedimentos, responsabilidades organizacionais, gerência pessoal e planejamento de capacidade; Banco de dados; Redes de comunicação e computadores; Controle sobre aplicativos: Desenvolvimento, Entradas, processamento e saídas.<br />
<br />
Auditoria da tecnologia da informação é abrangente, engloba todos os controles que podem influenciar a segurança de informação e o correto funcionamento dos sistemas de toda a organização: Controles organizacionais; De mudança; De operação de sistemas; Sobre Banco de Dados; 50<br />
<br />
http://pucrs.campus2.br/~annes/sas_audit.doc<br />
<br />
109<br />
<br />
TI para concursos<br />
<br />
Sobre microcomputadores; Sobre ambiente cliente-servidor. Auditoria da segurança de informações determina a postura da organização com relação à segurança. Avalia a política de segurança e controles relacionados com aspectos de segurança institucional mais globais, faz parte da auditoria da TI. Seu escopo envolve: Avaliação da política de segurança; Controles de acesso lógico; Controles de acesso físicos; Controles ambientais; Planos de contingência e continuidade de serviços. Auditoria de aplicativos verifica a segurança e o controle de aplicativos específicos, incluindo aspectos intrínsecos à área a que o aplicativo atende: Controles sobre o desenvolvimento de sistemas aplicativos; Controles de entradas, processamento e saída de dados; Controle sobre conteúdo e funcionamento do aplicativo, com relação à área por ele atendida. A natureza especializada da auditoria de sistemas de informação (SI) e a capacidade necessária para realizar essas auditorias requerem o estabelecimento de normas que se apliquem especificamente à auditoria de SI. 51 A Associação de Auditoria e Controle de Sistemas de Informação, ISACA, desenvolve normas aplicáveis globalmente, de forma a suportar essa visão. A estrutura das Normas de Auditoria de SI apresenta diversos níveis de orientação: Normas: definem requisitos obrigatórios para auditorias e relatórios de SI. Informam: Os auditores de SI sobre o nível mínimo de desempenho aceitável exigido para cumprir as responsabilidades profissionais estabelecidas no Código de Ética Profissional A gestão e outras partes interessadas sobre as expectativas da profissão no que se refere às atividades daqueles que a exercem<br />
<br />
Diretrizes: fornecem orientação para a aplicação das normas de auditoria de SI. O auditor de SI deve levá-las em consideração para determinar como alcançar a implementação das normas, utilizar a avaliação profissional na sua aplicação e estar preparado para justificar qualquer divergência. O objetivo das Directrizes de Auditoria de SI é fornecer informações adicionais sobre como cumprir as Normas de Auditoria de SI. Procedimentos: fornecem exemplos de procedimentos que um auditor de SI pode seguir durante a realização de uma auditoria. Os documentos de procedimentos fornecem informações sobre como cumprir as normas ao realizar a auditoria de SI, mas não estabelecem requisitos. O objetivo dos Procedimentos de Auditoria de SI é fornecer informações adicionais sobre como cumprir as Normas de Auditoria de SI. As normas da ISACA contêm princípios básicos e procedimentos essenciais que são obrigatórios, juntamente com orientações relacionadas com os mesmos, com o objetivo de estabelecer e fornecer orientações sobre áreas de governança de TI que o auditor de SI deve considerar durante o processo de auditoria. O auditor de SI deve analisar e avaliar: ambiente de controle da organização. conformidade com a organização: missão, visão, valores, qualidade de informações, objetivos e estratégias. conformidade com as leis: ambientais, trabalhistas, fiduciárias e de segurança. eficiência e eficácia de SI, as suas realizações e os processos de gestão de desempenho. riscos que podem causar efeitos adversos no ambiente de SI.<br />
<br />
Diretrizes de auditoria de SI: 51<br />
<br />
Carta de auditoria Conceitos de materialidade para auditoria de sistemas de informações Relacionamento e independência organizacionais Uso da avaliação de riscos no planeamento de auditoria Planeamento - lista detalhada das tarefas Impacto de terceiros em controles de TI de uma organização<br />
<br />
http://www.isaca.org/Template.cfm?Section=Home&Template=/ContentManagement/ContentDisplay.cfm&ContentFileID=10775<br />
<br />
110<br />
<br />
TI para concursos<br />
<br />
Impacto de função de não auditoria na independência do auditor de SI<br />
<br />
8.5<br />
<br />
Conhecimento sobre norma ISO 27001 ISO/IEC 27001 é um padrão para sistema de gerência da segurança da informação (ISMS - Information Security Management System) publicado em outubro de 2005 pelo International Organization for Standardization e pelo International Electrotechnical Commision. Seu nome completo é ISO/IEC 27001:2005 - Tecnologia da informação - técnicas de segurança - sistemas de gerência da segurança da informação - requisitos mas conhecido como "ISO 27001".52 Seu objetivo é ser usado em conjunto com ISO/IEC 17799, o código de práticas para gerência da segurança da informação, o qual lista objetivos do controle de segurança e recomenda um conjunto de especificações de controles de segurança. Organizações que implementam um ISMS de acordo com as melhores práticas da ISO 17799 estão simultaneamente em acordo com os requisitos da ISO 27001, mas uma certificação é totalmente opcional. Este padrão é o primeiro da família de segurança da informação relacionado aos padrões ISO que espera-se sejam agrupados à série 27000. Outros foram incluídos antecipadamente: ISO 27000 - Vocabulário de Gestão da Segurança da Informação (sem data de publicação); ISO 27001 - Esta norma foi publicada em Outubro de 2005 e substituiu a norma BS 7799-2 para certificação de sistema de gestão de segurança da informação; ISO 27002 - Esta norma irá substituir em 2006/2007 o ISO 17799:2005 (Código de Boas Práticas); ISO 27003 - Esta norma abordará a gestão de risco, contendo recomendações para a definição e implementação de um sistema de gestão de segurança da informação. Deverá ser publicada em 2006; ISO 27004 - Esta norma incidirá sobre os mecanismos de mediação e de relatório de um sistema de gestão de segurança da informação. A sua publicação deverá ocorrer em 2007; ISO 27005 - Esta norma será constituída por indicações para implementação, monitoramento e melhoria contínua do sistema de controles. O seu conteúdo deverá ser idêntico ao da norma BS 7799-3:2005 – “Information Security Management Systems - Guidelines for Information Security Risk Management”, a publicar em finais de 2005. A publicação da norma ISO 27005 ocorreu em meados de 2008; ISO 27006 - Esta norma será referente à recuperação e continuidade de negócio. Este documento tem o título provisório de “Guidelines for information and communications technology disaster recovery services”, não estando calendarizado a sua edição. ISO 27001 foi baseado e substitui o BS 7799 parte 2, o qual não é mais válido. A série ISO 27000 está de acordo com outros padrões de sistemas de gerência ISO, como ISO 9001 (sistemas de gerência da qualidade) e ISO 14001 (sistemas de gerência ambiental), ambos em acordo com suas estruturas gerais e de natureza a combinar as melhores práticas com padrões de certificação. Certificações de organização com ISMS ISO/IEC 27001 é um meio de garantir que a organização certificada implementou um sistema para gerência da segurança da informação de acordo com os padrões. Credibilidade é a chave de ser certificado por uma terceira parte que é respeitada, independente e competente. Esta garantia dá confiança à gerência, parceiros de negócios, clientes e auditores que uma organização é séria sobre gerência de segurança da informação - não perfeita, necessariamente, mas está rigorosamente no caminho certo de melhora contínua.<br />
<br />
8.6<br />
<br />
Exercícios 153. (ICMS-SP 2009) Segundo as normas ABNT sobre segurança da informação, o tratamento de risco está 153 inserido no processo de xx (a) gestão de riscos. (b) aceitação do risco. (c) análise de riscos. (d) avaliação de riscos. (e) análise/avaliação de riscos.<br />
<br />
52<br />
<br />
http://pt.wikipedia.org/wiki/ISO_27001<br />
<br />
111<br />
<br />
TI para concursos<br />
<br />
154. (ICMS-SP 2009) As ações a serem tomadas imediatamente após a ocorrência de um incidente que coloque em risco as operações do negócio devem estar descritas no plano de continuidade de negócios como 154 procedimentos (a) operacionais temporários. (b) de ensaio geral. (c) de recuperação. (d) de restauração. xx (e) de emergência. 155. (ICMS-SP 2009) Se qualquer não-conformidade for encontrada como um resultado da análise crítica nas áreas sobre o cumprimento das políticas e normas de segurança da informação, NÃO convém que os 155 gestores (a) determinem as causas da não-conformidade. (b) determinem e implementem ação corretiva apropriada. (c) analisem criticamente a ação corretiva tomada. xx (d) avaliem a necessidade de ações para assegurar que a conformidade não se repita. (e) registrem os resultados das análises e das ações corretivas e que esses registros sejam mantidos. 156. (ICMS-SP 2009) No modelo PDCA adotado para estruturar todos os processos do SGSI – Sistema de Gestão de Segurança da Informação, os resultados das atividades da auditoria interna do SGSI estão 156 vinculados ao ciclo PDCA como entrada dos processos na etapa (a) Plan (Planejar): estabelecer o SGSI. (b) Do (Fazer): implementar e operar o SGSI. (c) Check (Verificar): monitorar o SGSI. (d) Control (Controlar): analisar criticamente o SGSI. xx (e) Act (Agir): manter e melhorar o SGSI. 157. No Brasil, a NBR ISO17799 constitui um padrão de recomendações para práticas na gestão de Segurança da Informação. De acordo com o estabelecido nesse padrão, três termos assumem papel de importância capital: confidencialidade, integridade e disponibilidade. 157 Nesse contexto, a confidencialidade tem por objetivo: (a) salvaguardar a exatidão e a inteireza das informações e métodos de processamento. (b) salvaguardar os dados gravados no backup por meio de software que utilize assinatura digital. (c) permitir que os usuários tenham acesso aos arquivos de backup e aos métodos de criptografia empregados. (d) permitir que os usuários autorizados tenham acesso às informações e aos ativos associados, quando necessário. (e) garantir que as informações sejam acessíveis apenas para aqueles que estejam autorizados a acessáxx las. 158. Para garantir a segurança da informação em uma rede de computadores, um sistema de autenticação típico 158 é composto apenas do código do usuário, uma senha e um (a) processo de certificação. (b) método de criptografia. (c) sistema de detecção de intrusão. (d) plano de recuperação. xx (e) firewall. 159. NÃO é um algoritmo de chave simétrica o sistema de criptografia de chave (a) única. (b) pública.xx (c) secreta. (d) simétrica. (e) compartilhada.<br />
<br />
159<br />
<br />
160. Um conjunto de dados de computador, em observância à Recomendação Internacional ITUT X.509, que se destina a registrar, de forma única, exclusiva e intransferível, a relação existente entre uma chave de 160 criptografia e uma pessoa física, jurídica, máquina ou aplicação é (a) uma autoridade certificadora. (b) uma trilha de auditoria. (c) uma chave assimétrica. (d) uma assinatura digital. xx (e) um certificado digital.<br />
<br />
112<br />
<br />
TI para concursos<br />
<br />
161. Considere a seguinte definição: "Evitar violação de qualquer lei criminal ou civil, estatutos, regulamentação ou obrigações contratuais; evitar a violação de direitos autorais dos software - manter mecanismos de controle dos softwares legalmente adquiridos". De acordo com as especificações das normas brasileiras de 161 segurança da informação, esta definição se inclui corretamente em (a) Gestão de Incidentes e Segurança da Informação. xx (b) Conformidade. (c) Controle de Acesso. (d) Gestão da Continuidade do Negócio. (e) Gestão de Ativos. 162<br />
<br />
162. É um elemento biométrico de identificação xx (a) a impressão digital. (b) o cartão bancário. (c) a senha da internet. (d) o certificado digital. (e) a assinatura eletrônica.<br />
<br />
163. Ameaças à segurança das redes que fazem com que os micros infectados por esses tipos de vírus formem redes de computadores "zumbis" que são comandados simultaneamente por seus invasores para enviar 163 mensagens indesejadas (spam), colocar sites fora do ar e promover fraudes são categorizadas como. (a) Advance Fee Fraud. (b) Botnet.xx (c) Hoax. (d) Phishing. (e) Rootkit. 164. Programa capaz de capturar e armazenar as teclas digitadas pelo usuário no teclado de um computador é o 164<br />
<br />
(a) (b) (c) (d) (e)<br />
<br />
Worm. Spyware. Backdoor. Keylogger.xx Cavalo de Tróia.<br />
<br />
165. Por meio da análise dos procedimentos para estabelecer e finalizar uma conexão utilizada para troca de informações entre dois hosts, obtém-se informações que permitem uma prospecção sobre os serviços por 165 eles oferecidos. Essa técnica, utilizada para descobrir um possível ataque do tipo DoS, é denominada (a) network security. (b) file scan. (c) packet sniffer. (d) network scan.xx (e) scan vírus. 166<br />
<br />
166. A integridade de software é medida (a) em defeitos por KLOC (milhares de linhas de código). (b) por sua usabilidade. (c) pelo mean-time-to-change - MTTC. (d) por sua conectividade. xx (e) pela capacidade do sistema resistir a ataques à sua segurança. 167<br />
<br />
167. Em relação aos conceitos de segurança, é correto afirmar: (a) Confidencialidade é a propriedade que se refere ao fato de determinada informação não poder ser alterada ou destruída de maneira não autorizada. (b) Medidas físicas e organizacionais de proteção relacionam-se não apenas à proteção de hardware, mas xx também a elementos lógicos de um sistema. (c) Umidade e temperatura não podem ser consideradas ameaças a uma rede de SI. (d) Negação de uso é um ataque que visa atingir a integridade de um sistema computacional. (e) Um firewall de rede tornou-se, em dias atuais, um equipamento desnecessário, desde que todos os computadores da rede sejam dotados de antivírus ativos e atualizados. 168. A Disponibilidade do sistema, a Integridade dos dados e a Confidencialidade dos dados são objetivos de 168 segurança dos sistemas, respectivamente, sujeitos às ameaças de (a) Adulteração dos dados, Recusa de serviço e Exposição aos dados. (b) Recusa de serviço, Exposição aos dados e Adulteração dos dados. (c) Exposição aos dados, Recusa de serviço e Adulteração dos dados. xx (d) Recusa de serviço, Adulteração dos dados e Exposição aos dados. (e) Exposição aos dados, Adulteração dos dados e Recusa de serviço. 169. Na disciplina de segurança de redes e criptografia, a propriedade que traduz a confiança em que a 169 mensagem não tenha sido alterada desde o momento de criação é: (a) autenticidade. (b) criptologia. (c) não-repúdio. xx (d) integridade. (e) confidencialidade. 113<br />
<br />
TI para concursos<br />
<br />
170. Os mecanismos de segurança para autenticação efetiva de um usuário devem ser baseados em: I. Conhecimento individual. II. Posse de alguma coisa. III. Característica pessoal. IV. Local em que se encontra. 170 É correto o que se afirma em (a) I, II e III, apenas. (b) I, II e IV, apenas. (c) I, III e IV, apenas. (d) II, III e IV, apenas. xx (e) I, II, III e IV. 171. Receber as solicitações de serviços, oriundas de clientes internos, e enviá-las para a rede externa como se 171 fosse o cliente de origem é uma função do (a) criptógrafo. (b) firewall. xx (c) proxy. (d) soquete. (e) broadcast. 172<br />
<br />
172. Sobre segurança da informação, é correto afirmar que (a) vulnerabilidades determinam controles de segurança. (b) riscos são determinados pelas vulnerabilidades. (c) controles de segurança eliminam os riscos. xx (d) ameaças exploram vulnerabilidades. (e) vulnerabilidades provocam ameaças. 173. O controle de acesso lógico pode utilizar, para proteção aos arquivos de dados e de programas, uma senha 173 pessoal como recurso de (a) permissão de acesso. (b) direito de acesso. (c) monitoração de acesso. xx (d) autenticação do usuário. (e) identificação do usuário.<br />
<br />
114<br />
<br />
TI para concursos<br />
<br />
9<br />
<br />
Sistemas Operacionais<br />
<br />
9.1<br />
<br />
Conceitos de administração de servidores em plataforma Windows A administração de servidores Windows é feita sobre uma interface gráfica, com mouse, janelas e botões. Nem por isto a tarefa se torna fácil. O usuário precisa saber em que ícones clicar e que controles modificar. Administrar servidores em plataforma Windows é instalar e manter em funcionamento os serviços que a rede necessita. Este serviços são acessíveis a partir do Painel de Controle e do menu Ferramentas administrativas. O primeiro serviço que deve funcionar muito bem é administração de usuários, que consiste em criar contas, que são identificadas por um nome de usuário (login) e atribuir direitos a eles. Para esta função, utiliza-se o aplicativo “Contas de usuário”, no painel de controle. Usuários com direitos de administradores, conforme a sua configuração, podem fazer tudo, enquanto que usuário comuns só podem usar recursos definidos pelo administrador. O Windows administra os recursos da rede dividindo-a em subredes chamadas de domínios. Em cada domínio há uma lista distinta de usuários e um servidor para controlar. Um servidor na rede que centraliza a configuração de usuários em um domínio é o Primary Domain Controller (PDC), ou controlador primário de domínio. Em uma rede pode haver diversos servidores Windows, mas apenas um servidor primário de domínio para cada domínio, sendo os demais Backup Domain Controle (BDC), ou servidores de backup. Os recursos oferecidos na rede estão, em geral, ligados a um computador. Este computador faz o papel de servidor deste recurso, como serviço de impressão, de conexão internet (proxy e firewall), de armazenamento de dados etc. Mas a permissão de acesso a todos os serviços passa pelo servidor primário do domínio. Dois domínios diferentes podem se comunicar e os usuários de um ser autorizado pelo outro. Para isto o Windows utiliza o conceito de relação de confiança, que é estabelecido entre os dois domínios. Eles passam a se comportar como um único domínio, mas com duas lista de usuários. O Windows utiliza o recurso Active Directory para administrar os domínios como se fossem uma estrutura de diretórios, agrupando domínios em árvores e estas em florestas.<br />
<br />
9.2<br />
<br />
Conceitos de administração de servidores em plataforma Linux A administração de servidores Linux é feita, em geral, por linhas de comando digitadas em uma tela de textos. Por isto, o administrador precisa saber os comandos e sua sitaxe. Existem programas que criam interfaces gráficas, chamados de shells, que facilitam a vida de usuários inesperientes. Os servidores Linux com serviços para internet são mais usados do que os demais sistemas por sua estabilidade e confiabilidade. Assim são os servidores linux: apache, servidor http, que adminstra páginas de internet, proftpd, servidor ftp, para administrar transferências de arquivos Bind, serviço dns, para administração de nomes de domínios Squid, servidor proxy, para controlar a entrada da rede e os acessos externos (firewall)<br />
<br />
9.2.1<br />
<br />
Alguns comandos no Linux cp copia arquivos. cp [opções] [origem] [destino]<br />
<br />
mv move ou renomeia arquivos e diretórios. O processo é semelhante ao do comando cp mas o arquivo de origem é apagado após o término da cópia. mv [opções] [origem] [destino]<br />
<br />
chown muda dono de um arquivo/diretório. Opcionalmente pode também ser usado para mudar o grupo. chown [opções] [dono.grupo] [diretório/arquivo]<br />
<br />
chmod é usado para alterar permissões de arquivos (ou ficheiros) e diretórios (directórios ou pastas). Sua sintaxe é a seguinte: chmod [permissões] arquivo 115<br />
<br />
TI para concursos<br />
<br />
9.2.1.1<br />
<br />
53<br />
<br />
Gerenciando Usuários<br />
<br />
Para adicionar um usuário: adduser <usuário><br />
<br />
Em seguida é necessário definir uma senha para este usuário, utilizando o comando: passwd <usuário><br />
<br />
Para remover um usuário e seu diretório home: userdel -r usuário<br />
<br />
Para obter as permissões de outros usuários: su <usuário><br />
<br />
Se o campo <usuário> for omitido, o su intenderá como root. E para simular um login, executando os scripts de inicialização do usuário acrescenta-se “- “ entre su e o <usuário> , como no exemplo: su - vinicius<br />
<br />
9.2.1.2<br />
<br />
Diretório /etc O diretório /etc contém todas as configurações do servidor, por isso deve-se conhecer todo o seu conteúdo e também ter uma preocupação especial com as permissões de arquivos nele contidos: passwd - ficam os usuários cadastrados no sistema. Cada linha corresponde a um usuário e o caracter “:” separa os campos. Analisando o exemplo abaixo: vinic:x:1001:0:Vinicius Schmidt,,,:/home/vinic:/bin/bash login:Senha:Id:Gid:Nome e Dados:Diretório:Shell Login: É a identificação do usuário que também pode ser usado para identificação do email. Senha: “ x “ informa que a senha está em outro arquivo mais seguro. Id: código único para o Linux identificar cada usuário. Nunca deve-se ter dois usuários com o mesmo código. Gid: código do grupo primário que o usuário pertence. Nome e Dados: usado para armazenar informações sobre o usuário como nome, telefone, sala, etc.. Esses dados são separados por “,” e devem obedecer um padrão. Diretório: informa qual é o directório home, do usuário. Shell: shell default do usuário. Para usuários que não precisam de shell deve-se colocar “/dev/null”.<br />
<br />
shadow - ficam gravadas todas as senhas (criptografadas) de acesso ao sistema. group - descreve quais são os grupos do sistema. O primeiro campo corresponde ao nome do grupo, o segundo campo a senha, o terceiro é o chamado GID ou Group ID, e o próximo campo são os usuários pertencentes a este grupo, observando que os mesmos são separados por “,“. Inittab - arquivo principal de inicialização do Linux, ele é quem dá inicio aos demais arquivos dentro do diretório /etc/rc.d . O modo mais usado é o “3” que indica para iniciar todas as tarefas, mas continuar no console. Existe também o modo “5” que entra com a tela de login já em modo gráfico. Veja detalhes no Apêndice E, Níveis de Execução no Red Hat Linux . Fstab - configura os sistemas de arquivos montados durante o processo de inicialização do Linux. Estabelece os pontos default de montagem do sistema. O arquivo /etc/fstab permite configurar o sistema para montar partições, cdroms, disquetes e compartilhamentos de rede durante o boot. Cada linha é responsável por um ponto de montagem. login.defs - É o arquivo de configurações do login, possui informações valiosas para melhorar a segurança do seu ambiente. É um arquivo muito simples de configurar pois é baseado em exemplos, e seus parâmetros são simples. Profile - Toda vez que um usuário loga, este arquivo é executado, por isso ele é usado para setar as variáveis de ambiente globais, dentre outras coisas. hosts.deny - Hosts que não tem permissão para acessar a máquina. hosts.allow - Hosts que tem permissão para acessar a máquina. Services - Este arquivo descreve a relação entre os serviços e as portas mais comuns. 9.2.1.3<br />
<br />
Diretórios mais importantes: • /etc/rc.d - arquivos responsáveis pela carga dos daemons na inicialização do Linux. • /etc/skel - arquivos que serão copiados para o home de um usuário recém criado.<br />
<br />
53<br />
<br />
http://apostilas.netsaber.com.br/apostilas/1662.pdf<br />
<br />
116<br />
<br />
TI para concursos<br />
<br />
9.2.2<br />
<br />
Gerenciando a iniciação do Linux O lilo e o grub disputam o posto de gerenciador de boot default entre as distribuições Linux. São os responsáveis pela “carga” do kernel do Linux na memória. Sem o gerenciador de boot o sistema simplesmente não inicializa. Muitas distribuições permitem que você escolha entre usar o lilo ou o grub durante a instalação. Outras usam um dos dois por padrão. O grub oferece mais opções e inclui um utilitário, o update-grub que gera um arquivo de configuração básico automaticamente. Por outro lado, a sintaxe do arquivo de configuração do grub é mais complexa o que o torna bem mais difícil de editar manualmente que o do lilo. O lilo utiliza um único arquivo de configuração, o /etc/lilo.conf. Ao fazer qualquer alteração neste arquivo é preciso chamar o executável do lilo, o "/sbin/lilo" para que ele leia o arquivo e salve as alterações.. O grub usa o arquivo de configuração /boot/grub/menu.lst. Este arquivo é lido a cada boot, por isso não é necessário reinstalar o grub ao fazer alterações, como no caso do lilo.<br />
<br />
9.2.3<br />
<br />
Fazendo Backups Realizar backups do sistema hoje em dia é uma tarefa essencial de todo administrador. No Linux podese usar o comando tar para compactar os arquivos. Sintaxe: tar [opções] [-f arquivo] Opções: x : descompactar. t : lista o conteúdo de um arquivo. v : mostra na tela o que está sendo feito. z : descompacta arquivos que também estejam gzipados . f : especifica o nome do arquivo. c : cria um novo arquivo.<br />
<br />
Exemplos: tar cvzf meu_backup.tgz ~ tar cvzf backup.tgz /home tar xvzf /root/backup.tar.gz<br />
<br />
9.2.4<br />
<br />
(faz o backup de sua área pessoal) (faz o backup da área dos usuários ) (descompacta o backup)<br />
<br />
Recompilando e Adaptando o Kernel Os administradores devem se preocupar em manter a máquina mais enxuta possível e para isso devese recompilar o kernel apenas com o necessário. Uma sugestão é a separação em módulos, o que sem dúvida reduzirá o “peso” da máquina. Para recompilar o kernel deve-se baixar o fonte de uma versão estável no site http://www.kernel.org ou um mirror confiável. O fonte deve ser descompactado no diretório /usr/src. No diretório /usr/src/linux devem ser feitos alguns procedimentos: make menuconfig - Entra no modo de configuração do kernel. Um ambiente amigável de fácil compreensão onde se pode marcar os pacotes que serão usados. make dep - Acerta as dependências das bibliotecas necessárias para a compilação. make - Compila o kernel. make modules - Compila os módulos. make install - Instala o kernel. make modules_install - Instala os módulos.<br />
<br />
9.2.5<br />
<br />
Agendando Processos Para agendar processos muito demorados como o download de um arquivo muito grande, ou qualquer outro processo que necessite de uma execução automática, deve-se usar basicamente dois comandos: at - agenda a execução de um comando e logo depois que esse processo ocorre este comando não será mais executado crontab - agenda processos que devem rodar periodicamente.<br />
<br />
9.2.6<br />
<br />
Syslogd - A Caixa Preta do Linux Para analisar o que vem ocorrendo ou já ocorreu no sistema, o linux possui o syslogd, que funciona como uma caixa preta, guardando em arquivos, informações como: data e hora do boot, login de<br />
<br />
117<br />
<br />
TI para concursos<br />
<br />
usuário e outros dados importantes para analisar o servidor. O arquivo responsável pelas configuração do syslogd é o /etc/syslog.conf . Os registros deste arquivo são divididos em facility, priority e destino, podendo haver derivações como dois conjuntos “facility.priority” para um mesmo destino. As “facilities” podem ser: auth, auth-priv, cron, daemon, kern, lpr, mail, mark, news, security (mesmo que auth), syslog, user, uucp e local0. Já as “priorities” seguem em ordem crescente: debug, info, notice, warning, warn warning), err, error (mesmo que err), crit, alert, emerg, panic (mesmo que emerg).<br />
<br />
(memo que<br />
<br />
Um arquivo gerado na grande maioria dos sistemas *nix é o /var/log/messages, que contém informações genéricas sobre todo o sistema. Outro arquivo muito comum é o /var/log/debug que contém informações mais detalhadas.<br />
<br />
9.2.7<br />
<br />
Técnicas Básicas para Trabalhar com Redes (ifconfig, route) O Linux é um sistema operacional totalmente compatível com redes, dos tipos mais heterogêneos. Para listar as interfaces de rede usa-se o comando: ifconfig -a<br />
<br />
Para atribuir um endereço IP para uma interface usa-se: ifconfig eth0 <endereço> broadcast <broadcast> netmask <mascara><br />
<br />
Também existem as rotas para o pacote IP poder sair para fora da rede local, caso haja um roteador. Para exibir a tabela de rotas usa-se o comando: route -n ou netstat -nr<br />
<br />
Para adicionar uma rota: route add default gw <Gateway> netmask 0.0.0.0 metric 1<br />
<br />
E caso haja a necessidade de excluir uma rota usa-se: route del <destino><br />
<br />
9.2.8<br />
<br />
Gerenciando os Serviços - inetd O inetd é um daemon que pode gerenciar outros daemons, tendo uma função de supervisor. Este supervisor é executado sempre na carga do sistema, e busca a lista de serviços que devem passar pelo inetd no arquivo /etc/inetd.conf.<br />
<br />
9.2.9<br />
<br />
Utilizando Ferramentas de Busca Para deixar o sistema em dia, com pacotes sempre atualizados, sugere-se a pesquisa contínua nos vários sites que oferecem tais pacotes. Ex.: http://www.freshmeat.net<br />
<br />
9.2.10<br />
<br />
Instalando SSh / SShD O telnet antigamente era muito usado para obter acesso remoto de um servidor, mas o grande problema do telnet é que os pacotes de dados passam limpos (não criptografados) pela rede possibilitando um ataque, captura de todos os pacotes que percorrem na rede, inclusive senhas, números de cartão de crédito etc. A solução encontrada pelos profissionais de segurança e administradores foi a substituição do telnet por ssh, que criptografa os dados dos pacotes, impossibilitando a sua fácil compreensão. Para instalar o SSh deve-se baixar o pacote de algum lugar, tendo o cuidado de se baixar o produto de instituições com reconhecida credibilidade, pois do contrário, corre-se um sério risco de baixar “trojan horse”. Depois de pegar o pacote: tar xvzf ssh-1.2.27.tar.gz<br />
<br />
Depois, apenas mais três comandos dentro do diretório do ssh-1.2.27: ./configure ; make ; make install<br />
<br />
O SSh já está instalado agora para colocar seu daemon no /etc/rc.d/rc.local:<br />
<br />
118<br />
<br />
TI para concursos<br />
<br />
echo “/usr/local/sbin/sshd” >> /etc/rc.d/rc.local<br />
<br />
rc.local: Este arquivo é executado sempre na hora do boot, como o Autoexec.bat do DOS<br />
<br />
9.3<br />
<br />
Conceitos de Virtualização Virtualização é a técnica que permite particionar um único sistema computacional em vários outros denominados de máquinas virtuais. Cada máquina virtual oferece um ambiente completo muito similar a uma máquina física. Com isso, cada máquina virtual pode ter seu próprio sistema operacional, aplicativos e serviços de rede (Internet). É possível ainda interconectar (virtualmente) cada uma dessas máquinas através de interfaces de redes, switches, roteadores e firewalls virtuais, além do uso já 54 bastante difundido de VPN (Virtual Private Networks). A virtualização pode auxiliar a se trabalhar em um ambiente onde haja uma diversidade de plataformas de software (sistemas operacionais) sem ter um aumento no número de plataformas de hardware (máquinas físicas). Assim, cada aplicação pode executar em uma máquina virtual própria, possivelmente incluindo suas bibliotecas e seu sistema operacional que, por sua vez, executam em uma plataforma de hardware comum. Ao se executar múltiplas instâncias de máquinas virtuais em um mesmo hardware, também se está proporcionando um uso eficiente de seu poder de processamento. Essa situação é comumente denominada de consolidação de servidores e é especialmente interessante em data centers devido a heterogeneidade de plataformas inerente ao próprio negócio. Além disso, em data centers, a diminuição de máquinas físicas implica na redução de custos de infra-estrutura física como espaço, energia elétrica, cabeamento, refrigeração, suporte e manutenção a vários sistemas. A flexibilidade e a portabilidade das máquinas virtuais também tornam interessante o uso da virtualização em desktops. É possível imaginar, por exemplo, o desenvolvimento de produtos de software destinados a vários sistemas operacionais sem ter a necessidade de uma plataforma física para desenvolver e testar cada um deles. Assim, as máquinas virtuais em desktops podem ser usadas para se definir ambientes experimentais sem comprometer o sistema operacional original da máquina, ou ainda, para compor plataformas distribuídas como clusters e grades computacionais. As máquinas virtuais, por emularem um ambiente computacional sobre outro, impõem algumas restrições de implementação e de desempenho. É aqui que entra o desenvolvimento dos produtos de software para a virtualização. As máquinas virtuais podem ser: máquina virtual de processo – aplicação sobre um sistema operacional hypervisor ou monitor de máquina virtual – camada de software posicionada entre o hardware da máquina e o sistema operacional por duas técnicas: para-virtualização – o sistema hóspede é modificado para chamar a VMM sempre que for executada uma instrução ou ação considerada sensível. Dessa forma, o teste por instrução não é necessário. Os dispositivos de hardware são acessados por drivers da própria VMM. A substituição da chamada de uma instrução sensível pela chamada a um tratador de interrupção de software (trap) é chamado de hypercall. virtualização total – réplica do hadware subjacente de tal forma que o sistema operacional e as aplicações podem executar como se tivessem executando diretamente sobre o hardware original. A grande vantagem dessa abordagem é que o sistema operacional hóspede não precisa ser modificado para executar sobre a VMM.<br />
<br />
Sistema operacional é a camada de software inserida entre o hardware e as aplicações que executam tarefas para os usuários e cujo objetivo é tornar a utilização do computador, ao mesmo tempo, mais eficiente e conveniente. A utilização mais eficiente busca um maior retorno no investimento feito no hardware. Maior eficiência significa mais trabalho obtido pelo mesmo hardware. Isso é obtido através da distribuição de seus recursos (espaço em memória principal, processador, espaço em disco etc) entre diferentes programas. Cada programa tem a ilusão de estar executando sozinho no computador quando na realidade ele está compartilhando com os demais. Uma utilização mais conveniente do computador é obtida, escondendose do usuário detalhes de hardware, em especial, dos periféricos de entrada e saída. Tipicamente, isso é feito através da criação de recursos de mais alto nível oferecido através de interfaces gráficas. Por exemplo, os usuários usam espaço em disco através do conceito de arquivos. Arquivos não existem no hardware. Eles formam um recurso criado a partir do que o hardware oferece. Genericamente, isso é denominado de virtualização de recursos.<br />
<br />
54<br />
<br />
http://www.gta.ufrj.br/ensino/CPE758/artigos-basicos/cap4-v2.pdf<br />
<br />
119<br />
<br />
TI para concursos<br />
<br />
O elemento central de um computador é seu processador. Cada processador tem um conjunto de instruções de máquina que pode seguir um determinado padrão. Por exemplo, Intel e AMD, fabricam processadores que implementam um mesmo padrão ISA, o Intel IA-32 (x86). Os projetistas de software compilam seu programas para obter códigos binários para um determinado ISA. Portanto, o conjunto de instruções (ISA) é uma interface entre o hardware e o software. Tipicamente, um sistema de computação oferece três tipos de interfaces: instruções de máquina (privilegiadas) - interface que permite que apenas alguns programas, os com privilégios especiais, como o sistema operacional, possam executar todas as instruções, entre elas, as de manipulação de recursos de hardware, como entrada e saída e interrupções. instruções de máquina (não privilegiadas) e chamadas de sistema - interface que possibilita que um programa de usuário execute instruções não-privilegiadas diretamente no processador, mas não permite o acesso aos recursos de hardware (instruções privilegiadas). As chamadas de sistema são uma forma de permitir que os programas de usuários acessem de forma indireta, e controlada, os recursos de hardware. Através delas, os programas de usuário executam, após ter sido garantido a autenticidade e a validade da operação, operações de acesso a recursos de hardware (tipicamente E/S). interface aplicativa de programação – mais conhecida como API (Application Program Interface), são funções de biblioteca que fazem com que as chamadas de sistema sejam ocultadas.<br />
<br />
Considerando essas interfaces, a implementação de máquinas virtuais pode ser feita de três modos: programa de aplicação que forneçe um ambiente de execução para outras aplicações. Esse ambiente pode possuir um conjunto de instruções abstratas que são interpretadas para gerar as instruções de máquinas não-privilegiadas, as chamadas de sistema e de API de bibliotecas que correspondem à ação abstrata desejada. É o caso da máquina virtual java (JVM). programa de aplicação que emula chamadas de sistemas de outro sistema operacional, como ocorre quando se executa Linux em sistemas Windows com a ferramenta VMware player . Esse tipo de virtualização é o que se denomina de máquina virtual de processo. camada de software entre o hardware e o sistema operacional protegendo o acesso direto deste aos recursos físicos da máquina. Essa camada oferece como interface ao sistema operacional um conjunto de instruções de máquina que pode ser o mesmo do processador físico, ou um outro. O ponto importante é que essa interface deve estar disponível sempre que o computador estiver ligado e que ela possa ser usada simultaneamente por diferentes programas. O resultado final é que possível ter diversos sistemas operacionais (programas) executando independentemente na mesma plataforma. Genericamente, essa máquina virtual é referenciada como monitor de máquina virtual (Virtual Machine Monitor ou VMM), também conhecido como hypervisor, ou ainda, máquina virtual de sistema. O processo ou sistema que executa sobre uma máquina virtual é denominado de hóspede, enquanto o ambiente sobre o qual ele executa é chamado de hospedeiro. Os fabricantes de processadores, AMD e Intel, desenvolveram extensões para a arquitetura x86 para suportarem a virtualização: Pacífica – AMD-V (AMD-Virtualization), se aplica às arquiteturas x86 de 64 bits como o Athon, Turion, Phenom e as linhas mais recentes. A AMD implementa funções especiais no processador que são executadas por um hypervisor e que podem controlar, em seu nome, se determinados acessos de um sistema hóspede são permitidos. Vanderpool – IVT (Intel Virtualization Technology) para as arquiteturas x86 de 32 e 64 bits. A Intel introduziu mecanismos similares (virtual machines extensions) que complementam a idéia do conceito de anéis de proteção com dois novos modos: root e não-root. Esses modos são controlados pelo hypervisor (que executa em modo root) e que pode transferir a execução de um sistema operacional hóspede para o modo não-root no qual instruções do anel zero são executadas sem risco para o sistema. As soluções da AMD e da Intel foram desenvolvidas independentemente uma da outra e são incompatíveis, embora sirvam para o mesmo propósito. Existem diversas soluções comerciais, gratuitas, em software livre ou integradas a sistemas operacionais. Entre as mais conhecidas destacam-se o VMware e o Xen O VMware é uma infra-estrutura de virtualização completa com produtos abrangendo desde desktops a data centers organizados em três categorias: gestão e automatização, forma automatizada e centralizada de gerência de todos os recursos da infra-estrutura virtual permitindo a monitoração do sistema, auxiliando na conversão de sistemas físicos em virtuais, na recuperação de desastres, entre outros.<br />
<br />
120<br />
<br />
TI para concursos<br />
<br />
infra-estrutura virtual, monitoração e alocação de recursos entre as máquinas virtuais de forma a atender requisitos e regras de negócios. Soluções para alta disponibilidade, backup, migração de máquinas virtuais e atualização de versões de software. virtualização de plataformas, destinado a criar máquinas virtuais. O Xen é um monitor de máquina virtual (hypervisor ou VMM), em software livre, licenciado nos termos da GNU General Public Licence (GPL), para arquiteturas x86, que permite vários sistemas operacionais hóspedes serem executados em um mesmo sistema hospedeiro. O Xen é originário de um projeto de pesquisa da universidade de Cambridge, que resultou em um empresa, a XenSource inc, adquirida pela CitrixSystem em outubro 2007. Os dois principais conceitos do Xen são: domínios - máquinas virtuais do Xen e são de dois tipos: privilegiada (domínio 0) - máquina virtual única que executa um núcleo linux modificado e que possuí privilégios especiais para acessar os recursos físicos de entrada e saída e interagir com as demais máquinas virtuais (domínios U). Por ser um sistema operacional modificado, possui os drivers de dispositivos da máquina física e dois drivers especiais para tratar as requisições de acesso a rede e ao disco efetuados pelas máquinas virtuais dos domínios U. não-privilegiada (domínio U)<br />
<br />
hypervisor - controla os recursos de comunicação, de memória e de processamento das máquinas virtuais e não possui drivers de dispositivos. O hypervisor Xen não é capaz de suportar nenhum tipo de interação com sistemas hóspedes, é necessário que exista um sistema inicial para ser invocado pelo hypervisor. Esse sistema inicial é o domínio 0. As outras máquinas virtuais só podem ser executadas depois que ele for iniciado. As máquinas virtuais de domínio U são criadas, iniciadas e terminadas através do domínio 0. O Virtual PC 2007 é uma máquina virtual para família Windows que pode ser configurada para executar qualquer outro sistema operacional. O Virtual PC oferece mecanismos para interconectar logicamente as diferentes máquinas virtuais. Cada máquina virtual tem seu próprio endereço MAC e endereço IP. Além disso, o Virtual PC oferece um servidor de DHCP, um servidor NAT e switches virtuais. Dessa forma, é possível construir cenários de rede usando máquinas virtuais. O virtual PC 2007 é disponível para download, assim como um white paper que ensina a configurar as máquinas virtuais e um ambiente de rede. O Windows 2008 Server Hyper-V explora eficientemente as arquiteturas de 64 bits, processadores multicore e meios de armazenamento e oferece todo um ambiente integrado de gerenciamento da virtualização (monitoração, automatização de procedimentos, migração, recuperação de desastres etc). Entre as principais vantagens do Windows 2008 Server Hyper-V estão várias ferramentas para automatizar o processo de virtualização. Uma delas é o Manager Physical-to-virtual (P2V) que auxilia na conversão de servidores físicos para virtuais. Há também o Volume Shadow Copy Services que realiza automaticamente procedimentos de backup e de disponibilidade de forma que o sistema, como um todo, opere de forma homogênea independente de falhas e de “picos” de carga. Isso é feito por técnicas de migração de máquinas virtuais.<br />
<br />
9.4<br />
<br />
Active Directory Software da Microsoft utilizado em ambientes Windows, o Active Directory é uma implementação de serviço de diretório no protocolo LDAP que armazena informações sobre objetos em rede de computadores e disponibiliza essas informações a usuários e administradores desta rede.55 O "diretório ativo" permite que os administradores atribuam à empresa políticas largas, ofereçam programas a muitos computadores, e apliquem updates críticos a uma organização inteira. Uma informação ativa e ajustes das lojas do diretório que relacionam-se a uma organização em uma central, base de dados organizada, acessível. O Active Directory está relacionado à: Gerenciamento centralizado GPO – Políticas de Grupo Catálogo Global Gerenciamento de Desktop Intellimiror Distribuição de Software Automática Interface de acesso ADSI<br />
<br />
55<br />
<br />
http://pt.wikipedia.org/wiki/Active_Directory<br />
<br />
121<br />
<br />
TI para concursos<br />
<br />
Compatibilidade com sistemas operacionais MS Legados Administração Delegada Replicação Automática O Active Directory (AD) surgiu da necessidade de se ter um único diretório – um banco de dados que armazena as informações dos usuários, grupos, senhas, contas de computadores, relações de confiança, informações sobre o domínio, unidades organizacionais etc – onde os usuários poderão ter apenas uma senha para acessar todos os recursos disponíveis na rede. Disponibiliza vários serviços, como: autenticação dos usuários, replicação do seu banco de dados, pesquisa dos objetos disponíveis na rede, administração centralizada da segurança utilizando GPO, entre outros serviços. O AD é organizado de uma forma hierárquica, com o uso de domínios. Um domínio é um limite administrativo com diferentes administradores e diferentes políticas de segurança. Domínios baseados no AD pussuem os seguintes recursos: Logon único: com esse recurso, o usuário necessita fazer apenas um logon para acessar os recursos em diversos servidores da rede, inclusive email e banco de dados. Conta de usuário única: os usuários possuem apenas um nome de usuário para acessar os recursos da rede. As contas de usuários ficam armazenadas no banco de dados do AD. Gerenciamento centralizado: com os domínios baseados no AD, temos uma administração centralizada. Todas as informações sobre contas de usuários, grupos e recursos da rede, podem ser administradas a partir de um único local no domínio. Escalonabilidade: os domínios podem crescer a qualquer momento, sem limite de tamanho. A forma de administração é a mesma para uma rede pequena ou grande. Nos domínios baseados no AD, podemos ter dois tipos de servidores: Controlador de Domínio (DC – Domain Controller): é o servidor que possui o AD instalado. Em um mesmo domínio podemos ter mais de um Controlador de Domínio. As alterações efetuadas em um DC são replicadas para todos os outros DC’s. São os DC’s quem fazem a autenticação dos usuários de um domínio. Um destes DC é eleito o controlador primário do domínio (PDC). Quando ele sai da rede, um controlador secundário assume a função. Servidor Membro (Member Server) ou estação de trabalho (workstation): é um computador que não possui uma cópia do AD, porém tem acesso aos objetos do AD. Não fazem a autenticação dos usuários. O AD utiliza o DNS para a nomeação de servidores e recursos, e também para resolução de nomes. Esquema é um conjunto de regras que define as classes de objetos e atributos contidos no diretório, as restrições e os limites das ocorrências desses objetos e o formato de seus nomes, que está incluído no Active Directory. Com a utilização de domínios, a rede pode refletir a estrutura de uma empresa. Diversos domínios podem se interligar através do estabelecimento de relação de confiança, que permite aos usuários de ambos os domínios acessar seus recursos. No Windows 2000, as relações de confianças são bidirecionais e transitivas, ou seja, se o domínio X confia no domínio Y, e Y confia no domínio W, o domínio X também confia no domínio W. Algumas características próprias de cada domínio: Um domínio armazena informações somente dos objetos do próprio domínio. Um domínio possui suas próprias diretivas de segurança<br />
<br />
9.5<br />
<br />
Exercícios 174. (ICMS-SP 2009) Na arquitetura do sistema operacional Windows XP, o Executivo expõe serviços aos 174 processos usuários por meio (a) dos Drivers de dispositivo. (b) das DLL. xx (c) da API nativa. (d) do Gerenciador de objeto. (e) do Gerenciador de E/S.<br />
<br />
122<br />
<br />
TI para concursos 175<br />
<br />
175. (ICMS-SP 2009) NÃO é uma característica do Active Directory do Windows XP: (a) Um serviço de rede que permite aos usuários compartilhar informações, recursos e objetos por meio de rede. (b) Serviços de diretório para objetos compartilhados em uma rede, por exemplo: arquivos, impressoras, usuários etc. xx (c) Um serviço de acesso remoto que permite aos usuários se conectarem remotamente com uma LAN. (d) O cliente LDAP – Protocolo Leve de Acesso a Diretório, para pesquisar e modificar diretórios de Internet, pode acessar o Active Directory. (e) As localizações dos objetos são transparentes, ou seja, os usuários não sabem o endereço de um objeto. 176. (ICMS-SP 2009) Os mecanismos IPC disponíveis, tais como Sinais, Pipes, Soquetes, Mensagens, Memória 176 compartilhada e Semáforos de System V, são implementados no núcleo do Linux pelo subsistema primário (a) Sistemas de arquivos. xx (b) Sistema de comunicação interprocessos. (c) Gerenciador de processo. (d) Gerenciador de memória. (e) Gerenciador de E/S. 177. Para configurar e gerenciar o processo de inicialização (boot) de um computador com o sistema operacional 177 Linux, pode-se utilizar o LILO ou o (a) INIT (b) BOOT. (c) LINX. (d) LOAD xx (e) GRUB 178. O Windows Server 2003 fornece várias ferramentas que podem ser usadas para gerenciar arquivos e pastas. A respeito das práticas recomendadas, quando se trata de pastas compartilhadas, analise as afirmativas a seguir: I. A atribuição de permissões a grupos simplifica o gerenciamento dos recursos compartilhados, pois se pode adicionar ou remover usuários nos grupos sem precisar reatribuir as permissões. II. As permissões compartilhadas se aplicam somente aos usuários que acessam os recursos compartilhados na rede e não a usuários que fazem logon localmente. III. Na implementação das ferramentas, a descentralização das pastas de dados facilita o backup dos dados 178 e o gerenciamento do compartilhamento. Assinale: (a) se somente a afirmativa I estiver correta. xx (b) se somente as afirmativas I e II estiverem corretas. (c) se somente as afirmativas I e III estiverem corretas. (d) se somente as afirmativas II e III estiverem corretas. (e) se todas as afirmativas estiverem corretas. 179. Um conjunto de regras que define as classes de objetos e atributos contidos no diretório, as restrições e os limites das ocorrências desses objetos e o formato de seus nomes, que está incluído no Active Directory, 179 denomina-se (a) floresta. (b) domínio. (c) diretiva de grupo. xx (d) esquema. (e) catálogo global. 180<br />
<br />
180. Quando se elimina o nó raiz de uma estrutura em árvore, o que dela restar forma (a) outra árvore. xx (b) uma floresta. (c) uma árvore binária. (d) uma sub-árvore. (e) um conjunto de sub-árvores.<br />
<br />
181<br />
<br />
181. Obtidas as permissões de acesso a um arquivo GNU/Linux: rw-r-xr-x Trata-se de um arquivo do tipo (a) normal, cuja execução é permitida ao dono, aos usuários do grupo user e aos outros usuários do arquivo. xx (b) normal, cujas alteração ou "deleção" são permitidas apenas ao dono do arquivo. (c) normal, cujas alteração ou "deleção" são permitidas ao dono do arquivo ou aos usuários do grupo user do arquivo. (d) diretório, cujas leitura, gravação e execução são permitidas apenas ao dono do arquivo. (e) diretório, cujas leitura e execução são permitidas ao dono, aos usuários do grupo user e aos outros usuários do arquivo.<br />
<br />
123<br />
<br />
TI para concursos 182<br />
<br />
182. O Kernel do Linux deve ser descompactado no diretório xx (a) /usr/src, após login como root. (b) /root/src, após login como user. (c) /sys/src, após login como root. (d) /home, após login como wrapper. (e) /boot, após login como kewl.<br />
<br />
183. Para diversas partes de um programa serem executadas ao mesmo tempo, um sistema operacional utiliza 183 uma tecnologia de (a) multitarefa. (b) camadas. xx (c) threads. (d) particionamento. (e) multiprocessamento.<br />
<br />
124<br />
<br />
TI para concursos<br />
<br />
10<br />
<br />
Redes<br />
<br />
10.1<br />
<br />
Conceito de rede Rede de computadores é um conjunto de computadores interligados por qualquer meio e que se comunicam por uma codificação determinada (protocolo de rede). Existem diversos protocolos de rede, mas o mais utilizado atualmente é o protocolo TCP/IP, transfer control protocol – internet protocol. Computadores que se comunicam em um sistema fechado, estão em uma rede local (LAN). Quando duas ou mais redes se ligam em um espaço mais amplo, diz-se que estão em uma rede WAN. Existem milhões de computadores no mundo interligados em rede por um protocolo chamado TCP/IP, formando uma única rede chamada de internet. O meio de ligação entre os computadores (estações de trabalho) e a forma da disposição das conexões são camados de topologia da rede. Cabos metálicos, fibras óticas ou comunicação sem fios formam os enlaces entre computadores, ou entre computadores e outros equipamentos que fazem o papel de nós que recebem e distribuem os sinais na rede. A topologia de uma rede de comunicação refere-se à forma como os enlaces físicos e os nós estão organizados, determinando os caminhos físicos existentes e utilizáveis entre quaisquer pares de estações conectadas a essa rede. A topologia de uma rede muitas vezes caracteriza o seu tipo, eficiência e velocidade. Malha (fully) - A interconexão é total garantindo alta confiabilidade, porém a complexidade da implementação física e o custo inviabilizam seu uso comercial; Estrela (star) - A conexão é feita através de um nó central que exerce controle sobre a comunicação. Sua confiabilidade é limitada à confiabilidade do nó central, cujo mau funcionamento prejudica toda a rede; Barramento (bus) - As estações são conectadas através de um cabo com difusão da informação para todos os nós. é necessária a adoção de um método de acesso para as estações em rede compartilharem o meio de comunicação, evitando colisões. é de fácil expansão, mas de baixa confiabilidade, pois qualquer problema no barramento impossibilita a comunicação em toda a rede; Anel (ring) - O barramento toma a forma de um anel, com ligações unidirecionais ponto a ponto. A mensagem é repetida de estação para estação até retornar à estação de origem, sendo então retirada do anel. Como o sinal é recebido por um circuito e reproduzido por outro há a regeneração do sinal no meio de comunicação; entretanto há também a inserção de um atraso a cada estação. O tráfego passa por todas as estações do anel, sendo que somente a estação destino interpreta a mensagem; Árvore (tree) - é a expansão da topologia em barra herdando suas capacidades e limitações. O barramento ganha ramificações que mantêm as características de difusão das mensagens e compartilhamento de meio entre as estações; Mistas (mesh) - Combinam duas ou mais topologias simples. Alguns exemplos são o de estrelas conectadas em anel e as árvores conectadas em barramento. Procuram explorar as melhores características das topologias envolvidas, realizar a conexão em um barramento único de módulos concentradores aos quais são ligadas as estações em configurações mais complexas e mais confiáveis.<br />
<br />
10.1.1<br />
<br />
Configuração de redes TCP-IP Em uma rede de computadores que utiliza o protocolo TCP-IP, existem determinadas práticas de configuração que permitem que se usufrua da internet sem perder a rede local suas características e segurança.<br />
<br />
125<br />
<br />
TI para concursos<br />
<br />
A cada equipamento conectado fisicamente na rede atribui-se um número chamado de endereço IP. Este número é formado por quatro números de 0 a 255 separados por pontos. Por exemplo, 192.168.1.23 ou 10.10.0.128 são endereços IP válidos e 175.268.1.0 não é válido, pois contém um número maior do que 255. Estes números são, na verdade, uma representação decimal, pois a rede enxerga estes endereços como quatro grupos de oito números binários (0 ou 1) ou octetos. Para transformar um número decimal em binário, faz-se a divisão inteira daquele por sete vezes, então toma-se os restos das divisões em ordem contrária: Por exemplo, dividindo-se 244 por dois e guardando o resto da divisão: div 2 sobra 244 0 122 0 61 1 30 0 15 1 7 1 3 1 1 1 temos que o número 244 do sistema decimal é representado por 11110100 no sistema binário.<br />
<br />
Em uma rede local, sem conexão com outras redes que utilizam o protocolo TCP-IP, qualquer endereço válido pode ser atribuída a qualquer computador. Porém, isto pode dificultar a sua manutenção e prejudicar seu desempenho quando o número de computadores na rede aumentar. O IP, elemento comum encontrado na internet pública, é descrito no documento RFC 791 (Request for Comments) da IETF (Internet Engineering Task Force), que foi pela primeira vez publicado em Setembro de 1981. Esta versão do protocolo é designada de versão 4, ou IPv4. O IPv6 tem endereçamento de origem e destino de 128 bits, oferecendo mais endereçamentos que os 32 bits do IPv4, com previsão de ser padrão na internet a partir de 2011. Originalmente, o espaço do endereço IP foi dividido em poucas estruturas de tamanho fixo chamados de "classes de endereço". As três principais são a classe A, classe B e classe C. Examinando os primeiros bits de um endereço, o software do IP consegue determinar rapidamente qual a classe, e logo, a estrutura do endereço. Classe A: Primeiro bit é 0 (zero) 00000000.00000000.00000000.00000000 até 01111111.11111111.11111111.11111111 ou 0.0.0.0<br />
<br />
até 127.255.255.255<br />
<br />
Classe B: Primeiros dois bits são 10 (um, zero) 10000000.00000000.00000000.00000000 até 10111111.11111111.11111111.11111111 ou 128.0.0.0 até 191.255.255.255<br />
<br />
Classe C: Primeiros três bits são 110 (um, um, zero) 11000000.00000000.00000000.00000000 até 11011111.11111111.11111111.11111111 ou 192.0.0.0 até 223.255.255.255<br />
<br />
Classe D: (endereço multicast): Primeiros quatro bits são: 1110 (um, um, um, zero) 11000000.00000000.00000000.00000000 até 11011111.11111111.11111111.11111111 ou 224.0.0.0 até 239.255.255.255<br />
<br />
Classe E: (endereço especial reservado): Primeiros cinco bits são 11110 (um, um, um, um, zero) 11000000.00000000.00000000.00000000 até 11011111.11111111.11111111.11111111 ou 240.0.0.0 até 247.255.255.255<br />
<br />
Existem classes especiais na Internet que não são consideradas públicas, não são consideradas como endereçáveis. São reservados para a comunicação em uma rede privada os endereços que começam com 10.0.0.0, e 192.168.0.0 e os endereços na faixa 172.16.0.0 até 172.31.255.254. É reservado para representar o computador local ("localhost") a faixa de endereços 127.0.0.0 a 127.255.255.255. Um computador usa qualquer destes endereços para designar a ele mesmo, como o pronome pessoal “eu”. É reservado para representar rede corrente o endereço 0.0.0.0. Um computador usa este endereço para designar a própria rede.<br />
<br />
A utilização destes endereços torna o computador inacessível por outros computadores na internet, o que representa uma segurança. Por outro lado, para acessar a internet, a rede local precisa de pelo menos um equipamento com um endereço público não reservado. Este equipamento pode fazer a ligação entre a rede e a internet, ou roteamento. Pode ser um roteador ou um computador. O endereço IP tem a função de identificar o computador, que chamamos de host, e também a rede em que está conectado. O roteamento dos pacotes enviados na rede TCP/IP é feito procurando a rede e depois o host (equipamento). Os bits à esquerda são utilizados para a rede. A quantidade de bits utilizada é definida pelo administrador da rede por um número chamado de máscara de rede ou netmask. O netmask é um conjunto de quatro octetos, como um endereço IP, iniciado por um grupo de uns à esquerda e outro grupo com zeros à direita. 126<br />
<br />
TI para concursos<br />
<br />
Uma rede com endereços que comece com 192.168 e netmask 255.255.0.0, por exemplo, pode ter até 255x255=65536 endereços. O primeiro (192.168.0.0) é reservado para identificar a própria rede e o último (192.168.255.255) é usado para distribuir dados para toda a rede (broadcast), os demais 65534 endereços são para os hosts. Todas as informações de todos os computadores nesta rede vai ser inviada para todos os computadores, gerando colisões que podem tornar a rede muito lenta. Para minimizar este problema, uma rede pode ser dividida em várias subredes alterando-se o natmask. Um netmask 255.255.255.0 vai reduzir o número de endereços em cada rede para apenas 256 (254 para hosts) e aumentar o número de redes em 256 vezes. Cada subrede recebe um endereço para ser identificada e outro para o broadcast a partir de operações lógicas entre a máscara de rede (netmask) e cada endereço de cada equipamento. Por exemplo, uma net mask pode ser 11111111. 11111111. 11111111.00000000, representada por 255.255.255.0.<br />
<br />
A identificação de rede de um endereço IP é dada pela operação lógica ^ (e/and) entre a máscara e o endereço. Nesta operação, comparam-se os octetos posição a posição, sendo atribuido o valor zero se um dos dígitos for zero, ou valor um em caso contrário. Um endereço 192.168.1.101 E uma máscara 255.255.255.0 produz o endereço 192.168.1.0, que identifica a rede.<br />
<br />
A identificação de rede do broadcast é obtido pelo operação lógica v (ou/or) entre a negação da máscara e o endereço. Um endereço 192.168.1.101 OU uma máscara 255.255.255.0 produz o endereço 192.168.1.255, que identifica o broadcast.<br />
<br />
O netmask não precisa usar somente grupos completos de oito bits. Desde que não haja “buracos”, pode-se tomar mais algums bits. Uma net mask pode ser 11111111. 11111111. 11111111.10000000, representada por 255.255.255.128, e um endereço, por exemplo, 192.168.1.132/25, dentro desta subrede será representada com o número de bits da máscara à sua direita, neste caso 25 (8+8+8+1). Neste exemplo, o número de endereços se reduziu para 128 (126 para hosts) e o número de redes aumentou em 128 vezes.<br />
<br />
Assim, podem ser criadas subredes com 128 endereços (126 hosts), 64, 32, 16, 8, 4 ou 2 endereços (que não seve para nada). A conta de quantos hosts podem haver em uma subnet é dois elevado ao número de zeros na netmask menos dois: hosts=2n-2. O número de subredes é dois elevado ao número de uns do octeto incompleto: redes=2n. Na nossa net mask 11111111. 11111111. 11111111.10000000, com sete zeros, teremos 27-2=126 endereços para hosts e 21=2 para subredes. Em uma net mask 11111111. 11111111. 11111111.11100000, com cinco zeros, teremos 25-2=30 endereços para hosts e 23=8 subredes.<br />
<br />
Com isto tudo, o acesso de um equipamento a outro na mesma subrede é direta e rápida, enquanto que computadores em redes distintas só conseguem se comunicar de forma remota.<br />
<br />
10.2<br />
<br />
Arquitetura de Rede Arquitetura de rede é como se designa um conjunto de camadas e protocolos de rede. A especificação de uma arquitetura deve conter informações suficientes para permitir que um implementador desenvolva programas ou construa o hardware de cada camada, de forma que ela obedeça 56 corretamente ao protocolo adequado. ISO foi uma das primeiras organizações a definir formalmente uma forma comum de conectar computadores. Sua arquitetura é chamada OSI (Open Systems Interconnection), Camadas OSI ou 57 Interconexão de Sistemas Abertos. Esta arquitetura é um modelo que divide as redes de computadores em sete camadas, de forma a se obter camadas de abstração. Cada protocolo implementa uma funcionalidade assinalada a uma determinada camada. 1 Camada física Subcamada MAC Subcamada LLC<br />
<br />
<br />
<br />
2 Camada de enlace 3 Camada de rede 4 Camada de transporte 5 Camada de sessão 6 Camada de apresentação<br />
<br />
56<br />
<br />
http://pt.wikipedia.org/wiki/Arquitetura_de_rede<br />
<br />
57<br />
<br />
http://pt.wikipedia.org/wiki/Modelo_OSI<br />
<br />
127<br />
<br />
TI para concursos<br />
<br />
7 Camada de aplicação<br />
<br />
10.2.1<br />
<br />
Camada Física A camada física define as características técnicas dos dispositivos elétricos (físicos) do sistema. Ela contém os equipamentos de cabeamento ou outros canais de comunicação que se comunicam diretamente com o controlador da interface de rede. Preocupa-se, portanto, em permitir uma comunicação bastante simples e confiável, na maioria dos casos com controle de erros básico: Move bits (ou bytes, conforme a unidade de transmissão) através de um meio de transmissão. Define as características elétricas e mecânicas do meio, taxa de transferência dos bits, tensões etc. Controle de acesso ao meio. Controle da quantidade e velocidade de transmissão de informações na rede. Os principais equipamentos relacionados à camada física são: Repeater ou repetidor - utilizado para interligação de redes idênticas, amplificam e regeneram eletricamente os sinais transmitidos no meio físico. Recebe todos os pacotes de cada uma das redes que ele interliga e os repete nas demais redes sem realizar qualquer tipo de tratamento sobre os mesmos. HUB ou concentrador - concentra a ligação entre diversos computadores que estão em uma rede local. Trabalha por broadcast, que envia a mesma informação dentro de uma rede para todas as máquinas interligadas. Possui diversas portas que partilham o mesmo domínio de colisão.<br />
<br />
10.2.2<br />
<br />
Camada de Enlace ou Ligação de Dados Detecta e, opcionalmente, corrige erros que possam acontecer no nível físico. É responsável pela transmissão e recepção (delimitação) de quadros e pelo controle de fluxo. Estabelece um protocolo de comunicação entre sistemas diretamente conectados, como PPP ou NetBios. Esta camada é dividida em outras duas camadas: Controle de ligação lógica (LLC), que fornece uma interface para camada superior (rede). Controle de acesso ao meio físico (MAC), que acessa diretamente o meio físico e controla a transmissão de dados. Os principais equipamentos relacionados à camada de enlace são: Bridge ou ponte - dispositivo que liga redes com quaisquer protocolos ou dois segmentos da mesma rede que usam o mesmo protocolo. Uma bridge ignora os protocolos utilizados nos dois segmentos que liga, somente envia dados de acordo com o endereço do pacote. Este endereço não é o endereço IP (internet protocol), mas o MAC (media access control) que é único para cada placa de rede. Os únicos dados que são permitidos atravessar uma bridge são dados destinados a endereços válidos no outro lado da ponte. Desta forma é possível utilizar uma bridge para manter um segmento da rede livre dos dados que pertencem a outro segmento. Switch ou comutador – dispositivo que reencaminha frames entre os diversos nós e segmenta a rede internamente. Possui diversas portas, cada uma corresponde um dominio de colisão diferente, não havendo colisões entre pacotes de segmentos diferentes. Com um Switch gerenciável, podemos criar VLANS, deste modo a rede gerenciada será divida em menores segmentos. Protocolos: Ethernet e PPP.<br />
<br />
10.2.3<br />
<br />
Camada de Rede A camada de Rede é responsável pelo endereçamento dos pacotes, convertendo endereços lógicos (ou IP) em endereços físicos, de forma que os pacotes consigam chegar corretamente ao destino. Essa camada também determina a rota que os pacotes irão seguir para atingir o destino, baseada em fatores como condições de tráfego da rede e prioridades. Essa camada é usada quando a rede possui mais de um segmento e, com isso, há mais de um caminho para um pacote de dados percorrer da origem ao destino. As funções da camada de rede são encaminhamento, endereçamento, interconexão de redes, tratamento de erros, fragmentação de pacotes, controle de congestionamento e sequenciamento de pacotes. Movimenta pacotes a partir de sua fonte original até seu destino através de um ou mais enlaces. Define como dispositivos de rede descobrem uns aos outros e como os pacotes são roteados até seu destino final. Dispositivo: Swith L3<br />
<br />
128<br />
<br />
TI para concursos<br />
<br />
Protocolo: IP.<br />
<br />
10.2.4<br />
<br />
Camada de Transporte A camada de transporte é responsável por usar os dados enviados pela camada de Sessão e dividi-los em pacotes que serão transmitidos para a camada de Rede. No receptor, a camada de Transporte é responsável por pegar os pacotes recebidos da camada de Rede, remontar o dado original e assim enviá-lo à camada de Sessão. Isso inclui controle de fluxo, ordenação dos pacotes e a correção de erros, tipicamente enviando para o transmissor uma informação de recebimento, informando que o pacote foi recebido com sucesso. A camada de Transporte separa as camadas de nível de aplicação (camadas 5 a 7) das camadas de nível físico (camadas de 1 a 3). A camada 4, Transporte, faz a ligação entre esses dois grupos e determina a classe de serviço necessária como orientada a conexão e com controle de erro e serviço de confirmação, sem conexões e nem confiabilidade. O objetivo final da camada de transporte é proporcionar serviço eficiente, confiável e de baixo custo. O hardware e/ou software dentro da camada de transporte e que faz o serviço é denominado entidade de transporte. A ISO define o protocolo de transporte para operar em dois modos: Orientado a conexão – usando o protocolo TCP, mais confiável. Não-Orientado a conexão – através do protocolo UDP, mais rápido. Dispositivos: Swith L4.<br />
<br />
10.2.5<br />
<br />
Camada de Sessão A camada de Sessão permite que duas aplicações em computadores diferentes estabeleçam uma sessão de comunicação. Nesta sessão, essas aplicações definem como será feita a transmissão de dados e coloca marcações nos dados que estão sendo transmitidos. Se porventura a rede falhar, os computadores reiniciam a transmissão dos dados a partir da última marcação recebida pelo computador receptor. Disponibiliza serviços como pontos de controle periódicos a partir dos quais a comunicação pode ser restabelecida em caso de pane na rede. Abre portas (sockets) para que várias aplicações possam escalonar o uso da rede e aproveitar melhor o tempo de uso. Por exemplo, um browser quando for fazer o download de várias imagens pode requisitá-las juntas para que a conexão não fique ociosa em uma só imagem. Protocolos: NetBIOS, IPX, Appletalk.<br />
<br />
10.2.6<br />
<br />
Camada de Apresentação A camada de Apresentação, também chamada camada de tradução, converte o formato do dado recebido pela camada de Aplicação em um formato comum a ser usado na transmissão desse dado, ou seja, um formato entendido pelo protocolo usado. Um exemplo comum é a conversão do padrão de caracteres (código de página) quando o dispositivo transmissor usa um padrão diferente do ASCII. Pode ter outros usos, como compressão de dados e criptografia. A compressão de dados pega os dados recebidos da camada sete e os comprime, e a camada 6 do dispositivo receptor fica responsável por descompactar esses dados. A transmissão dos dados torna-se mais rápida, já que haverá menos dados a serem transmitidos: os dados recebidos da camada 7 foram "encolhidos" e enviados à camada 5. Para aumentar a segurança, pode-se usar algum esquema de criptografia neste nível, sendo que os dados só serão decodificados na camada 6 do dispositivo receptor. Ela trabalha transformando os dados em um formato no qual a camada de aplicação possa aceitar.<br />
<br />
10.2.7<br />
<br />
Camada de Aplicação A camada de aplicação faz a interface entre o protocolo de comunicação e o aplicativo que pediu ou receberá a informação através da rede. Por exemplo, ao solicitar a recepção de e-mails através do aplicativo de e-mail, este entrará em contato com a camada de Aplicação do protocolo de rede efetuando tal solicitação. Tudo nesta camada é direcionado aos aplicativos. Telnet e FTP são exemplos de aplicativos de rede que existem inteiramente na camada de aplicação. Protocolos: SMTP, FTP, Telnet, SSH, IRC, http, POP3, VFRAD<br />
<br />
129<br />
<br />
TI para concursos<br />
<br />
10.3<br />
<br />
Noções de administração de redes O Administrador de Rede tem como atribuição principal o gerenciamento da rede local, bem como dos 58 recursos computacionais relacionados direta ou indiretamente. Suas atribuições são: Instalação e ampliação da rede local; Acompanhar o processo de compra do material necessário para manutenção da rede local junto com o SAT (Setor de Assistência Técnica), orientando o processo de compra e mantendo contato com os fornecedores de equipamentos e materiais de informática; Instalar e configurar a máquina gateway da rede local seguindo as orientações "Normas de Utilização do DIN"; Orientar e/ou auxiliar os administradores das sub-redes na instalação/ampliação da sub-rede; manter em funcionamento a rede local do DIN, disponibilizando e otimizando os recursos computacionais disponíveis; Executar serviços nas máquinas principais da rede local, tais como: gerenciamento de discos, fitas e backup's, parametrização dos sistemas, atualização de versões dos sistemas operacionais e aplicativos, aplicação de correções e patches; Realizar abertura, controle e fechamento de contas nas máquinas principais do domínio local, conforme normas estabelecidas pelo DIN; Controlar e acompanhar a performance da rede local e sub-redes bem como dos equipamentos e sistemas operacionais instalados; Propor a atualização dos recursos de software e hardware aos seus superiores; Manter atualizado os dados relativos ao DNS das máquinas da rede local; Divulgar informações de forma simples e clara sobre assuntos que afetem os usuários locais, tais como mudança de serviços da rede, novas versões de software, etc.; Manter-se atualizado tecnicamente através de estudos, participação em cursos e treinamentos, listas de discussão, etc.; Garantir a integridade e confidenciabilidade das informações sob seu gerenciamento e verificar ocorrências de infrações e/ou segurança; Comunicar ao DIN qualquer ocorrência de segurança na rede local que possa afetar a rede local e/ou Internet; Promover a utilização de conexão segura entre os usuários do seu domínio. Tendo como foco principal os serviços de Rede e equipamentos a qual a ele compete. Colocar em pratica a política de segurança de redes, além de desenvolvê-la.<br />
<br />
10.4<br />
<br />
Acesso Remoto Acesso remoto é utilização de um computador através de outro por algum meio de comunicação. Usualmente, o acesso remoto funciona como se o teclado e o mouse de um computador estivesse ligado ao computador controlado e o monitor deste estivesse ligado no primeiro. Existem diversos aplicativos que fazem este serviço, como o VNC, PCAnyWhere, Dameware, Conexão de área de trabalho remota do Windows entre outros. Muito utilizado em data centers para administrar diversos servidores com um só vídeo, teclado e mouse.<br />
<br />
10.5<br />
<br />
Rede Wireless Wi-Fi foi uma marca licenciada originalmente pela Wi-Fi Alliance para descrever a tecnologia de redes sem fios embarcadas (WLAN) baseadas no padrão IEEE 802.11. O termo Wi-Fi é entendido como uma tecnologia de interconexão entre dispositivos sem fios, usando o protocolo IEEE 802.11.59 O padrão Wi-Fi opera em faixas de freqüências que não necessitam de licença para instalação e/ou operação. Este fato as tornam atrativas. No entanto, para uso comercial no Brasil é necessária licença da Agência Nacional de Telecomunicações (Anatel). Para se ter acesso à internet através de rede Wi-Fi deve-se estar no raio de ação ou área de abrangência de um ponto de acesso (normalmente conhecido por hotspot) ou local público onde opere rede sem fios e usar dispositivo móvel, como computador portátil, Tablet PC ou Assistente Pessoal Digital com capacidade de comunicação sem fio.<br />
<br />
58<br />
<br />
http://pt.wikipedia.org/wiki/Administrador_de_rede<br />
<br />
59<br />
<br />
http://pt.wikipedia.org/wiki/Wi-Fi<br />
<br />
130<br />
<br />
TI para concursos<br />
<br />
Hotspot Wi-Fi existe para estabelecer ponto de acesso para conexão à internet. O ponto de acesso transmite o sinal sem fios numa pequena distância – cerca de 100 metros. Quando um periférico que permite "Wi-Fi", como um Pocket PC, encontra um hotspot, o periférico pode na mesma hora conectarse à rede sem fio. Muitos hotspots estão localizados em lugares que são acessíveis ao público, como aeroportos, cafés, hotéis e livrarias. Muitas casas e escritórios também têm redes "Wi-Fi". Enquanto alguns hotspots são gratuitos, a maioria das redes públicas é suportada por Provedores de Serviços de Internet (Internet Service Provider - ISPs) que cobram uma taxa dos usuários para se conectarem. Atualmente praticamente todos os computadores portáteis vêm de fábrica com dispositivos para rede sem fio no padrão Wi-Fi (802.11 a, b, g ou n). O que antes era acessório está se tornando item obrigatório, principalmente devido ao fato da redução do custo de fabricação.<br />
<br />
10.6<br />
<br />
Exercícios 184. (ICMS-SP 2009) As redes wireless utilizam os padrões IEEE 802.11 de conectividade sem fio para redes locais, que determinam a velocidade, ou taxa de transmissão em Mbps, e a frequência, ou faixa de operação 184 em GHz. O padrão que tem as características de velocidade e frequência corretas corresponde a: xx (a) IEEE 802.11n 128 Mbps 5 GHz (b) IEEE 802.11g 54 Mbps 5 GHz (c) IEEE 802.11b 54 Mbps 5 GHz (d) IEEE 802.11a 11 Mbps 2,4 GHz (e) IEEE 802.11 11 Mbps 2,4 GHz. 185. (ICMS-SP 2009) A arquitetura OSI de 7 camadas (1. Física, 2. Enlace, 3. Rede, 4. Transporte, 5. Sessão, 6. Apresentação e 7. Aplicação) pode funcionalmente representar um sistema de comunicação dividido em três partes: redes (conectividade), transporte (ligação entre redes e aplicação) e aplicação (programas que 185 utilizam a rede). As camadas que representam as três partes são: (a) Redes (camadas 1 e 2), Transporte (camadas 3 e 4) e Aplicação (camadas 5, 6 e 7). xx (b) Redes (camadas 1, 2 e 3), Transporte (camada 4) e Aplicação (camadas 5, 6 e 7). (c) Redes (camadas 1 e 2), Transporte (camadas 3, 4 e 5) e Aplicação (camadas 6 e 7). (d) Redes (camadas 1, 2 e 3), Transporte (camadas 4, 5 e 6) e Aplicação (camada 7). (e) Redes (camada 1), Transporte (camadas 2, 3, 4 e 5) e Aplicação (camadas 6 e 7). 186. (ICMS-SP 2009) Em um modelo simplificado de gerenciamento de redes SNMP Internet, o programa 186 executado nas entidades a serem gerenciadas (hosts, hubs, roteadores etc.) é denominado (a) MIB. (b) SMI. (c) SNMP. xx (d) Agente SNMP. (e) Gerenciador SNMP. 187<br />
<br />
187. Switches, Repetidores e Roteadores atuam respectivamente nas camadas xx (a) de enlace, física e de rede. (b) de rede, de enlace e de transporte. (c) física, de enlace e de rede. (d) de enlace, de transporte e física. (e) física, de rede e de enlace.<br />
<br />
188. Entre os dispositivos utilizados para implementar fisicamente uma rede de computadores, pode-se citar o __________ e o __________ , que operam, respectivamente, nas camadas 2 e 3 do modelo OSI. Assinale a 188 alternativa que completa, correta e respectivamente, as lacunas do texto. (a) HUB ... Switch (b) Roteador ... HUB (c) Roteador ... Switch (d) Switch ... HUB xx (e) Switch ... Roteador 189. No modelo de referência OSI, os pacotes e os quadros são unidades intercambiadas, respectivamente, pelas 189 camadas de (a) enlace e de transporte. (b) enlace e de rede. (c) rede e física. xx (d) rede e de enlace. (e) transporte e de enlace. 190. No modelo de referência TCP/IP, os protocolos IP, TCP e também aquele cujo objetivo é organizar máquinas em domínios e mapear nomes de hosts em ambientes IP, são, respecivamente, partes integrantes das 190 camadas (a) Inter-Redes, de Aplicação e de Transporte. (b) Host/Rede, Inter-Redes e de Transporte. (c) Inter-Redes, Host/Rede e de Aplicação. xx (d) Inter-Redes, de Transporte e de Aplicação. (e) Host/Rede, de Transporte e de Aplicação. 131<br />
<br />
TI para concursos<br />
<br />
191. Para testar o funcionamento de uma placa controladora de rede Ethernet, instalada em um computador pessoal com sistema operacional Windows XP, pode-se, a partir desse computador, aplicar o comando ping 191 para o endereço IP (a) 0.0.0.0 (b) 1.1.1.1 xx (c) 127.0.0.1 (d) 255.0.0.0 (e) 255.255.255.0 192. A Internet utiliza a pilha de protocolos TCP/IP para prover todos os serviços. Nesse contexto, o TCP é encarregado de possibilitar o __________ e o IP é encarregado do __________ . Assinale a alternativa que 192 completa, correta e respectivamente, as lacunas do texto. (a) roteamento ... endereçamento (b) roteamento ... transporte (c) transporte ... empacotamento xx (d) transporte ... endereçamento (e) transporte ... sequenciamento 193. O processo de navegação na Internet é facilitado pelo uso de endereços de domínio no lugar dos endereços IPs (mais difíceis de memorizar e relacionar com os sites endereçados). O serviço que faz o relacionamento 193 entre o domínio e o IP é denominado (a) DHCP. xx (b) DNS. (c) IMAP. (d) PPP. (e) TCP/IP. 194. O equipamento de rede de computador utilizado para armazenar cópias (cache) de páginas mais visitadas e, 194 além disso, verificar o conteúdo dessas páginas, é denominado xx (a) Proxy. (b) Bridge. (c) Spyware. (d) Firewall. (e) Gateway. 195. TCP/IP (transmission control protocol/Internetprotocol) são os dois protocolos mais importantes de um conjunto de protocolos que deram seus nomes à arquitetura. Deles, surge a Internet, uma rede pública de comunicação de dados que, com controle descentralizado, utiliza esse conjunto de protocolos como base para sua estrutura de comunicação e seus serviços de rede. A arquitetura TCP/IP não só fornece os protocolos que habilitam a comunicação de dados entre redes, mas também define uma série de aplicações que contribuem para a eficiência e sucesso da arquitetura. Tendo como referência inicial as informações 195 acima, assinale a opção correta a respeito de Internet, intranet e padrões de tecnologia Web. (a) Uma intranet é a aplicação da tecnologia criada na Internet e do conjunto de protocolos de transporte e de rede TCP/IP em uma rede semiprivada, interna a uma empresa. Nela, grande quantidade de informações e aplicações é disponibilizada por meio dos sistemas Web (protocolo HTTP) e correioeletrônico, sendo, comumente, verificadas funcionalidades como informações dos empregados e dos clientes que a acessam em busca de informações sobre andamento de pedidos. (b) O protocolo OSPF (open shortest path first), que é embasado no paradigma de chaveamento de pacotes (packetswitching), especifica o formato dos pacotes que são enviados e recebidos entre roteadores e sistemas finais. (c) Os protocolos UDP e SMTP podem ser utilizados na transferência de arquivos para um computador remoto que também os execute e em qualquer estrutura de rede, seja ela simples, como uma ligação ponto-a-ponto, seja ela uma rede de pacotes complexa. (d) O DNS (domain name system) é um sistema de banco de dados distribuído implementado em uma hierarquia de servidores de nome (servidores DNS) e em um protocolo de camada de aplicação que xx permite a hospedeiros consultarem o banco de dados distribuído. (e) O ICMP (Internet control message protocol), que é um protocolo de roteamento exterior auxiliar ao IP e cuja finalidade é conectar dois ou mais sistemas autônomos, pode operar em conjunto com os protocolos EGP (exterior gateway protocol) e BGP (border gateway protocol), o que permite maior confiabilidade à ligação entre dois sistemas autônomos. 196. Para acesso aos recursos da Internet, os browsers possibilitam o uso de endereços de sites na forma de mnemônicos, como, por exemplo, no portal do Governo do Estado do Rio de Janeiro – http://www.governo.rj.gov.br/, deixando para o sistema automatizado a tarefa de realizar as necessárias 196 conversões para os correspondentes endereços IP´s. Esse recurso é conhecido pela sigla: (a) ARP. xx (b) DNS. (c) ISP. (d) NAT. (e) NFS.<br />
<br />
132<br />
<br />
TI para concursos<br />
<br />
197. Dentre os recursos atualmente disponíveis no âmbito da tecnologia da informação, a Extranet constitui um termo associado às facilidades de comunicação na busca do aumento da produtividade. Nesse sentido, a 197 Extranet é definida como: (a) uma parte da Intranet que fica disponível à troca de informações com os funcionários de uma organização, mas inibe todo tipo de acesso ao ambiente externo por meio do firewall. (b) uma sub-rede sob sistema operacional Windows XP ou Linux que implementa recursos de VPN na sua segurança, mas libera acesso por meio do firewall. (c) uma parte da Intranet que fica disponível na Internet para interação com clientes e fornecedores de uma xx organização, mas com acesso autorizado, controlado e restrito. (d) uma sub-rede que disponibiliza uma maior quantidade de microcomputadores com acesso à Internet por meio da utilização do mecanismo NAT, mas restringe a intercomunicação com usuários indesejados à organização. (e) uma parte da Intranet que disponibiliza a comunicação com fornecedores e determinados clientes de uma organização, mas inibe todo tipo de acesso ao ambiente interno por meio do firewall. 198. A Internet constitui o melhor exemplo de uma WAN operando por meio de uma infraestrutura baseada no emprego de endereços IP´s para o roteamento dos pacotes de informações. Por definição na RFC 1918, alguns endereços IP são reservados e não-roteáveis externamente, sendo somente usados para redes internas, significando que nenhum computador conectado em rede local e usando qualquer uma das classes desses endereços reservados conseguirá acessar a internet. A exceção ocorre se os microcomputadores estiverem em rede e usando NAT (RFC 1631 – Network Address Translation). Para Intranets privadas, o Internet Assigned Numbers Authority (IANA) reservou a faixa de endereços de 10.0.0.0 a 10.255.255.255 para a classe A e a de 172.16.0.0 a 172.16.255.255 para a classe B. Assinale a alternativa que apresente a 198 faixa de endereços reservada para a classe C. (a) de 128.192.0.0 a 128.192.255.255 (b) de 128.146.0.0 a 128.146.255.255 (c) de 184.191.0.0 a 184.191.255.255 xx (d) de 192.168.0.0 a 192.168.255.255 (e) de 198.162.0.0 a 198.162.255.255 199. Dada uma faixa de endereços que utilize a máscara de sub-rede 255.255.255.240, será possível atribuir 199 endereços IP para (a) 2 redes e 62 estações em cada rede. (b) 6 redes e 30 estações em cada rede. xx (c) 14 redes e 14 estações em cada rede. (d) 30 redes e 6 estações em cada rede. (e) 62 redes e 2 estações em cada rede. 200. Conecta segmentos de LAN que utilizam o mesmo protocolo de enlace de dados e de rede. Normalmente, fornece portas para 4, 8, 16 ou 32 segmentos de LAN separados, permite que todas as portas estejam simultaneamente em uso e pode conectar os mesmos ou diferentes tipos de cabo. Estas são características 200 de um (a) concentrador. (b) multiplexador. xx (c) comutador. (d) modulador de amplitude. (e) repetidor. 201. Padrão de protocolo da camada de transporte, sem conexão, não confiável, destinado a aplicações que não querem controle de fluxo e nem manutenção da seqüência das mensagens enviadas, usado pelo TCP para 201 enviar mensagens curtas. Trata-se de xx (a) UDP. (b) IP. (c) SMTP. (d) POP. (e) Telnet. 202<br />
<br />
202. As mensagens de correio eletrônico, a partir de um microcomputador pessoal, serão enviadas (a) pelo protocolo SMTP, conectado pela porta 25, e serão recebidas pelos protocolos POP3 ou IMAP, xx conectado respectivamente pelas portas 110 ou 220. (b) pelo protocolo SMTP, conectado pela porta 110, e serão recebidas pelos protocolos POP3 ou IMAP, conectado respectivamente pelas portas 25 ou 220. (c) pelos protocolos SMTP ou IMAP, conectado respectivamente pelas portas 25 ou 220, e serão recebidas pelo protocolo POP3, conectado pela porta 110. (d) pelos protocolos SMTP ou IMAP, conectado respectivamente pelas portas 110 ou 220, e serão recebidas pelo protocolo POP3, conectado pela porta 25. (e) pelo protocolo SMTP, conectado pela porta 110, serão recebidas pelo protocolo POP3, conectado pela porta 25, e serão enviadas ou recebidas pelo protocolo IMAP, conectado pela porta 220.<br />
<br />
133<br />
<br />
TI para concursos 203<br />
<br />
203. O daemon de correio eletrônico que se comunica com o SMTP permanece em escuta na porta (a) 21 xx (b) 15 (c) 69 (d) 80 (e) 110<br />
<br />
204. Controlar o acesso ao canal compartilhado é uma questão que as redes de difusão têm a resolver na camada 204 de enlace de dados. Para cuidar desse problema existe (a) o roteador. (b) a VPN. xx (c) a subcamada MAC. (d) o protocolo IP. (e) o protocolo HTTP. 205. Serviço que permite ao usuário entrar em outro computador ligado à internet, transformando sua máquina 205 local em um terminal do computador remoto é o xx (a) Telnet. (b) FTP. (c) Usenet. (d) Intranet. (e) IRC. 206<br />
<br />
206. As camadas LLC e MAC da arquitetura de rede IEEE 802 correspondem no modelo OSI à camada de (a) Rede. (b) Sessão. xx (c) Enlace. (d) Transporte. (e) Aplicação.<br />
<br />
134<br />
<br />
TI para concursos<br />
<br />
11<br />
<br />
Referências<br />
<br />
Além das referências anotradas nos rodapés das páginas: OBJECT Management Group, Inc. (OMG), Business Process Model and Notation (BPMN). Version 2.0 de 03/01/2011. Disponível em http://www.omg.org/spec/BPMN/2.0. Acesso em 15/09/2012. MAZZOLA, Vitório Bruno. “Engenharia de Software”. Disponível em http://seriesloads.wordpress.com/2010/11/04/engenharia-de-software-vitorio-bruno-mazzola/ . Acesso em 15/09/2012 PMI, Project Management Institute, Inc. “Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK®)”. Terceira edição. ©2004.<br />
<br />
135<br />
<br />
TI para concursos<br />
<br />
12<br />
<br />
Sobre o autor<br />
<br />
Walter de Tarso Faria Santos de Campos foi aprovado no concurso de AFR ICMS-SP de 2009 e está alocado no Centro de Desenvolvimento de Sistemas do Departamento de Tecnologia de Informações (CDS-DTI) da Secretaria da Fazenda de São Paulo. Este material foi um resumo de tudo de TI que estudou para esta prova. Formado em licenciatura em química pela Universidade de São Paulo, lecionou informática básica para alunos do ensino fundamental e médio no Colégio Rio Branco por doze anos. Exerceu consultoria de informática e desenvolveu mais de trinta sistemas para diversas intituições públicas e privadas por 25 anos, para FIPE, FIA, FIPECAFI, Secretaria do Meio Ambiente, CDHU, Convap Engenharia e Construções, GMR Arquitetos Associados, Fundação Padre Anchieta, Fundação Osesp, ABEM, Souza Cruz, entre outras.<br />
<br />
136<br />
<br />
TI para concursos<br />
<br />
13<br />
<br />
Gabarito<br />
<br />
47 1<br />
<br />
(b) 2 (a) 3 (e) 4 (b) 5 (e) 6 (b) 7 (d) 8 (e) 9 (b) 10 (a) 11 (c) 12 (a) 13 (b) 14 (d) 15 (b) 16 (d) 17 (a) 18 (c) 19 (a) 20 (d) 21 (c) 22 (d) 23 (c) 24 (e) 25 (b) 26 (a) 27 (d) 28 (c) 29 (e) 30 (b) 31 (a) 32 (a) 33 (d) 34 (d) 35 (d) 36 (c) 37 (d) 38 (d) 39 (a) 40 (b) 41 (b) 42 (e) 43 (c) 44 (a) 45 (d) 46 (e) 137<br />
<br />
(d) 48 (a) 49 (c) 50 (a) 51 (c) 52 (c) 53 (b) 54 (a) 55 (b) 56 (c) 57 (d) 58 (d) 59 (d) 60 (b) 61 (c) 62 (d) 63 (d) 64 (b) 65 (a) 66 (a) 67 (c) 68 (b) 69 (c) 70 (e) 71 (d) 72 (e) 73 (c) 74 (b) 75 (e) 76 (c) 77 (e) 78 (c) 79 (c) 80 (d) 81 (d) 82 (b) 83 (b) 84 (c) 85 (e) 86 (c) 87 (b) 88 (e) 89 (a) 90 (b) 91 (d) 92 (e) 93 (b)<br />
<br />
94<br />
<br />
(c) 95 (a) 96 (e) 97 (a) 98 (c) 99 (e) 100 (b) 101 (a) 102 (d) 103 (e) 104 (a) 105 (b) 106 (b) 107 (b) 108 (e) 109 (b) 110 (a) 111 (a) 112 (d) 113 (a) 114 (e) 115 (b) 116 (b) 117 (c) 118 (a) 119 (e) 120 (d) 121 (e) 122 (d) 123 (c) 124 (d) 125 (c) 126 (a) 127 (c) 128 (b) 129 (d) 130 (e) 131 (c) 132 (c) 133 (d) 134 (e) 135 (a) 136 (d) 137 (b) 138 (e) 139 (a) 140 (b)<br />
<br />
141<br />
<br />
(b) 142 (d) 143 (a) 144 (d) 145 (e) 146 (c) 147 (b) 148 (e) 149 (c) 150 (b) 151 (c) 152 (e) 153 (a) 154 (e) 155 (d) 156 (e) 157 (e) 158 (e) 159 (b) 160 (e) 161 (b) 162 (a) 163 (b) 164 (d) 165 (d) 166 (e) 167 (b) 168 (d) 169 (d) 170 (e) 171 (c) 172 (d) 173 (d) 174 (c) 175 (c) 176 (b) 177 (e) 178 (b) 179 (d) 180 (b) 181 (b) 182 (a) 183 (c) 184 (a) 185 (b) 186 (d) 187 (a)<br />
<br />
188<br />
<br />
(e) (d) 190 (d) 191 (c) 192 (d) 193 (b) 194 (a) 195 (d) 196 (b) 197 (c) 198 (d) 199 (c) 200 (c) 201 (a) 202 (a) 203 (b) 204 (c) 205 (a) 206 (c) 189<br />
<br />
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="modal fade" id="report" tabindex="-1" role="dialog" aria-hidden="true">
<div class="modal-dialog">
<div class="modal-content">
<form role="form" method="post" action="https://idoc.tips/report/apostila-de-ti-para-concursos-pdf-free" style="border: none;">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal" aria-hidden="true">×</button>
<h4 class="modal-title">Report "apostila de TI para concursos"</h4>
</div>
<div class="modal-body">
<div class="form-group">
<label>Your name</label>
<input type="text" name="name" required="required" class="form-control" />
</div>
<div class="form-group">
<label>Email</label>
<input type="email" name="email" required="required" class="form-control" />
</div>
<div class="form-group">
<label>Reason</label>
<select name="reason" required="required" class="form-control">
<option value="">-Select Reason-</option>
<option value="pornographic" selected="selected">Pornographic</option>
<option value="defamatory">Defamatory</option>
<option value="illegal">Illegal/Unlawful</option>
<option value="spam">Spam</option>
<option value="others">Other Terms Of Service Violation</option>
<option value="copyright">File a copyright complaint</option>
</select>
</div>
<div class="form-group">
<label>Description</label>
<textarea name="description" required="required" rows="3" class="form-control" style="border: 1px solid #cccccc;"></textarea>
</div>
<div class="form-group">
<div style="display: inline-block;">
<div class="g-recaptcha" data-sitekey="6LcHT8sZAAAAAPKfs_PZGhwvz-OHbUMuekQzz5xK"></div>
</div>
</div>
<script src='https://www.google.com/recaptcha/api.js'></script>
</div>
<div class="modal-footer">
<button type="button" class="btn btn-default" data-dismiss="modal">Close</button>
<button type="submit" class="btn btn-success">Send</button>
</div>
</form>
</div>
</div>
</div>
<script>
$(document).ready(function () {
var inner_height = $(window).innerHeight() - 250;
$('#pdfviewer').css({"height": inner_height + "px"});
});
</script>
<footer class="footer" style="margin-top: 60px;">
<div class="container-fluid">
Copyright © 2024 IDOC.TIPS. All rights reserved.
<div class="pull-right">
<span><a href="https://idoc.tips/about">About Us</a></span> |
<span><a href="https://idoc.tips/privacy">Privacy Policy</a></span> |
<span><a href="https://idoc.tips/term">Terms of Service</a></span> |
<span><a href="https://idoc.tips/copyright">Copyright</a></span> |
<span><a href="https://idoc.tips/contact">Contact Us</a></span> |
<span><a href="https://idoc.tips/cookie_policy">Cookie Policy</a></span>
</div>
</div>
</footer>
<!-- Modal -->
<div class="modal fade" id="login" tabindex="-1" role="dialog" aria-labelledby="myModalLabel">
<div class="modal-dialog" role="document">
<div class="modal-content">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal" aria-label="Close" on="tap:login.close"><span aria-hidden="true">×</span></button>
<h4 class="modal-title" id="add-note-label">Sign In</h4>
</div>
<div class="modal-body">
<form action="https://idoc.tips/login" method="post">
<div class="form-group">
<label class="sr-only" for="email">Email</label>
<input class="form-input form-control" type="text" name="email" id="email" value="" placeholder="Email" />
</div>
<div class="form-group">
<label class="sr-only" for="password">Password</label>
<input class="form-input form-control" type="password" name="password" id="password" value="" placeholder="Password" />
</div>
<div class="form-group">
<div class="checkbox">
<label class="form-checkbox">
<input type="checkbox" name="remember" value="1" />
<i class="form-icon"></i> Remember me
</label>
<label class="pull-right"><a href="https://idoc.tips/forgot">Forgot password?</a></label>
</div>
</div>
<button class="btn btn-primary btn-block" type="submit">Sign In</button>
</form>
</div>
</div>
</div>
</div>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-177830117-1"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'UA-177830117-1');
</script>
<script src="https://idoc.tips/assets/js/jquery-ui.min.js"></script>
<link rel="stylesheet" href="https://idoc.tips/assets/css/jquery-ui.css">
<script>
$(function () {
$("#document_search").autocomplete({
source: function (request, response) {
$.ajax({
url: "https://idoc.tips/suggest",
dataType: "json",
data: {
term: request.term
},
success: function (data) {
response(data);
}
});
},
autoFill: true,
select: function (event, ui) {
$(this).val(ui.item.value);
$(this).parents("form").submit();
}
});
});
</script>
<!-- cookie policy -->
<div id="IDOCTIPS_cookie_box" style="z-index:99999; background: #97c479; width: 100%; position: fixed; padding: 5px 15px; text-align: center; left:0; bottom: 0;">
Our partners will collect data and use cookies for ad personalization and measurement. <a href="https://idoc.tips/cookie_policy" target="_blank">Learn how we and our ad partner Google, collect and use data</a>. <a href="#" class="btn btn-success" onclick="accept_IDOCTIPS_cookie_box();return false;">Agree & close</a>
</div>
<script>
function accept_IDOCTIPS_cookie_box() {
document.cookie = "IDOCTIPS_cookie_box_viewed=1;max-age=15768000;path=/";
hide_IDOCTIPS_cookie_box();
}
function hide_IDOCTIPS_cookie_box() {
var cb = document.getElementById('IDOCTIPS_cookie_box');
if (cb) {
cb.parentElement.removeChild(cb);
}
}
(function () {
var IDOCTIPS_cookie_box_viewed = (function (name) {
var matches = document.cookie.match(new RegExp("(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)"));
return matches ? decodeURIComponent(matches[1]) : undefined;
})('IDOCTIPS_cookie_box_viewed');
if (IDOCTIPS_cookie_box_viewed) {
hide_IDOCTIPS_cookie_box();
}
})();
</script>
<!-- end cookie policy -->
</body>
</html>
