sexta-feira, 28 de junho de 2013

Criptografia


Criptografia chave simétrica, onde a mesma chave é utilizada para cifrar e decifrar.

A máquina Enigma, utilizada na cifragem e decifragem de mensagens secretas.
Criptografia (Do Grego kryptós, "escondido", e gráphein, "escrita") é o estudo dos princípios e técnicas pelas quais a informação pode ser transformada da sua forma original para outra ilegível, de forma que possa ser conhecida apenas por seu destinatário (detentor da "chave secreta"), o que a torna difícil de ser lida por alguém não autorizado. Assim sendo, só o receptor da mensagem pode ler a informação com facilidade. É um ramo da Matemática, parte da Criptologia.1 2 Há dois tipos de chaves criptográficas: chaves simétricas e chaves assimétrica.3 Uma informação não-cifrada que é enviada de uma pessoa (ou organização) para outra é chamada de "texto claro" (plaintext). Cifragem é o processo de conversão de um texto claro para um código cifrado e decifragem é o processo contrário, de recuperar o texto original a partir de um texto cifrado. De facto, o estudo da criptografia cobre bem mais do que apenas cifragem e decifragem. É um ramo especializado da teoria da informação com muitas contribuições de outros campos da matemática e do conhecimento, incluindo autores como Maquiavel, Sun Tzu e Karl von Clausewitz. A criptografia moderna é basicamente formada pelo estudo dos algoritmos criptográficos que podem ser implementados em computadores.

Índice

1 Terminologia
2 História
3 Cifras e Códigos
3.1 Chave Criptográfica
4 Visão geral: objetivos
5 Criptografia Clássica
6 Criptografia Moderna
6.1 Criptografia Quântica
7 Gestão de direitos digitais
8 Alguns algoritmos e sistemas criptográficos
8.1 Funções de Hash criptográfico, ou message digest
8.2 Sistemas Free/Open Source
8.3 Algoritmos assimétricos ou de chave pública
8.4 Algoritmos simétricos
9 Referências
10 Bibliografia


Terminologia

O termo é comumente usado para se referir a área de estudo de forma abrangente, como criptologia ("o estudo dos segredos"). Outros termos relacionados são: Criptoanálise, Esteganografia, Esteganálise, Código, e Criptologia. Alguns autores cunharam o termo Criptovirologia para se referir a vírus que contém e usam chaves públicas.4 O estudo das formas de esconder o significado de uma mensagem usando técnicas de cifragem tem sido acompanhado pelo estudo das formas de conseguir ler a mensagem quando não se é o destinatário; este campo de estudo é chamado criptoanálise.5

As pessoas envolvidas neste trabalho, e na criptografia em geral, são chamados criptógrafos, criptólogos ou criptoanalistas, dependendo de suas funções específicas.

A Esteganografia é o estudo das técnicas de ocultação de mensagens dentro de outras, diferentemente da Criptografia, que a altera de forma a tornar seu significado original ininteligível. A Esteganografia não é considerada parte da Criptologia, apesar de muitas vezes ser estudada em contextos semelhantes e pelos mesmos pesquisadores. A Esteganálise é o equivalente a criptoanálise com relação à Esteganografia.6

História

Antigamente, a cifragem era utilizada na troca de mensagens, sobretudo em assuntos ligados à guerra (no intuito de o inimigo não descobrir a estratégia do emissor da mensagem, caso se apoderasse dela), ao amor (para que os segredos amorosos não fossem descobertos pelos familiares) e à diplomacia (para que facções rivais não estragassem os planos de acordos diplomáticos entre nações). O primeiro uso documentado da criptografia foi em torno de 1900 a.c., no Egito, quando um escriba usou hieróglifos fora do padrão numa inscrição.

Entre 600 a.c. e 500 a.c., os hebreus utilizavam a cifra de substituição simples (de fácil reversão e fazendo uso de cifragem dupla para obter o texto original), sendo monoalfabético e monogrâmica (os caracteres são trocados um a um por outros), e com ela escreveram o Livro de Jeremias.

O chamado "Codificador de Júlio César" ou "Cifra de César" que apresentava uma das técnicas mais clássicas de criptografia, é um exemplo de substituição que, simplesmente, substitui as letras do alfabeto avançando três casas. O autor da cifragem trocava cada letra por outra situada a três posições à frente no alfabeto. Segundo o autor, esse algoritmo foi responsável por enganar muitos inimigos do Império Romano; no entanto, após ter sido descoberta a chave, como todas, perdeu sua funcionalidade.

Em 1586, destacam-se os estudos de Blaise de Vigenère que constituíram um método muito interessante; é a cifra de Vigenère que utiliza a substituição de letras. Tal processo consiste na seqüência de várias cifras (como as de César) com diferentes valores de deslocamento alfanumérico. A partir desse período, Renascença, a criptologia começou a ser seriamente estudada no Ocidente e, assim, diversas técnicas foram utilizadas e os antigos códigos monoalfabéticos foram, aos poucos, sendo substituídos por polialfabéticos.

Dos anos 700 a 1200, são relatados incríveis estudos estatísticos, em que se destacam expoentes como al-Khalil, al-Kindi, Ibn Dunainir e Ibn Adlan, que marcaram sua época. Na Idade Média, a civilização árabe-islâmica contribuiu muito para os processos criptográficos, sobretudo quanto à criptoanálise (análise da codificação, a procura de padrões que identificassem mensagens camufladas por códigos).

Na Idade Moderna, merecem destaque o holandês Kerckhoff e o alemão Kasiski. Modernamente, em 1918, Arthur Scherbius desenvolveu uma máquina de criptografia chamada Enigma, utilizada amplamente pela marinha de guerra alemã em 1926, como a principal forma de comunicação.

Em 1928, o exército alemão construiu uma versão conhecida como "Enigma G", que tinha como garantidor de segurança a troca periódica mensal de suas chaves. Essa máquina tinha como diferencial ser elétrico-mecânica, funcionando com três (inicialmente) a oito rotores. Aparentava ser uma máquina de escrever, mas quando o usuário pressionava uma tecla, o rotor da esquerda avançava uma posição, provocando a rotação dos demais rotores à direita, sendo que esse movimento dos rotores gerava diferentes combinações de encriptação.

Assim, a codificação da mensagem pelas máquinas "Enigma" era de muito difícil decodificação, uma vez que, para isso, era necessário ter outra máquina dessas e saber qual a chave (esquema) utilizada para realizar a codificação.

A Colossus surgiu do esforço de engenharia reversa das forças aliadas em decriptar as mensagens da marinha e do exército alemão, só logrando efetivo êxito após se ter conseguido uma máquina Enigma alemã (furtada). Tais equipamentos foram, inicialmente, desenvolvidos como máquinas de decriptação, mas depois passaram a codificar mensagens das forças aliadas.

Depois, surgiram outras máquinas fisicamente semelhantes à Enigma (pareciam com antigas máquinas de escrever), porém foram aperfeiçoadas de forma a dificultar o mais possível a decriptação por quem não as possuísse.

Devido aos esforços de guerra, a criptografia passou a ser largamente utilizada. Em 1948, Claude Shannon desenvolveu a Teoria Matemática da Comunicação, que permitiu grandes desenvolvimentos nos padrões de criptografia e na criptoanálise.

Durante a chamada "Guerra Fria", entre Estados Unidos e União Soviética, foram criados e utilizados diversos métodos a fim de esconder mensagens a respeito de estratégias e operações, criptografadas com diferentes métodos e chaves.

Diffie e Hellman revolucionaram os sistemas de criptografia existentes até 1976, a partir do desenvolvimento de um sistema de criptografia de chave pública que foi aperfeiçoado por pesquisadores do MIT e deu origem ao algoritmo RSA.

Além dos avanços da criptografia, a criptoanálise se desenvolveu muito com os esforços de se descobrir padrões e chaves, além da diversidade dos canais de propagação das mensagens criptografadas. Desses esforços, surgiram diversos tipos de criptografia, tais como por chave simétrica, por chave assimétrica, por hash e até a chamada criptografia quântica, que se encontra, hoje, em desenvolvimento.

Durante muito tempo, o termo referiu-se exclusivamente à cifragem, o processo de converter uma informação comum (texto claro) em algo não-inteligível; o qual chama-se texto cifrado. Adecifragem é a tarefa contrária, dado uma informação não-inteligível convertê-la em texto claro. No uso coloquial, o termo "código" é usado para referir-se a qualquer método de cifragem ou similar. Em criptografia, "código" tem um significado mais específico, refere-se a substituição de uma unidade significativa (i.e., o significado de uma palavra ou frase) pelo substituto equivalente. Códigos não são mais usados na criptografia moderna, visto que o uso de cifras se tornou mais prático e seguro, como também melhor adaptado aos computadores.

Nos dias atuais, onde grande parte dos dados é digital, sendo representados por bits, o processo de criptografia é basicamente feito por algoritmos que fazem o embaralhamento dos bits desses dados a partir de uma determinada chave ou par de chaves, dependendo do sistema criptográfico escolhido. Atualmente, a criptografia é amplamente utilizada na WEB, em segurança a fim de autenticar os usuários para lhes fornecer acesso, na proteção de transações financeiras e em redes de comunicação.

Cifras e Códigos

A cifra é um ou mais algoritmos que cifram e decifram um texto. A operação do algoritmo costuma ter como parâmetro uma chave criptográfica. Tal parâmetro costuma ser secreto (conhecido somente pelos comunicantes). A cifra pode ser conhecida, mas não a chave; assim como se entende o mecanismo de uma fechadura comum, mas não se pode abrir a porta sem uma chave real.

Na linguagem não-técnica, um Código secreto é o mesmo que uma cifra. Porém, na linguagem especializada os dois conceitos são distintos. Um código funciona manipulando o significado, normalmente pela substituição simples de palavras ou frases. Uma cifra, ao contrário, trabalha na representação da mensagem (letras, grupos de letras ou, atualmente, bits).

Por exemplo, um código seria substituir a frase "Atacar imediatamente" por "Mickey Mouse". Uma cifra seria substituir essa frase por "sysvst ozrfosyszrmyr". No Dia D, por exemplo, as praias de desembarque não eram conhecidas pelo seu nome próprio, mas pelos seus códigos (Omaha, Juno, etc.).

Basicamente, códigos não envolvem chave criptográfica, apenas tabelas de substituição ou mecanismos semelhantes. Códigos podem ser então encarados como cifras cuja a chave é o próprio conhecimento do mecanismo de funcionamento da cifra.

Chave Criptográfica

Uma chave criptográfica é um valor secreto que modifica um algoritmo de encriptação. A fechadura da porta da frente da sua casa tem uma série de pinos. Cada um desses pinos possui múltiplas posições possíveis. Quando alguém põe a chave na fechadura, cada um dos pinos é movido para uma posição específica. Se as posições ditadas pela chave são as que a fechadura precisa para ser aberta, ela abre, caso contrário, não.

Visão geral: objetivos

A criptografia tem quatro objetivos principais:

confidencialidade da mensagem: só o destinatário autorizado deve ser capaz de extrair o conteúdo da mensagem da sua forma cifrada. Além disso, a obtenção de informação sobre o conteúdo da mensagem (como uma distribuição estatística de certos caracteres) não deve ser possível, uma vez que, se o for, torna mais fácil a análise criptográfica.
integridade da mensagem: o destinatário deverá ser capaz de determinar se a mensagem foi alterada durante a transmissão.
autenticação do remetente: o destinatário deverá ser capaz de identificar o remetente e verificar que foi mesmo ele quem enviou a mensagem.
não-repúdio ou irretratabilidade do emissor: não deverá ser possível ao emissor negar a autoria da mensagem.
Nem todos os sistemas ou algoritmos criptográficos são utilizados para atingir todos os objetivos listados acima. Normalmente, existem algoritmos específicos para cada uma destas funções. Mesmo em sistemas criptográficos bem concebidos, bem implementados e usados adequadamente, alguns dos objetivos acima não são práticos (ou mesmo desejáveis) em algumas circunstâncias. Por exemplo, o remetente de uma mensagem pode querer permanecer anônimo, ou o sistema pode destinar-se a um ambiente com recursos computacionais limitados.

Criptografia Clássica


Um bastão reconstruído dos gregos antigos, a Cítala era utilizada para envio de mensagens secretas
Podemos dizer que o uso da criptografia é tão antigo quanto a necessidade do homem em esconder a informação. Muitos pesquisadores atribuem o uso mais antigo da criptografia conhecido aos hieróglifos usados em monumentos do Antigo Egito (cerca de 4500 anos atrás). Diversas técnicas de ocultar mensagens foram utilizadas pelos gregos e romanos.

A criptografia pré-computacional era formada por um conjunto de métodos de substituição e transposição dos caracteres de uma mensagem que pudessem ser executados manualmente (ou até mesmo mentalmente) pelo emissor e pelo destinatário da mensagem. O surgimento de máquinas especializadas e, posteriormente, dos computadores ocasionou uma significativa evolução das técnicas criptográficas.

Criptografia Moderna


Cartão de crédito com funções de cartão inteligente, é mostrado o chip de 3x5 mm embutido no cartão. Os cartões inteligentes combinam a portabilidade o baixo custo e capacidade de correr algoritmos de encriptação.
A era da criptografia moderna começa realmente com Claude Shannon, possivelmente o pai da criptografia matemática. Em 1949 ele publicou um artigo Communication Theory of Secrecy Systems com Warren Weaver. Este artigo, junto com outros de seus trabalhos que criaram a área de Teoria da Informação estabeleceu uma base teórica sólida para a criptografia e para a criptoanálise. Depois disso, quase todo o trabalho realizado em criptografia se tornou secreto, realizado em organizações governamentais especializadas (como o NSA nos Estados Unidos). Apenas em meados de 1970 as coisas começaram a mudar.

Em 1976 aconteceram dois grandes marcos da criptografia para o público. O primeiro foi a publicação, pelo governo americano, do DES (Data Encryption Standard), um algoritmo aberto de criptografia simétrica, selecionado pela NIST em um concurso onde foi escolhido uma variante do algoritmo Lucifer, proposto pela IBM. O DES foi o primeiro algoritmo de criptografia disponibilizado abertamente ao mercado.

O segundo foi a publicação do artigo New Directions in Cryptography por Whitfield Diffie e Martin Hellman, que iniciou a pesquisa em sistemas de criptografia de chave pública. Este algoritmo ficou conhecido como "algoritmo Diffie-Hellman para troca de chaves" e levou ao imediato surgimento de pesquisas neste campo, que culminou com a criação do algoritmo RSA, por Ronald Rivest, Adi Shamir e Leonard Adleman.

Criptografia Quântica

Desenvolvimento da técnica reunindo o conceito de criptografia e a teoria quântica é mais antigo do que se imagina, sendo anterior à descoberta da criptografia de Chave Pública. Stephen Wiesner escreveu um artigo por volta de 1970 com o título: "Conjugate Coding" que permaneceu sem ser publicado até o ano de 1983. Em seu artigo, Wiesner explica como a teoria quântica pode ser usada para unir duas mensagens em uma única transmissão quântica na qual o receptor poderia decodificar cada uma das mensagens porém nunca as duas simultaneamente, pela impossibilidade de violar uma lei da natureza (o princípio de incerteza de Heisenberg).7

Utilizando-se pares de fótons, a criptografia quântica permite que duas pessoas escolham uma chave secreta sem jamais terem se visto, trocado alguma mensagem ou mesmo algo material. A criptografia quântica oferece a possibilidade de gerar uma chave segura se o sinal é um objeto quântico, assim, o termo mais correto seria Distribuição de Chave Quântica (Quantum Key Distribution - QKD) e não Criptografia Quântica. É interessante notar que a Criptologia atual está amparada na Matemática mas com a introdução desse conceito de mensagens criptografadas por chaves quânticas a física passou a ter importância primordial no tema. O maior problema para implementação da Criptografia quântica ainda é a taxa de erros na transmissão dos fótons seja por via aérea ou fibra ótica. Os melhores resultados obtidos atualmente se dão em cabos de fibra ótica de altíssima pureza, e conseqüentemente elevadíssimo custo também, alcançando algo em torno de 70 km.

Por via aérea a distância chega a algumas centenas de metros e qualquer tentativa de se aumentar essa distância tanto em um quanto em outro método a taxa de erros se torna muito grande e inviabiliza o processo. O desenvolvimento de tecnologias que permitam o perfeito alinhamento dos polarizadores, fibras óticas melhores e amplificadores quânticos de sinais permitirá que o sistema de Distribuição de Chaves Quânticas venha a ser o novo padrão de segurança de dados.

A Criptografia Quântica se destaca em relação aos outros métodos criptográficos pois não necessita do segredo nem do contato prévio entre as partes, permite a detecção de intrusos tentando interceptar o envio das chaves, e é incondicionalmente segura mesmo que o intruso tenha poder computacional ilimitado. A única forma possível de falha no processo seria se utilizar de um ardil onde a comunicação fosse interceptada e substituída, tanto para o emissor quanto para o receptor, criando assim um canal de comunicação controlado pelo intruso. O processo ainda apresenta um elevado custo de implantação, mas o desenvolvimento tecnológico poderá torná-la acessível a todas as aplicações militares, comerciais e de fins civis em geral.

Gestão de direitos digitais

A criptografia é central no tema de gestão de direitos digitais (DRM), um grupo de técnicas para controlar e restringir tecnologicamente o uso de direitos autorais e suas marcas registradas. Em 1998 a lei Estadounidense Millennium Copyright Act (DMCA) criminaliza toda a produção e diseminação de certas técnicas (não conhecidas ou mais tarde conhecidas) da criptogafia, especialmente aquelas que poderiam ser utilizadas para ultrapassar o DRM. Leis e códigos similares ao DRM foram desde essa altura aparecendo em vários países e regiões, incluindo a implementação Directive on the harmonisation of certain aspects of copyright and related rights in the information society na Europa. Leis com restrições similares estão a ser propostos pelos Estados membros da Organização Mundial da Propriedade Intelectual.

Alguns algoritmos e sistemas criptográficos

Funções de Hash criptográfico, ou message digest

MD5
SHA-1
RIPEMD-160
Tiger
Sistemas Free/Open Source

PGP
GPG
SSL
IPSec / Free S/WAN
Algoritmos assimétricos ou de chave pública

Curvas elípticas
Diffie-Hellman
DSA de curvas elípticas
El Gamal
RSA
Algoritmos simétricos

Máquina Enigma (Máquina alemã de rotores utilizada na 2a Guerra Mundial)
DES - Data Encryption Standard (FIPS 46-3, 1976)
RC4 (um dos algoritmos criados pelo Prof. Ron Rivest)
RC5 (também por Prof. Ron Rivest)
Blowfish (por Bruce Schneier)
IDEA - International Data Encryption Algorithm (J Massey e X Lai)
AES (também conhecido como RIJNDAEL) - Advanced Encryption Standard (FIPS 197, 2001)
RC6 (Ron Rivest)
Referências

↑ Fiarresga, Victor Manuel Calhabrês; Jorge Nuno Oliveira e Silva (2010). Criptografia e Matemática. Repositório aberto da Universidade de Lisboa Teses de mestrado. Página visitada em 17 de Junho de 2012.
↑ Knudsen, Jonathan. Java Cryptography. Beijing: O´Reilly, 1998. 344 p. ISBN 1-56592-402-9
↑ Alecrim, Emerson (2010). Criptografia. InfoWester Propagando Conhecimento. Página visitada em 17 de Junho de 2012.
↑ Young, Adam L.; Yung, Moti. Malicious Cryptography: Exposing Cryptovirology. Indianapolis: Addison-Wesley, 2004. 392 p. ISBN 0-7645-4975-8
↑ Gaines, Hele Fouché. Cryptanalysis. New York: Dover Publications, 1956. 237 p.
↑ Solomon, David. Coding for Data and Computer Communications. Northridge, California: Springer, 2005. 548 p. ISBN 0-387-21245-0
↑ Introdução à criptografia quântica (PDF). Revista Brasileira de Ensino de Física, v. 27, n. 4, p. 517 - 526, (2005). Página visitada em 10 de fevereiro de 2009.

Bibliografia

Hook, David. Beginning Cryptography with Java. Indianapolis: Wrox, 2005. 448 p. ISBN 0-7645-9633-0
Schneier, Bruce. Applied Cryptography. New York: John Wiley and Sons, 1996. 758 p. ISBN 0-471-11709-9
Viktoria Tkotz, Criptografia -Segredos Embalados para Viagem. Novatec Editora. ISBN 85-7522-071-3.

Qualidade de software




A qualidade de software é uma á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.

Segundo a norma ISO 9000 (versão 2000), a qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos inicialmente estipulados para estes.

No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento1 , desta forma, é comum que a busca por um software de maior qualidade passe necessariamente por uma melhoria no processo de desenvolvimento.

Rodney Brooks, diretor do Laboratório de Inteligência Artificial e Ciência da Computação do MIT, define qualidade como a conformidade aos requisitos. Essa definição exige determinar dois pontos: I) o que se entende por conformidade; e II) como são especificados - e por quem - os requisitos.

Índice

1 Principais tópicos
2 Requisitos de qualidade
3 O processo de software Cabeça de martelo
3.1 Garantia de qualidade de software
3.2 Modelos de qualidade


Principais tópicos

Para um melhor entendimento e estudo, o SWEBOK divide a qualidade de software em três tópicos, e cada tópico é subdividido em atividades, da seguinte forma:

Fundamentos de qualidade de software
Cultura e ética de engenharia de software
Valores e custos de qualidade
Modelos e características de qualidade
Melhoria da qualidade
Gerência do processo de qualidade de software
Garantia de qualidade de software
Verificação e validação
Revisões e auditorias
Considerações práticas
Requisitos de qualidade para aplicações
Caracterização de defeitos
Técnicas de gerência de qualidade de software
Medidas de qualidade de software
Ainda segundo o SWEBOK, a qualidade de software é um tema tão importante que é encontrado, de forma ubíqua, em todas as outras áreas de conhecimento envolvidas em um projeto. Além disso, ele deixa claro que essa área, como nele definida, trata do aspectos estáticos, ou seja, daqueles que não exigem a execução do software para avaliá-lo, em contraposição á área de conhecimento teste de software.

Porém, é normal que se encontrem autores e empresas que afirmam serem os testes de software uma etapa da qualidade de software.

Muita coisa pode ser encontrada no site http://www.ibqts.com.br O IBQTS, Instituto Brasileiro de Qualidade em Testes de Software.
Podem ser encontradas mais informações no site http://www.bstqb.com.br o BSTQB, Brazilian Software Testing Quality Board

Requisitos de qualidade

Requisitos de qualidade é um tópico por si dentro do assunto qualidade. Dentro da ótica desta última, espera-se que os requisitos sejam definidos de maneira a caracterizar completamente o produto a ser construído. Nesse aspecto - e em relação à definição de Brooks - é evidente que as zonas de sombra dentro de uma especificação abrem margem a todo tipo de problemas de avaliação de produtos.

Sommerville2 distingue requisitos funcionais e não funcionais. O modelo internacional mais recente Square, estabelecido pela norma ISO 25000, adota uma classificação um pouco diferente e utiliza uma descrição hierárquica. Dentro dessa descrição, "funcionalidade" é uma das seis divisões iniciais em que se classificam os requisitos de um produto de software.

Idealmente, a especificação de requisitos deve permitir que o processo de fabricação do software seja controlado. Isso significa que idealmente a qualidade de produtos intermediários deve poder ser mensurada e que os dados obtidos devem trazer informação que possa levar ao controle de desvios, localização de defeitos e outras ocorrências negativas.

O processo de software Cabeça de martelo

Nas últimas décadas foram propostas dezenas de metodologias e processos adaptados a diferentes cenários e produtos. Embora se possa justificar essa multiplicidade por outra lei de Brooks - a ausência de "balas de prata", é um fato que a situação se mostra confusa.

Há dezenas de trabalhos propostos para casos particulares. Exemplos das diversas iniciativas para tratar o assunto são metodologias como XP e Scrum; o modelo CMM, seguido de toda uma série de adaptações (como SW-CMM, people-CMM, etc.), mais tarde substituído pelo modelo CMMI; e dezenas de artigos e teses de mestrado e doutorado, abordando tópicos particulares em um ou mais de tais métodos, ou propondo ainda novas adaptações a casos particulares.

A situação deixa evidente que há um vácuo a ser preenchido - atacar a raiz do problema e identificar uma estrutura suficientemente geral, capaz de explicar o problema de qualidade e ser adaptada a todos os cenários diferentes. Se tal objetivo é possível resta a ser provado - assunto para novos artigos e teses.

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.

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;
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; e
a busca de uma melhoria contínua no processo de desenvolvimento de software.
Para facilitar o trabalho dos desenvolvedores e evitar geração de metodologias diversas, o Serpro desenvolveu o Processo Serpro de Desenvolvimento de Soluções (PSDS).

O PSDS foi construído por pessoas das unidades da empresa que procuraram aproveitar as melhores práticas existentes e consagradas.

O "CMM - Capability Maturity Model for Software /SEI" é uma estrutura-"framework", que descreve os principais elementos de um processo de desenvolvimento de software efetivo. O CMM descreve os estágios de maturidade através dos quais 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, repetitivo, definido, gerenciado e otimizado.

O Modelo CMM (CMM- Capability Maturity Model) fornece às organizações uma direção sobre como ganhar controle de seu processo de desenvolvimento de software e como evoluir para uma cultura de excelência na gestão de software. O objetivo principal nas transações destes níveis de maturidade é a realização de um processo controlado e mensurado como a fundação para melhoria contínua. Cada nível de maturidade possui um conjunto de práticas de software e gestão específicas, denominado áreas-chave do processo. Estas devem ser implantadas para a organização atingir o nível de maturidade em qualidade de software..

Modelos de qualidade

CMMI
MPS.BR
ISO 9126
ISO 15504
ISO 12207

Referências

↑ Qualidade de Software: Visões de Produto e Processo de Software
↑ Sommerville, I. Engenharia de Software. [S.l.]: Pearson/Prentice Hall, 2007. 568 p. 9788588639287
Bibliografia

AROUCK, O. Avaliação de sistemas de informação: revisão da literatura. Transinformação, v. 13, n. 1, jan./jun., 2001. p. 7-21.
BROOKS, F. P. No Silver Bullet: Essence and Accidents of Software Engineering". Computer, Vol. 20, N. 4, pp 10–19. April, 1987.
KOSCIANSKI, A., Soares, M. S.. Qualidade de Software. Editora Novatec, Segunda Edição, 2007.
MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software, Editora Visual Books, 2007, Florianópolis, 85-7502-210-5.
MOLINARI, Leonardo. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis, Editora Èrica, 2006, 3a Edição, São Paulo, 85-7194-959X.
PRESSMAN, R. S. Engenharia de Software. McGraw Hill, 2002.

Qualidade de software


A qualidade de software é uma á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.

Segundo a norma ISO 9000 (versão 2000), a qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos inicialmente estipulados para estes.

No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento1 , desta forma, é comum que a busca por um software de maior qualidade passe necessariamente por uma melhoria no processo de desenvolvimento.

Rodney Brooks, diretor do Laboratório de Inteligência Artificial e Ciência da Computação do MIT, define qualidade como a conformidade aos requisitos. Essa definição exige determinar dois pontos: I) o que se entende por conformidade; e II) como são especificados - e por quem - os requisitos.

Índice

1 Principais tópicos
2 Requisitos de qualidade
3 O processo de software Cabeça de martelo
3.1 Garantia de qualidade de software
3.2 Modelos de qualidade


Principais tópicos

Para um melhor entendimento e estudo, o SWEBOK divide a qualidade de software em três tópicos, e cada tópico é subdividido em atividades, da seguinte forma:

Fundamentos de qualidade de software
Cultura e ética de engenharia de software
Valores e custos de qualidade
Modelos e características de qualidade
Melhoria da qualidade
Gerência do processo de qualidade de software
Garantia de qualidade de software
Verificação e validação
Revisões e auditorias
Considerações práticas
Requisitos de qualidade para aplicações
Caracterização de defeitos
Técnicas de gerência de qualidade de software
Medidas de qualidade de software
Ainda segundo o SWEBOK, a qualidade de software é um tema tão importante que é encontrado, de forma ubíqua, em todas as outras áreas de conhecimento envolvidas em um projeto. Além disso, ele deixa claro que essa área, como nele definida, trata do aspectos estáticos, ou seja, daqueles que não exigem a execução do software para avaliá-lo, em contraposição á área de conhecimento teste de software.

Porém, é normal que se encontrem autores e empresas que afirmam serem os testes de software uma etapa da qualidade de software.

Muita coisa pode ser encontrada no site http://www.ibqts.com.br O IBQTS, Instituto Brasileiro de Qualidade em Testes de Software.
Podem ser encontradas mais informações no site http://www.bstqb.com.br o BSTQB, Brazilian Software Testing Quality Board

Requisitos de qualidade

Requisitos de qualidade é um tópico por si dentro do assunto qualidade. Dentro da ótica desta última, espera-se que os requisitos sejam definidos de maneira a caracterizar completamente o produto a ser construído. Nesse aspecto - e em relação à definição de Brooks - é evidente que as zonas de sombra dentro de uma especificação abrem margem a todo tipo de problemas de avaliação de produtos.

Sommerville2 distingue requisitos funcionais e não funcionais. O modelo internacional mais recente Square, estabelecido pela norma ISO 25000, adota uma classificação um pouco diferente e utiliza uma descrição hierárquica. Dentro dessa descrição, "funcionalidade" é uma das seis divisões iniciais em que se classificam os requisitos de um produto de software.

Idealmente, a especificação de requisitos deve permitir que o processo de fabricação do software seja controlado. Isso significa que idealmente a qualidade de produtos intermediários deve poder ser mensurada e que os dados obtidos devem trazer informação que possa levar ao controle de desvios, localização de defeitos e outras ocorrências negativas.

O processo de software Cabeça de martelo

Nas últimas décadas foram propostas dezenas de metodologias e processos adaptados a diferentes cenários e produtos. Embora se possa justificar essa multiplicidade por outra lei de Brooks - a ausência de "balas de prata", é um fato que a situação se mostra confusa.

Há dezenas de trabalhos propostos para casos particulares. Exemplos das diversas iniciativas para tratar o assunto são metodologias como XP e Scrum; o modelo CMM, seguido de toda uma série de adaptações (como SW-CMM, people-CMM, etc.), mais tarde substituído pelo modelo CMMI; e dezenas de artigos e teses de mestrado e doutorado, abordando tópicos particulares em um ou mais de tais métodos, ou propondo ainda novas adaptações a casos particulares.

A situação deixa evidente que há um vácuo a ser preenchido - atacar a raiz do problema e identificar uma estrutura suficientemente geral, capaz de explicar o problema de qualidade e ser adaptada a todos os cenários diferentes. Se tal objetivo é possível resta a ser provado - assunto para novos artigos e teses.

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.

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;
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; e
a busca de uma melhoria contínua no processo de desenvolvimento de software.
Para facilitar o trabalho dos desenvolvedores e evitar geração de metodologias diversas, o Serpro desenvolveu o Processo Serpro de Desenvolvimento de Soluções (PSDS).

O PSDS foi construído por pessoas das unidades da empresa que procuraram aproveitar as melhores práticas existentes e consagradas.

O "CMM - Capability Maturity Model for Software /SEI" é uma estrutura-"framework", que descreve os principais elementos de um processo de desenvolvimento de software efetivo. O CMM descreve os estágios de maturidade através dos quais 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, repetitivo, definido, gerenciado e otimizado.

O Modelo CMM (CMM- Capability Maturity Model) fornece às organizações uma direção sobre como ganhar controle de seu processo de desenvolvimento de software e como evoluir para uma cultura de excelência na gestão de software. O objetivo principal nas transações destes níveis de maturidade é a realização de um processo controlado e mensurado como a fundação para melhoria contínua. Cada nível de maturidade possui um conjunto de práticas de software e gestão específicas, denominado áreas-chave do processo. Estas devem ser implantadas para a organização atingir o nível de maturidade em qualidade de software..

Modelos de qualidade

CMMI
MPS.BR
ISO 9126
ISO 15504
ISO 12207

Referências

↑ Qualidade de Software: Visões de Produto e Processo de Software
↑ Sommerville, I. Engenharia de Software. [S.l.]: Pearson/Prentice Hall, 2007. 568 p. 9788588639287
Bibliografia

AROUCK, O. Avaliação de sistemas de informação: revisão da literatura. Transinformação, v. 13, n. 1, jan./jun., 2001. p. 7-21.
BROOKS, F. P. No Silver Bullet: Essence and Accidents of Software Engineering". Computer, Vol. 20, N. 4, pp 10–19. April, 1987.
KOSCIANSKI, A., Soares, M. S.. Qualidade de Software. Editora Novatec, Segunda Edição, 2007.
MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software, Editora Visual Books, 2007, Florianópolis, 85-7502-210-5.
MOLINARI, Leonardo. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis, Editora Èrica, 2006, 3a Edição, São Paulo, 85-7194-959X.
PRESSMAN, R. S. Engenharia de Software. McGraw Hill, 2002.

Jogo eletrônico de plataforma





Trailer do jogo Dustforce exibindo caracterias de plataforma, como inimigos, obstáculos, pulos duplos e pulos pela parede.
Jogo eletrônico de plataforma é o nome dado a um gênero de jogos de Video-game em que o jogador corre e pula entre plataformas e obstáculos, enfrentando inimigos e coletando objetos bônus. Alguns dos mais conhecidos e difundidos exemplos destes tipos de jogos são o Super Mario Bros. e o Sonic the Hedgehog. Este gênero atinge diretamente o publico infantil e vários representantes do publico jovem e adulto também. São jogos que requerem um pouco mais de tempo do usuário, uma vez que o jogador só consegue prosseguir no jogo se atingir algumas metas, o que acaba exigindo muitas vezes um pouco de treino.

As séries de jogos de plataforma mais famosas são Mario e Sonic. Outras franquias de plataforma incluem Donkey Kong, Crash Bandicoot, Prince of Persia, Castlevania e Mega Man.

História

Era de Single screen

Jogos de plataforma apareceram primeiramente no início da década de 1980, quando vários gêneros de video game estavam apenas começando a tomar forma. Por causa das limitações técnicas da época, os primeiros exemplos eram limitados à campos de jogo estáticos, geralmente vistos de perfil. Embora os jogos de plataforma ofereciam um novo tipo de jogabilidade, eles ainda pegavam muitas coisas de jogos anteriores. Frogs, um jogo de arcade lançado pela Gremlin em 1978, foi o primeiro jogo a ter um personagem que pulava, fazendo dele um dos primeiros antecessores do gênero.

Space Panic, lançado em 1980 para arcade, é por vezes creditado como um dos primeiros jogos de plataforma,1 mas isso não é consenso, já que o jogador não tinha a habilidade de pular, nadar, balançar-se, ou cair, e como tal, não satisfaz a maior parte da definição moderna do gênero. Entretanto, ele foi claramente uma influência para o gênero, com a jogabilidade centrada em subir as escadas entre diferentes níveis, um elemento comum em muitos dos primeiros jogos de plataforma.

Donkey Kong, um jogo de arcade criado pela Nintendo, lançado em julho de 1981, foi o primeiro jogo que permitia aos jogadores pular sobre obstáculos e buracos, tornando-o o primeiro jogo verdadeiramente de plataforma.2 Donkey Kong tinha uma quantidade limitada de plataforma nas duas primeiras telas, mas nas outras duas o componente de pulo das plataformas estava mais acentuada. O jogo também introduziu Mario, um ícone do gênero. Donkey Kong foi lançado para vários consoles e computadores da época, e o jogo ajudou a definir a posição da Nintendo como um importante nome internacional para a indústria de video games.

O quarto jogo da série foi Mario Bros, um jogo de plataforma que oferecia um jogo cooperativo para dois jogadores simultâneos. O título inspirou outros jogos populares de plataforma com cooperação entre dois jogadores, como Fairyland Story e Bubble Bobble, que, por sua vez, influenciou muitos dos jogos de plataforma de uma tela que seriam criados.

Referências

↑ Crawford, Chris. Chris Crawford on Game Design. [S.l.]: New Riders, 2003. ISBN 0-88134-117-7
↑ Donkey Kong. Arcade History (2006-11-21). Página visitada em 2006-11-21.

Jogo eletrônico de plataforma



Trailer do jogo Dustforce exibindo caracterias de plataforma, como inimigos, obstáculos, pulos duplos e pulos pela parede.
Jogo eletrônico de plataforma é o nome dado a um gênero de jogos de Video-game em que o jogador corre e pula entre plataformas e obstáculos, enfrentando inimigos e coletando objetos bônus. Alguns dos mais conhecidos e difundidos exemplos destes tipos de jogos são o Super Mario Bros. e o Sonic the Hedgehog. Este gênero atinge diretamente o publico infantil e vários representantes do publico jovem e adulto também. São jogos que requerem um pouco mais de tempo do usuário, uma vez que o jogador só consegue prosseguir no jogo se atingir algumas metas, o que acaba exigindo muitas vezes um pouco de treino.

As séries de jogos de plataforma mais famosas são Mario e Sonic. Outras franquias de plataforma incluem Donkey Kong, Crash Bandicoot, Prince of Persia, Castlevania e Mega Man.

História

Era de Single screen

Jogos de plataforma apareceram primeiramente no início da década de 1980, quando vários gêneros de video game estavam apenas começando a tomar forma. Por causa das limitações técnicas da época, os primeiros exemplos eram limitados à campos de jogo estáticos, geralmente vistos de perfil. Embora os jogos de plataforma ofereciam um novo tipo de jogabilidade, eles ainda pegavam muitas coisas de jogos anteriores. Frogs, um jogo de arcade lançado pela Gremlin em 1978, foi o primeiro jogo a ter um personagem que pulava, fazendo dele um dos primeiros antecessores do gênero.

Space Panic, lançado em 1980 para arcade, é por vezes creditado como um dos primeiros jogos de plataforma,1 mas isso não é consenso, já que o jogador não tinha a habilidade de pular, nadar, balançar-se, ou cair, e como tal, não satisfaz a maior parte da definição moderna do gênero. Entretanto, ele foi claramente uma influência para o gênero, com a jogabilidade centrada em subir as escadas entre diferentes níveis, um elemento comum em muitos dos primeiros jogos de plataforma.

Donkey Kong, um jogo de arcade criado pela Nintendo, lançado em julho de 1981, foi o primeiro jogo que permitia aos jogadores pular sobre obstáculos e buracos, tornando-o o primeiro jogo verdadeiramente de plataforma.2 Donkey Kong tinha uma quantidade limitada de plataforma nas duas primeiras telas, mas nas outras duas o componente de pulo das plataformas estava mais acentuada. O jogo também introduziu Mario, um ícone do gênero. Donkey Kong foi lançado para vários consoles e computadores da época, e o jogo ajudou a definir a posição da Nintendo como um importante nome internacional para a indústria de video games.

O quarto jogo da série foi Mario Bros, um jogo de plataforma que oferecia um jogo cooperativo para dois jogadores simultâneos. O título inspirou outros jogos populares de plataforma com cooperação entre dois jogadores, como Fairyland Story e Bubble Bobble, que, por sua vez, influenciou muitos dos jogos de plataforma de uma tela que seriam criados.

Referências

↑ Crawford, Chris. Chris Crawford on Game Design. [S.l.]: New Riders, 2003. ISBN 0-88134-117-7
↑ Donkey Kong. Arcade History (2006-11-21). Página visitada em 2006-11-21.

Biblioteca (computação)




Ilustração de uma aplicação que pode utilizar libvorbisfile.so para reproduzir um arquivo Ogg Vorbis
Na ciência da computação, biblioteca é uma coleção de subprogramas utilizados no desenvolvimento de software. Bibliotecas contém código e dados auxiliares, que provém serviços a programas independentes, o que permite o compartilhamento e a alteração de código e dados de forma modular. Alguns executáveis são tanto programas independentes quanto bibliotecas, mas a maioria das bibliotecas não são executáveis. Executáveis e bibliotecas fazem referências mútuas conhecidas como ligações, tarefa tipicamente realizada por um ligador.

A maior parte dos sistemas operacionais modernos provê bibliotecas que implementam a maioria dos serviços do sistema, que transformaram em comodidades os serviços que uma aplicação moderna espera que sejam providos pelo sistema operacional. Assim sendo, a maior parte do código utilizado em aplicações modernas é fornecido por estas bibliotecas.

Índice

1 Visão geral
2 Bibliotecas tradicionais
3 Ligação dinâmica
3.1 Realocação
4 Localizando bibliotecas em tempo de execução
5 Carregamento dinâmico
6 Bibliotecas remotas
7 Bibliotecas compartilhadas
8 Bibliotecas objeto
9 Nomenclatura

Visão geral

Bibliotecas podem ser classificadas pela maneira como são compartilhadas, pela maneira como são ligadas e por quando são ligadas.

Bibliotecas tradicionais

Historicamente, as bibliotecas consistiam de um conjunto de rotinas que eram copiadas para uma aplicação-alvo pelo compilador ou ligador, produzindo uma aplicação executável independente, ou standalone. Os fabricantes de compiladores proviam bibliotecas-padrão (por exemplo, a biblioteca padrão do C), mas os programadores também podiam criar suas próprias bibliotecas para uso próprio ou distribuição.

Ligação dinâmica

Ligação dinâmica significa que os dados em uma biblioteca não são copiados para um novo executável ou biblioteca em tempo de compilação, mas permanecem a um arquivo separado no disco. O ligador realiza uma quantidade mínima de trabalho em tempo de compilação—ele apenas grava quais bibliotecas são necessárias para o executável em um índice. A maior parte do trabalho é feita quando a aplicação é carregada em memória ou durante a execução do processo. O código de ligação necessário é na verdade parte do sistema operacional subjacente. Na hora apropriada, o carregador do programa encontra as bibliotecas relevantes no disco e adiciona os dados relevantes da biblioteca no espaço de memória do processo.

Alguns sistemas operacionais são apenas capazes de ligar uma biblioteca em tempo de carregamento, antes que a execução do processo se inicie; outros podem ser capazes de esperar até depois do início da execução e apenas ligar a biblioteca quando ela for referenciada (ou seja, durante o tempo de execução). Este último é freqüentemente chamado de "carregamento atrasado". Em ambos os casos, a ligação é dita dinâmica.

Plugins são uma utilização comum de bibliotecas de ligação dinâmica, algo especialmente útil quando as bibliotecas podem ser substituídas por outras com interfaces similares, mas funcionalidades diferentes. Diz-se que um software possui uma "arquitetura de plugins" se ele utiliza bibliotecas para funcionalidades essenciais com a intenção de que elas possam ser substituídas. Note, entretanto, que o uso de bibliotecas de ligação dinâmica na arquitetura de uma aplicação não necessariamente significa que elas possam ser substituídas.

A ligação dinâmica foi originalmente desenvolvida no sistema operacional Multics, a partir de 1964. Ela também era uma característica do Michigan Terminal System, construído no final dos anos 1960.1 No Microsoft Windows, bibliotecas de ligação dinâmica são chamadas dynamic-link libraries.

Realocação

Uma sutileza com a qual o carregador de programas tem que lidar é que a localização real dos dados da biblioteca não é conhecida até que o executável e todas as bibliotecas a ele associadas sejam carregadas para a memória. Isto se deve ao fato de que as localizações de memória utilizadas dependerão de quais bibliotecas foram carregadas. Não é possível armazenar uma localização absoluta para os dados dentro do próprio executável, nem mesmo na biblioteca, uma vez que isto resultaria em conflitos entre diferentes bibliotecas. Isto é, se duas bibliotecas distintas alocassem espaços de memória iguais ou sobrepostos, seria impossível usar as duas no mesmo programa. Isto pode vir a mudar com a adoção de arquiteturas de 64-bits, pois elas oferecem endereços de memória virtual suficientes para garantir que cada biblioteca escrita receba sua faixa de endereços única.

Seria possível, em teoria, examinar o programa durante o tempo de carregamento e substituir cada referência a dados na biblioteca por ponteiros para as posições de memória apropriadas uma vez que todas as bibliotecas tivessem sido carregadas. Contudo, este método consumiria quantidades inaceitáveis de tempo ou memória. Em vez disso, a maioria dos sistemas de bibliotecas dinâmicas cria uma tabela de símbolos com endereços vazios no programa em tempo de compilação. Todas as referências ao código ou dados na biblioteca passam por esta tabela, chamada diretório de importação. Durante o tempo de carregamento esta tabela é modificada com a localização dos códigos e dados na biblioteca pelo carregador de programas. Este processo ainda é lento a ponto de comprometer a performance de programas que façam uso de outros programas a uma taxa muito alta, como é o caso de alguns shell scripts.

A biblioteca, por sua vez, contém uma tabela com todos os métodos que a compõem, conhecidos como pontos de entrada. Chamadas à biblioteca passam por esta tabela, procurando pela localização do código na memória e então os executando. Isto introduz uma sobrecarga na chamada de biblioteca, mas o atraso é, em geral, tão pequeno que pode ser negligenciado.

Localizando bibliotecas em tempo de execução

Ligadores e carregadores de programas dinâmicos variam amplamente em funcionalidade. Alguns dependem de caminhos explícitos armazenados no arquivo executável. Qualquer modificação no nome da biblioteca ou layout do sistema de arquivos causará falha nestes sistemas. Mais comumente, apenas um nome da biblioteca (e não do caminho) é armazenado no executável, e o sistema operacional provê um sistema para encontrar a biblioteca no disco, baseado em algum algoritmo.

A maioria de sistemas Unix-like possuem uma "busca de caminho" especificando o sistema de arquivos no qual procurar as bibliotecas dinâmicas. Em outros sistemas, o caminho padrão é especificado em um arquivo de configuração; em outros, é codificado no carregador de programas dinâmico. Alguns formatos de arquivos executáveis podem especificar diretórios adicionais nos quais procurar por bibliotecas de um programa em particular. Ele pode geralmente ser relido com uma variável de ambiente, embora ela esteja desabilitada para programas setuid e setgid, então o usuário não pode forçar tal programa a rodar código arbitrário. Desenvolvedores de bibliotecas são encorajados a colocar suas bibliotecas dinâmicas em locais no caminho de busca padrão. Por outro lado, isto pode tornar a instalação de novas bibliotecas problemática, e estes caminhos conhecidos rapidamente se tornarem padrão para um número crescente de arquivos de biblioteca, tornando o gerenciamento mais complexo.
O Windows verifica o Registro do Sistema para determinar o lugar próprio para achar uma DLL ActiveX, mas para outras DLL ele verifica o diretório de onde o programa foi carregado; o diretório corrente de trabalho (somente nas antigas versões de Windows); quaisquer diretórios selecionados pela chamada da funçãoSetDllDirectory(); os diretórios System32, System e Windows; e, finalmente, os diretórios especificados pela variável de ambiente PATH.2
O OpenStep usa um sistema mais flexível, coletando uma lista de bibliotecas de um número conhecido de localizações (similar ao conceito de PATH) quando o sistema se inicia. O deslocamento de alguma biblioteca não causa problemas, no entanto um tempo maior será necessário durante o primeiro início do sistema.
Uma das grandes desvantagens da ligação dinâmica é que os executáveis dependem de bibliotecas armazenadas separadamente para o correto funcionamento. Se uma biblioteca é apagada, movida, ou renomeada, ou ainda se uma versão incompatível de uma DLL é copiada para o lugar onde é procurada, o executável pode ter mal funcionamento ou mesmo falhar no carregamento; danificando arquivos vitais vitais usados por quase todos os executáveis do sistema (como a biblioteca Clibc.so nos sistemas Unix), tornando o sistema inoperável. No Windows isso é comumente chamado de DLL hell.

Carregamento dinâmico

O Carregamento dinâmico é um subconjunto da ligação dinâmica em que uma biblioteca ligada dinâmica é carregada ou descarregada do sistema em tempo de execução após requisição. A requisição pode ser feita implicitamente em tempo de compilação, ou explicitamente em tempo de execução. Requisições implícitas são feitas ao adicionar referências às bibliotecas a um arquivo objeto pelo ligador. Requisições explícitas são feitas pelas aplicações através do uso de uma API de ligação.

A maioria dos sistemas operacionais que suportam a ligação dinâmica também suportam o carregamento dinâmico através de uma API específica. Por exemplo, o Windows utiliza as funções da API LoadLibrary, LoadLibraryEx, FreeLibrary e GetProcAddress para DLL; incluindo a maioria dos UNIX e UNIX-like, sistemas baseados em POSIX usam dlopen, dlclose e dlsym.

Bibliotecas remotas

Outra solução para a questão das bibliotecas é utilizar executáveis completamente separados e chamá-los através de chamadas de procedimento remoto (RPC). Essa abordagem maximiza o reaproveitamento do sistema operacional: o código necessário para suportar a biblioteca é o mesmo usado para prover o suporte e a segurança da aplicação para os outros programas. Adicionalmente, esse sistema remoto não requer que a biblioteca esteja na mesma máquina do executável, as chamas podem ser transmitidas por uma rede.

A desvantagem é que cada chamada da biblioteca implica uma sobrecarga considerável. Entretanto, essa abordagem tornou-se popular em diversas áreas específicas, como sistemas cliente-servidor e servidores e aplicação como o Enterprise JavaBeans.

Bibliotecas compartilhadas

Além de poderem ser carregadas estaticamente ou dinamicamente, bibliotecas também são classificadas de acordo com como são compartilhadas pelos programas. Bibliotecas dinâmicas quase sempre fornecem alguma forma de compartilhamento, permitindo que sejam utilizadas por diferentes programas ao mesmo tempo. Por definição, bibliotecas estáticas não podem ser compartilhadas pois são ligadas individualemente a cada programa.

O termo biblioteca compartilhada é ambíguo, pois se refere a dois conceitos distintos. O primeiro é o compartilhamento de código localizado no disco por programas não relacionados. O segundo é o compartilhamento de código carregado na memória, quando dois programas executam a mesma página física da RAM, mapeada em diferentes espaços de endereçamento. O segundo caso possui algumas vantagens. Por exemplo, no sistema OpenStep as aplicações tinham geralmente um tamanho pequeno e eram carregadas instantaneamente; a vasta maioria do código estava localizada em bibliotecas já carregadas pelo sistema operacional. Mas existe um custo, pois o código compartilhado deve ser escrito para ser executado em um ambiente multitarefa, o que afeta o desempenho.

Na maioria dos sistemas operacionais modernos, o compartilhamento de bibliotecas pode ser do mesmo formato dos executáveis. Isso permite que o carregador de programas seja o mesmo para executáveis e bibliotecas, e que um executável seja usado como biblioteca dinâmica, se tiver uma tabela de símbolos. Formatos típicos de híbridos executável/DLL são ELF e Mach-O (Unix) e PE (Windows). No Windows o conceito vai além, pois mesmo recursos de sistema como fontes e ícones são adicionados a uma DLL.

Bibliotecas objeto

Apesar da ligação dinâmica ter sido desenvolvida na década de 1960, somente no final da década de 1980 a tecnologia atingiu o consumidor final. Durante a década de 1990 já estava disponível na maioria dos sistemas operacionais. Durante o mesmo período a programação orientada a objeto tornou-se cada vez mais significativa no desenvolvimento de software. POO em tempo de execução requer informações adicionais que bibliotecas tradicionais não fornecem. Além dos nomes e dos pontos de entrada da biblioteca, também requerem uma lista de objetos do qual dependem. Como no caso de uma herança, que separa partes de uma definição em diferentes pontos do código. Em um sistema verdadeiramente orientado a objeto, as bibliotecas podem não ser conhecidas em tempo de compilação.

Ainda no mesmo período outra área de desenvolvimento era o conceito de execução remota, em que um computador cliente executaria os serviços de um mainframe. O cliente manteria mensagens para a central a fim de receber pacotes de dados para apresentar. Chamadas de procedimento remoto já eram usadas para essas tarefas, ainda que não houvesse um sistema padrão para tal.

Os dois conceitos logo foram fundidos, produzindo um formato de biblioteca orientada a objeto que pudesse ser executado em qualquer local. Tais sistemas foram denominados bibliotecas objeto, ou objetos distribuídos se suportassem acesso remoto. A Component Object Model da Microsoft é exemplo desse tipo de biblioteca para uso local, e a DCOM para uso remoto.

Por um tempo bibliotecas objeto foram a sensação do mundo da programação, existindo esforços para criar sistemas que pudessem ser executados em diferentes plataformas. Exemplos incluem System Object Model (SOM/DSOM) da IBM, Distributed Objects Everywhere (DOE) da Sun Microsystems, Portable Distributed Objects (PDO) da NeXT, Component Object Model (COM/DCOM) da Microsoft, e diferentes sistemas baseados em CORBA. O que sucedeu foi que o conceito foi caindo em desuso, com exceção da COM da Microsoft e o PDO da NeXT (agora Apple Inc.).

Nomenclatura

GNU/Linux, Solaris e variantes BSD: os arquivoslibfoo.a elibfoo.so estão localizados em diretórios como/lib,/usr/lib ou/usr/local/lib. Os nomes dos arquivos sempre começam comlib e terminam com.a (arquivo, ligação estática) ou.so (objeto compartilhado, ligação dinâmica), opcionalmente com o número da versão interface, comlibfoo.so.2.
Mac OS X e superiores: o sistema herda as convenções de bibliotecas estáticas do BSD, e pode usar o estilo.so (mas com o sufixo.dylib).
Microsoft Windows: arquivos*.LIB são de ligação estática e arquivos*.DLL são de ligação dinâmica. Existem ainda usuos específicos de DLL, como por exemplo o*.OCX para bibliotecas de controle OCX. A versão da interface está codificada no arquivo, ou abstraída usando uma interface COM.
Referências

↑ "A History of MTS", Information Technology Digest, Vol. 5, No. 5
↑ About Dynamic Link Libraries, Microsoft Developer Network, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic-link_library_search_order.asp

Biblioteca (computação)


Ilustração de uma aplicação que pode utilizar libvorbisfile.so para reproduzir um arquivo Ogg Vorbis
Na ciência da computação, biblioteca é uma coleção de subprogramas utilizados no desenvolvimento de software. Bibliotecas contém código e dados auxiliares, que provém serviços a programas independentes, o que permite o compartilhamento e a alteração de código e dados de forma modular. Alguns executáveis são tanto programas independentes quanto bibliotecas, mas a maioria das bibliotecas não são executáveis. Executáveis e bibliotecas fazem referências mútuas conhecidas como ligações, tarefa tipicamente realizada por um ligador.

A maior parte dos sistemas operacionais modernos provê bibliotecas que implementam a maioria dos serviços do sistema, que transformaram em comodidades os serviços que uma aplicação moderna espera que sejam providos pelo sistema operacional. Assim sendo, a maior parte do código utilizado em aplicações modernas é fornecido por estas bibliotecas.

Índice

1 Visão geral
2 Bibliotecas tradicionais
3 Ligação dinâmica
3.1 Realocação
4 Localizando bibliotecas em tempo de execução
5 Carregamento dinâmico
6 Bibliotecas remotas
7 Bibliotecas compartilhadas
8 Bibliotecas objeto
9 Nomenclatura

Visão geral

Bibliotecas podem ser classificadas pela maneira como são compartilhadas, pela maneira como são ligadas e por quando são ligadas.

Bibliotecas tradicionais

Historicamente, as bibliotecas consistiam de um conjunto de rotinas que eram copiadas para uma aplicação-alvo pelo compilador ou ligador, produzindo uma aplicação executável independente, ou standalone. Os fabricantes de compiladores proviam bibliotecas-padrão (por exemplo, a biblioteca padrão do C), mas os programadores também podiam criar suas próprias bibliotecas para uso próprio ou distribuição.

Ligação dinâmica

Ligação dinâmica significa que os dados em uma biblioteca não são copiados para um novo executável ou biblioteca em tempo de compilação, mas permanecem a um arquivo separado no disco. O ligador realiza uma quantidade mínima de trabalho em tempo de compilação—ele apenas grava quais bibliotecas são necessárias para o executável em um índice. A maior parte do trabalho é feita quando a aplicação é carregada em memória ou durante a execução do processo. O código de ligação necessário é na verdade parte do sistema operacional subjacente. Na hora apropriada, o carregador do programa encontra as bibliotecas relevantes no disco e adiciona os dados relevantes da biblioteca no espaço de memória do processo.

Alguns sistemas operacionais são apenas capazes de ligar uma biblioteca em tempo de carregamento, antes que a execução do processo se inicie; outros podem ser capazes de esperar até depois do início da execução e apenas ligar a biblioteca quando ela for referenciada (ou seja, durante o tempo de execução). Este último é freqüentemente chamado de "carregamento atrasado". Em ambos os casos, a ligação é dita dinâmica.

Plugins são uma utilização comum de bibliotecas de ligação dinâmica, algo especialmente útil quando as bibliotecas podem ser substituídas por outras com interfaces similares, mas funcionalidades diferentes. Diz-se que um software possui uma "arquitetura de plugins" se ele utiliza bibliotecas para funcionalidades essenciais com a intenção de que elas possam ser substituídas. Note, entretanto, que o uso de bibliotecas de ligação dinâmica na arquitetura de uma aplicação não necessariamente significa que elas possam ser substituídas.

A ligação dinâmica foi originalmente desenvolvida no sistema operacional Multics, a partir de 1964. Ela também era uma característica do Michigan Terminal System, construído no final dos anos 1960.1 No Microsoft Windows, bibliotecas de ligação dinâmica são chamadas dynamic-link libraries.

Realocação

Uma sutileza com a qual o carregador de programas tem que lidar é que a localização real dos dados da biblioteca não é conhecida até que o executável e todas as bibliotecas a ele associadas sejam carregadas para a memória. Isto se deve ao fato de que as localizações de memória utilizadas dependerão de quais bibliotecas foram carregadas. Não é possível armazenar uma localização absoluta para os dados dentro do próprio executável, nem mesmo na biblioteca, uma vez que isto resultaria em conflitos entre diferentes bibliotecas. Isto é, se duas bibliotecas distintas alocassem espaços de memória iguais ou sobrepostos, seria impossível usar as duas no mesmo programa. Isto pode vir a mudar com a adoção de arquiteturas de 64-bits, pois elas oferecem endereços de memória virtual suficientes para garantir que cada biblioteca escrita receba sua faixa de endereços única.

Seria possível, em teoria, examinar o programa durante o tempo de carregamento e substituir cada referência a dados na biblioteca por ponteiros para as posições de memória apropriadas uma vez que todas as bibliotecas tivessem sido carregadas. Contudo, este método consumiria quantidades inaceitáveis de tempo ou memória. Em vez disso, a maioria dos sistemas de bibliotecas dinâmicas cria uma tabela de símbolos com endereços vazios no programa em tempo de compilação. Todas as referências ao código ou dados na biblioteca passam por esta tabela, chamada diretório de importação. Durante o tempo de carregamento esta tabela é modificada com a localização dos códigos e dados na biblioteca pelo carregador de programas. Este processo ainda é lento a ponto de comprometer a performance de programas que façam uso de outros programas a uma taxa muito alta, como é o caso de alguns shell scripts.

A biblioteca, por sua vez, contém uma tabela com todos os métodos que a compõem, conhecidos como pontos de entrada. Chamadas à biblioteca passam por esta tabela, procurando pela localização do código na memória e então os executando. Isto introduz uma sobrecarga na chamada de biblioteca, mas o atraso é, em geral, tão pequeno que pode ser negligenciado.

Localizando bibliotecas em tempo de execução

Ligadores e carregadores de programas dinâmicos variam amplamente em funcionalidade. Alguns dependem de caminhos explícitos armazenados no arquivo executável. Qualquer modificação no nome da biblioteca ou layout do sistema de arquivos causará falha nestes sistemas. Mais comumente, apenas um nome da biblioteca (e não do caminho) é armazenado no executável, e o sistema operacional provê um sistema para encontrar a biblioteca no disco, baseado em algum algoritmo.

A maioria de sistemas Unix-like possuem uma "busca de caminho" especificando o sistema de arquivos no qual procurar as bibliotecas dinâmicas. Em outros sistemas, o caminho padrão é especificado em um arquivo de configuração; em outros, é codificado no carregador de programas dinâmico. Alguns formatos de arquivos executáveis podem especificar diretórios adicionais nos quais procurar por bibliotecas de um programa em particular. Ele pode geralmente ser relido com uma variável de ambiente, embora ela esteja desabilitada para programas setuid e setgid, então o usuário não pode forçar tal programa a rodar código arbitrário. Desenvolvedores de bibliotecas são encorajados a colocar suas bibliotecas dinâmicas em locais no caminho de busca padrão. Por outro lado, isto pode tornar a instalação de novas bibliotecas problemática, e estes caminhos conhecidos rapidamente se tornarem padrão para um número crescente de arquivos de biblioteca, tornando o gerenciamento mais complexo.
O Windows verifica o Registro do Sistema para determinar o lugar próprio para achar uma DLL ActiveX, mas para outras DLL ele verifica o diretório de onde o programa foi carregado; o diretório corrente de trabalho (somente nas antigas versões de Windows); quaisquer diretórios selecionados pela chamada da funçãoSetDllDirectory(); os diretórios System32, System e Windows; e, finalmente, os diretórios especificados pela variável de ambiente PATH.2
O OpenStep usa um sistema mais flexível, coletando uma lista de bibliotecas de um número conhecido de localizações (similar ao conceito de PATH) quando o sistema se inicia. O deslocamento de alguma biblioteca não causa problemas, no entanto um tempo maior será necessário durante o primeiro início do sistema.
Uma das grandes desvantagens da ligação dinâmica é que os executáveis dependem de bibliotecas armazenadas separadamente para o correto funcionamento. Se uma biblioteca é apagada, movida, ou renomeada, ou ainda se uma versão incompatível de uma DLL é copiada para o lugar onde é procurada, o executável pode ter mal funcionamento ou mesmo falhar no carregamento; danificando arquivos vitais vitais usados por quase todos os executáveis do sistema (como a biblioteca Clibc.so nos sistemas Unix), tornando o sistema inoperável. No Windows isso é comumente chamado de DLL hell.

Carregamento dinâmico

O Carregamento dinâmico é um subconjunto da ligação dinâmica em que uma biblioteca ligada dinâmica é carregada ou descarregada do sistema em tempo de execução após requisição. A requisição pode ser feita implicitamente em tempo de compilação, ou explicitamente em tempo de execução. Requisições implícitas são feitas ao adicionar referências às bibliotecas a um arquivo objeto pelo ligador. Requisições explícitas são feitas pelas aplicações através do uso de uma API de ligação.

A maioria dos sistemas operacionais que suportam a ligação dinâmica também suportam o carregamento dinâmico através de uma API específica. Por exemplo, o Windows utiliza as funções da API LoadLibrary, LoadLibraryEx, FreeLibrary e GetProcAddress para DLL; incluindo a maioria dos UNIX e UNIX-like, sistemas baseados em POSIX usam dlopen, dlclose e dlsym.

Bibliotecas remotas

Outra solução para a questão das bibliotecas é utilizar executáveis completamente separados e chamá-los através de chamadas de procedimento remoto (RPC). Essa abordagem maximiza o reaproveitamento do sistema operacional: o código necessário para suportar a biblioteca é o mesmo usado para prover o suporte e a segurança da aplicação para os outros programas. Adicionalmente, esse sistema remoto não requer que a biblioteca esteja na mesma máquina do executável, as chamas podem ser transmitidas por uma rede.

A desvantagem é que cada chamada da biblioteca implica uma sobrecarga considerável. Entretanto, essa abordagem tornou-se popular em diversas áreas específicas, como sistemas cliente-servidor e servidores e aplicação como o Enterprise JavaBeans.

Bibliotecas compartilhadas

Além de poderem ser carregadas estaticamente ou dinamicamente, bibliotecas também são classificadas de acordo com como são compartilhadas pelos programas. Bibliotecas dinâmicas quase sempre fornecem alguma forma de compartilhamento, permitindo que sejam utilizadas por diferentes programas ao mesmo tempo. Por definição, bibliotecas estáticas não podem ser compartilhadas pois são ligadas individualemente a cada programa.

O termo biblioteca compartilhada é ambíguo, pois se refere a dois conceitos distintos. O primeiro é o compartilhamento de código localizado no disco por programas não relacionados. O segundo é o compartilhamento de código carregado na memória, quando dois programas executam a mesma página física da RAM, mapeada em diferentes espaços de endereçamento. O segundo caso possui algumas vantagens. Por exemplo, no sistema OpenStep as aplicações tinham geralmente um tamanho pequeno e eram carregadas instantaneamente; a vasta maioria do código estava localizada em bibliotecas já carregadas pelo sistema operacional. Mas existe um custo, pois o código compartilhado deve ser escrito para ser executado em um ambiente multitarefa, o que afeta o desempenho.

Na maioria dos sistemas operacionais modernos, o compartilhamento de bibliotecas pode ser do mesmo formato dos executáveis. Isso permite que o carregador de programas seja o mesmo para executáveis e bibliotecas, e que um executável seja usado como biblioteca dinâmica, se tiver uma tabela de símbolos. Formatos típicos de híbridos executável/DLL são ELF e Mach-O (Unix) e PE (Windows). No Windows o conceito vai além, pois mesmo recursos de sistema como fontes e ícones são adicionados a uma DLL.

Bibliotecas objeto

Apesar da ligação dinâmica ter sido desenvolvida na década de 1960, somente no final da década de 1980 a tecnologia atingiu o consumidor final. Durante a década de 1990 já estava disponível na maioria dos sistemas operacionais. Durante o mesmo período a programação orientada a objeto tornou-se cada vez mais significativa no desenvolvimento de software. POO em tempo de execução requer informações adicionais que bibliotecas tradicionais não fornecem. Além dos nomes e dos pontos de entrada da biblioteca, também requerem uma lista de objetos do qual dependem. Como no caso de uma herança, que separa partes de uma definição em diferentes pontos do código. Em um sistema verdadeiramente orientado a objeto, as bibliotecas podem não ser conhecidas em tempo de compilação.

Ainda no mesmo período outra área de desenvolvimento era o conceito de execução remota, em que um computador cliente executaria os serviços de um mainframe. O cliente manteria mensagens para a central a fim de receber pacotes de dados para apresentar. Chamadas de procedimento remoto já eram usadas para essas tarefas, ainda que não houvesse um sistema padrão para tal.

Os dois conceitos logo foram fundidos, produzindo um formato de biblioteca orientada a objeto que pudesse ser executado em qualquer local. Tais sistemas foram denominados bibliotecas objeto, ou objetos distribuídos se suportassem acesso remoto. A Component Object Model da Microsoft é exemplo desse tipo de biblioteca para uso local, e a DCOM para uso remoto.

Por um tempo bibliotecas objeto foram a sensação do mundo da programação, existindo esforços para criar sistemas que pudessem ser executados em diferentes plataformas. Exemplos incluem System Object Model (SOM/DSOM) da IBM, Distributed Objects Everywhere (DOE) da Sun Microsystems, Portable Distributed Objects (PDO) da NeXT, Component Object Model (COM/DCOM) da Microsoft, e diferentes sistemas baseados em CORBA. O que sucedeu foi que o conceito foi caindo em desuso, com exceção da COM da Microsoft e o PDO da NeXT (agora Apple Inc.).

Nomenclatura

GNU/Linux, Solaris e variantes BSD: os arquivoslibfoo.a elibfoo.so estão localizados em diretórios como/lib,/usr/lib ou/usr/local/lib. Os nomes dos arquivos sempre começam comlib e terminam com.a (arquivo, ligação estática) ou.so (objeto compartilhado, ligação dinâmica), opcionalmente com o número da versão interface, comlibfoo.so.2.
Mac OS X e superiores: o sistema herda as convenções de bibliotecas estáticas do BSD, e pode usar o estilo.so (mas com o sufixo.dylib).
Microsoft Windows: arquivos*.LIB são de ligação estática e arquivos*.DLL são de ligação dinâmica. Existem ainda usuos específicos de DLL, como por exemplo o*.OCX para bibliotecas de controle OCX. A versão da interface está codificada no arquivo, ou abstraída usando uma interface COM.
Referências

↑ "A History of MTS", Information Technology Digest, Vol. 5, No. 5
↑ About Dynamic Link Libraries, Microsoft Developer Network, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic-link_library_search_order.asp

Ferramenta CASE




Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma classificação que abrange todas ferramentas baseadas em computadores que auxiliam atividades de engenharia de software, desde análise de requisitos e modelagem até programação e testes. Podem ser consideradas como ferramentas automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de software.

Índice

1 Categorização
2 Classificação por funcionalidade
3 Objetivos
4 Vantagens do uso de ferramentas CASE
5 Desvantagens do uso de ferramentas CASE
6 Requisitos de ferramentas CASE
7 Seleção e avaliação de ferramentas CASE
7.1 Avaliação
7.2 Seleção
8 Norma ISO/IEC 14102

Categorização

Não há um padrão definido para a categorização das CASE, no entanto os termos abaixo são os que melhor o identificam.

Front End ou Upper CASE: apóia as etapas iniciais de criação dos sistemas: as fases de planejamento, análise e projeto do programa ou aplicação.
Back End ou Lower CASE: dão apoio à parte física, isto é, a codificação testes e manutenção da aplicação.
I-CASE ou Integrated CASE: classifica os produtos que cobrem todo o ciclo de vida do software, desde os requisitos do sistema até o controle final da qualidade.
Os ambientes de desenvolvimento integrado (IDEs) têm maior destaque e suportam:

Editor
Compilador
Debug
Geração de código
Ferramentas de modelagem
Deploy
Testes automatizados Yrla
Refatoração
Classificação por funcionalidade

Controle de Versão
CVS, Subversion, Git, Mercurial, Bazaar, Rational Clearcase, entre outros.
Gerência de projetos
Microsoft Project, dotProject, Xplanner, Google Code
Edição
Microsoft Word, JBuilder, Wiki, Open Office, Eclipse, NetBeans, Rational Rose, Astah Community, ArgoUML, Star UML
Ferramentas de prototipagem
Adobe PageMaker, NetBeans, JBuilder, Delphi, Visual Basic
Suporte a programação
Compiladores - JDK
Banco de Dados – Oracle, MySQL, Postgres
Teste - JUnit
Automação de tarefas - Apache Ant, Apache Maven
Análise de programas
Analisadores estáticos - HPROF
Teste
JUnit, cunit (unitários)
Depuração
Sistemas interativos de depuração
Geração de código
Transformica, Unitech CodeFSW, JEE Spider
Documentação
Editores de texto (Ex: Microsoft Word, OpenOffice)
Geradores de documentos (Ex: Javadoc)
Editores de texto colaborativo (Ex: wiki)
Reengenharia
Sistemas de reestruturação de programas
Ferramentas Integradas
Agrupam diversas funcionalidades
Ferramentas de Métricas
Costar, USC-COCOMO, Calico
Ferramentas de Planejamento
Foundation
Objetivos

Melhoria da qualidade de software
Aumento da produtividade no processo de software
Vantagens do uso de ferramentas CASE

Qualidade no produto final
Produtividade
Agilizar o tempo para tomada de decisão
Menor quantidade de códigos de programação
Melhoria e redução de custos na manutenção
Agilidade no retrabalho do software
Maior facilidade para desenvolvimento
Desvantagens do uso de ferramentas CASE

Incompatibilidade de ferramentas
Treinamento para utilização
Requisitos de ferramentas CASE

A captura dos requisitos do sistema verifica os usuários de ferramentas CASE, que são os desenvolvedores. Os membros de equipes de marketing também auxiliam no processo, pelo fato de se tratar de um produto dirigido ao mercado. Onde o processo da fase de requisitos faz uma análise do mercado, analisa a documentação de ferramentas similares que já existem, faz-se testes sobre as ferramentas que já estão no mercado, e se elabora questionários (respondidos pelos desenvolvedores e pelo pessoal de marketing).

Seleção e avaliação de ferramentas CASE

Avaliação

Processos nos quais vários aspectos de uma ferramenta CASE são medidos, considerando-se critérios definidos. Os resultados são armazenados para uso posterior. Avaliar ferramentas CASE é muito mais que simplesmente comparar preços e condições de pagamento. Se não há familiaridade com nenhuma é preciso definir e estudar essa metodologia antes mesmo de comprar ferramentas.
Uma forma bastante comum para o processo de avaliação é a utilização de questionários que buscam abranger todas as características de ferramentas CASE.

Seleção

Processo nos quais os dados de uma ou mais avaliações de ferramentas são ponderados e comparados, considerando-se critérios definidos, para determinar se uma ou mais ferramentas podem ser recomendadas para a adoção. A proposta do processo de seleção é identificar a ferramenta CASE mais adequada entre as candidatas e certificar-se que a ferramenta recomendada atende aos requisitos originais dos usuários. Pode iniciar quando os relatórios de avaliação estiverem concluídos. Um algoritmo de seleção deve ser definido e aplicado aos resultados da avaliação.

Norma ISO/IEC 14102

Esta norma trata da seleção e avaliação de ferramentas CASE, e cobre parcial ou todo o ciclo de vida da engenharia de software. Estabelece processos e atividades a serem aplicadas na avaliação de ferramentas e na seleção da ferramenta mais apropriada dentre diversas candidatas. Estes processos são genéricos e as organizações devem adaptá-los de acordo com suas necessidades.


Referências

WEINRICH, Jair e GRAHL, Everaldo, Software de apoio a avaliação e seleção de ferramentas case baseado na norma ISO/IEC 14102, Artigo SEMINCO 1999 FURB-Universidade Regional de Blumenau
SILVA, Manoel e ROCHA, Thayssa, PROJETO DE UMA FERRAMENTA CASE UTILIZANDO A NOTAÇÃO DA UML E A METODOLOGIA DE COAD & YOURDON, 1998, CESUPA Belém do Pará.

Ferramenta CASE


Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma classificação que abrange todas ferramentas baseadas em computadores que auxiliam atividades de engenharia de software, desde análise de requisitos e modelagem até programação e testes. Podem ser consideradas como ferramentas automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de software.

Índice

1 Categorização
2 Classificação por funcionalidade
3 Objetivos
4 Vantagens do uso de ferramentas CASE
5 Desvantagens do uso de ferramentas CASE
6 Requisitos de ferramentas CASE
7 Seleção e avaliação de ferramentas CASE
7.1 Avaliação
7.2 Seleção
8 Norma ISO/IEC 14102

Categorização

Não há um padrão definido para a categorização das CASE, no entanto os termos abaixo são os que melhor o identificam.

Front End ou Upper CASE: apóia as etapas iniciais de criação dos sistemas: as fases de planejamento, análise e projeto do programa ou aplicação.
Back End ou Lower CASE: dão apoio à parte física, isto é, a codificação testes e manutenção da aplicação.
I-CASE ou Integrated CASE: classifica os produtos que cobrem todo o ciclo de vida do software, desde os requisitos do sistema até o controle final da qualidade.
Os ambientes de desenvolvimento integrado (IDEs) têm maior destaque e suportam:

Editor
Compilador
Debug
Geração de código
Ferramentas de modelagem
Deploy
Testes automatizados Yrla
Refatoração
Classificação por funcionalidade

Controle de Versão
CVS, Subversion, Git, Mercurial, Bazaar, Rational Clearcase, entre outros.
Gerência de projetos
Microsoft Project, dotProject, Xplanner, Google Code
Edição
Microsoft Word, JBuilder, Wiki, Open Office, Eclipse, NetBeans, Rational Rose, Astah Community, ArgoUML, Star UML
Ferramentas de prototipagem
Adobe PageMaker, NetBeans, JBuilder, Delphi, Visual Basic
Suporte a programação
Compiladores - JDK
Banco de Dados – Oracle, MySQL, Postgres
Teste - JUnit
Automação de tarefas - Apache Ant, Apache Maven
Análise de programas
Analisadores estáticos - HPROF
Teste
JUnit, cunit (unitários)
Depuração
Sistemas interativos de depuração
Geração de código
Transformica, Unitech CodeFSW, JEE Spider
Documentação
Editores de texto (Ex: Microsoft Word, OpenOffice)
Geradores de documentos (Ex: Javadoc)
Editores de texto colaborativo (Ex: wiki)
Reengenharia
Sistemas de reestruturação de programas
Ferramentas Integradas
Agrupam diversas funcionalidades
Ferramentas de Métricas
Costar, USC-COCOMO, Calico
Ferramentas de Planejamento
Foundation
Objetivos

Melhoria da qualidade de software
Aumento da produtividade no processo de software
Vantagens do uso de ferramentas CASE

Qualidade no produto final
Produtividade
Agilizar o tempo para tomada de decisão
Menor quantidade de códigos de programação
Melhoria e redução de custos na manutenção
Agilidade no retrabalho do software
Maior facilidade para desenvolvimento
Desvantagens do uso de ferramentas CASE

Incompatibilidade de ferramentas
Treinamento para utilização
Requisitos de ferramentas CASE

A captura dos requisitos do sistema verifica os usuários de ferramentas CASE, que são os desenvolvedores. Os membros de equipes de marketing também auxiliam no processo, pelo fato de se tratar de um produto dirigido ao mercado. Onde o processo da fase de requisitos faz uma análise do mercado, analisa a documentação de ferramentas similares que já existem, faz-se testes sobre as ferramentas que já estão no mercado, e se elabora questionários (respondidos pelos desenvolvedores e pelo pessoal de marketing).

Seleção e avaliação de ferramentas CASE

Avaliação

Processos nos quais vários aspectos de uma ferramenta CASE são medidos, considerando-se critérios definidos. Os resultados são armazenados para uso posterior. Avaliar ferramentas CASE é muito mais que simplesmente comparar preços e condições de pagamento. Se não há familiaridade com nenhuma é preciso definir e estudar essa metodologia antes mesmo de comprar ferramentas.
Uma forma bastante comum para o processo de avaliação é a utilização de questionários que buscam abranger todas as características de ferramentas CASE.

Seleção

Processo nos quais os dados de uma ou mais avaliações de ferramentas são ponderados e comparados, considerando-se critérios definidos, para determinar se uma ou mais ferramentas podem ser recomendadas para a adoção. A proposta do processo de seleção é identificar a ferramenta CASE mais adequada entre as candidatas e certificar-se que a ferramenta recomendada atende aos requisitos originais dos usuários. Pode iniciar quando os relatórios de avaliação estiverem concluídos. Um algoritmo de seleção deve ser definido e aplicado aos resultados da avaliação.

Norma ISO/IEC 14102

Esta norma trata da seleção e avaliação de ferramentas CASE, e cobre parcial ou todo o ciclo de vida da engenharia de software. Estabelece processos e atividades a serem aplicadas na avaliação de ferramentas e na seleção da ferramenta mais apropriada dentre diversas candidatas. Estes processos são genéricos e as organizações devem adaptá-los de acordo com suas necessidades.


Referências

WEINRICH, Jair e GRAHL, Everaldo, Software de apoio a avaliação e seleção de ferramentas case baseado na norma ISO/IEC 14102, Artigo SEMINCO 1999 FURB-Universidade Regional de Blumenau
SILVA, Manoel e ROCHA, Thayssa, PROJETO DE UMA FERRAMENTA CASE UTILIZANDO A NOTAÇÃO DA UML E A METODOLOGIA DE COAD & YOURDON, 1998, CESUPA Belém do Pará.

Banco de dados





Bancos de dados (português brasileiro) ou bases de dados (português europeu) são coleções de informações que se relacionam de forma que crie um sentido.1 2 3 São de vital importância para empresas, e há duas décadas se tornaram a principal peça dos sistemas de informação.4 2 5 Normalmente existem por vários anos sem alterações em sua estrutura.6 7

São operados pelos Sistemas Gerenciadores de Bancos de Dados (SGBD), que surgiram na década de 70.8 9 Antes destes, as aplicações usavam sistemas de arquivos do sistema operacional para armazenar suas informações.10 9 Na década de 80 a tecnologia de SGBD relacional passou a dominar o mercado, e atualmente utiliza-se praticamente apenas ele.8 9 Outro tipo notável é o SGBD Orientado a Objetos, para quando sua estrutura ou as aplicações que o utilizam mudam constantemente.6

A principal aplicação de Banco de Dados é controle de operações empresariais.4 5 11 Outra aplicação também importante é gerenciamento de informações de estudos, como fazem os Bancos de Dados Geográficos, que unem informações convencionais com espaciais.1

Índice

1 Modelos de base de dados
2 Aplicações de bancos de dados
3 Transação
4 Controle de Concorrência
5 Segurança em banco de dados
6 Recuperação de bancos de dados
7 Funções internas comuns em BDs

Modelos de base de dados

O modelo plano (ou tabular) consiste de matrizes simples, bidimensionais, compostas por elementos de dados: inteiros, números 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.

Bases de dados relacionais consistem, principalmente de três componentes: uma coleção de estruturas de dados, nomeadamente relações, ou informalmente tabelas; uma coleção dos operadores, a álgebra e o cálculo relacionais; e 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 de quatro tipos: domínio (também conhecidas como type), atributo, relvar (variável relacional) e restrições de base de dados.

Assim bem diferente dos modelos hierárquico e de rede, não existem quaisquer apontadores, de acordo com o Princípio de Informação: toda informação tem de ser representada como dados; qualquer tipo de atributo representa relações entre conjuntos de dados. 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.

O modelo relacional é uma teoria matemática desenvolvida por Edgar Frank Codd para descrever como as bases de dados devem funcionar. Embora esta teoria seja a base para o software de bases de dados relacionais, muito poucos sistemas de gestão de bases de dados seguem o modelo de forma restrita ou a pé da letra - lembre-se das 12 leis do modelo relacional - e todos têm funcionalidades que violam a teoria, desta forma variando a complexidade e o poder. A discussão se esses bancos de dados merecem ser chamados de relacional ficou esgotada com o tempo, com a evolução dos bancos existentes. Os bancos de dados hoje implementam o modelo definido como objeto-relacional.

Aplicações de bancos de dados

Sistemas Gerenciadores de Bancos de dados são usados em muitas aplicações, enquanto atravessando virtualmente a gama inteira de software de computador. Os Sistemas Gerenciadores de Bancos de dados são o método preferido de armazenamento/recuperação de dados/informações para aplicações multi-usuárias grandes onde a coordenação entre muitos usuários é necessária. Até mesmo usuários individuais os acham conveniente, entretanto, muitos programas de correio eletrônico e organizadores pessoais estão baseados em tecnologia de banco de dados standard.

Transação

É um 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. Se durante a transação qualquer ação que constitui unidade de trabalho falhar, a transação inteira deve ser desfeita (rollback). Quando todas as ações são efetuadas com sucesso, a transação pode ser efetivada e persistida em banco (commit).
Consistência
Todas as regras e restrições definidas no banco de dados devem ser obedecidas. Relacionamentos por chaves estrangeiras, checagem de valores para campos restritos ou únicos devem ser obedecidos para que uma transação possa ser completada com sucesso.
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, possa 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 (ainda em respeito à propriedade da atomicidade).
Durabilidade
Significa que os resultados de uma transação são permanentes e podem ser desfeitos somente por uma transação subseqüente.Por exemplo: todos os dados e status relativos a uma transação devem ser armazenados num repositório permanente, não sendo passíveis de falha por uma falha de hardware.
Na prática, alguns SGBDs relaxam na implementação destas propriedades buscando desempenho.

Controle de Concorrência

Controle de concorrência é um método usado para garantir que as transações sejam executadas de uma forma segura e sigam 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. Requeremos, portanto, que qualquer escalonamento produzido ao se processar um conjunto de transações concorrentemente seja computacionalmente equivalente a um escalonamento produzido executando essas transações serialmente em alguma ordem. Diz-se que um sistema que garante esta propriedade assegura a seriabilidade ou também serialização12 .

Segurança em banco de dados

Os bancos de dados são utilizados para armazenar diversos tipos de informações, desde dados sobre uma conta de e-mail até dados importantes da Receita Federal. A segurança do banco de dados herda as mesmas dificuldades que a segurança da informação enfrenta, que é garantir a integridade, a disponibilidade e a confidencialidade. Um Sistema gerenciador de banco de dados deve fornecer mecanismos que auxiliem nesta tarefa.

Uma forma comum de ataque à segurança do banco de dados, é a injeção de SQL, em bancos de dados que façam uso desta linguagem, mas bancos de dados NoSQL também podem ser vítimas. Para evitar estes ataques, o desenvolvedor de aplicações deve garantir que nenhuma entrada possa alterar a estrutura da consulta enviada ao sistema.

Os bancos de dados SQL implementam mecanismos que restringem ou permitem acessos aos dados de acordo com papeis ou roles fornecidos pelo administrador. O comando GRANT concede privilégios específicos para um objeto (tabela, visão, hu3Hu3, banco de dados, função, linguagem procedural, esquema ou espaço de tabelas) para um ou mais usuários ou grupos de usuários.13

Recuperação de bancos de dados

Existem alguns mecanismos capazes de permitir a recuperação de um banco de dados de alguma inconsistência causada por falhas internas (erros de consistência, como recuperação de um estado anterior à uma transação que deu erro) e externas (queda de energia, catástrofe ambiental).12 .

Os mecanismos mais comuns são o Log de dados, no qual é usado em conjunto dos outros métodos; utilização de Buffer no qual, apesar de normalmente ser feito pelo próprio sistema operacional, é controle por rotinas de baixo nível pelo Sistema de gerenciamento de banco de dados. Possui também o as possibilidades de en:Write-ahead logging e informações das transações possibilitando o REDO (refazer) e o UNDO (desfazer), assim sempre possibilitando a volta do banco de dados à um estado anterior consistente, além de cópias de sombra dos logs e dos últimos dados alterados do banco de dados.

Funções internas comuns em BDs

Tabelas
Regras
Procedimentos armazenados (mais conhecidos como stored procedures)
Gatilho
Default
Visão
Índice
Generalizadores