Paradox X InterBase

A primeira vista, as tabelas Paradox não apresentam muitas diferenças das tabelas criadas
no InterBase e as seguintes semelhanças são evidentes:
· o acesso pode ser feito através de um Alias;
· os tipos dos campos possíveis são similares, apesar de possuirem nomes diferentes;
· as tabelas podem ser criadas com o DataBase Desktop;
· são utilizados os mesmos componentes TTable e TQuery para acesso;
Na realidade, o BDE (Borland DataBase Engine) cria uma ilusão de que tabelas InterBase e
Paradox comportam-se da mesma maneira.
Para alguns desenvolvedores, entretanto esta ilusão termina logo. A primeira decepção vem
com a utilização do Database Desktop para manipulação de tabelas InterBase. Enquanto o
Database Desktop é a ferramenta ideal para criação e reestruturação de tabelas Paradox, é
deficiente com relação ao Interbase, onde a restruturação e a utilização de características mais
avançadas só podem ser alcançadas através da montagem de scripts que serão executados no
Interbase Windows ISQL.
As pesquisas e índices no InterBase diferenciam maiúsculas e minúsculas, enquanto que no
Paradox esta diferenciação é configurável. Ainda no InterBase a definição de chaves primárias e
estrangeiras é realizada facilmente, porém a alteração destas chaves não é tão trivial. Algumas
operações utilizando o InterBase são mais lentas do que no Paradox. Torna-se rapidamente claro
que o InterBase não é automaticamente melhor que o Paradox.
A idéia de que o InterBase não é sempre mais adequado do que o Paradox é verídica.Os
dois produtos apresentam diferenças significativas e a escolha de qual utilizar é plenamente
dependente das condições e dos objetivos do aplicativo final. Na realidade, a única coisa que eles
tem em comum é que ambos armazenam dados em tabelas. Cada um possui pontos fortes e fracos
dependendo da realidade a ser trabalhada. O importante é decidir qual deles é apropriado para uma
situação particular. A decisão tomada, usar Paradox ou InterBase, afetará de forma significativa o
desenvolvimento do seu projeto.
Paradox: Baseado em Arquivos
O Paradox é um sistema de banco de dados baseado em arquivos. Os arquivos de dados
contêm registros de dados que possuem uma ordem fixa. Em outras palavras, o registro de número
106 será sempre o mesmo registro, até que seja movido fisicamente dentro do arquivo, através de
uma operação de ordenação, por exemplo. O que é mais importante, ele será sempre o sucessor do
registro 105 e o antecessor do 107, até que esta ordem seja explicitamente alterada. Isto permite
uma fácil navegação entre os registros, através do cursor, já que é possível localizar um registro em
uma tabela através da sua posição, sem necessidade de referenciar seu conteúdo.
Esta ordenação explícita de registros em uma tabela, apresenta algumas vantagens: a
movimentação para o início ou para o final de um arquivo de dados é simples e os registros podem
ser facilmente relidos quando um cursor é posicionado sobre eles. A concepção de navegação
(browsing) pode ser conveniente para usuários e desenvolvedores. Isto permite que os registros
sejam manipulados um de cada vez e em uma ordem previsível. Este comportamento de navegação
nas tabelas Paradox é uma das características mais difíceis de serem adaptadas ao sistema
InterBase, e muitos desenvolvedores em InterBase têm grandes problemas em efetuar esta
transição.
2
InterBase: Baseado em Conjuntos
O InterBase é na realidade um sistema de banco de bados relacional. As tabelas não são
armazenadas em arquivos individuais e o que é mais interessante: os registros não encontram-se
ordenados. Matematicamente falando, os conjuntos são desordenados. A ordem é “descoberta”
somente quando o conjunto for representado, como por exemplo em uma consulta ao banco de
dados. Você não pode contar duas vezes com o fato de o mesmo registro ser o registro número 105,
a menos que explicitamente seja imposta uma certa ordenação na consulta. Uma vez que não
podemos identificar positivamente um registro pela sua posição dentro de uma tabela devemos nos
referir a valores internos a este registro. Entretanto, para identificações positivas de um registro,
pelo menos um campo ou a combinação de alguns campos devem conter um valor único para cada
registro, o que é conhecido por Chave Primária.
É possível que mais de um campo ou combinações de campos possam fornecer valores
únicos. Estes campos – ou combinações – são denominados Chaves Candidatas. É imprescindível
para o gerenciamento de um sistema de banco de dados a identificação de Chaves Primárias. Uma
tabela que possui uma Chave Primária é chamada de R-table e todos os Data Sets (tables, query e
stored-procedures) devem ser R-tables para que o modelo relacional possa funcionar corretamente.
A vantagem deste conceito de dados baseado em conjunto é que os conjuntos e as
operações neles realizadas possuem a propriedade de “encapsulamento”. Isto significa que quando
realizamos operações em um conjunto sempre geraremos um outro conjunto, que poderá, então, ter
uma nova operação com ele realizada, produzindo um novo conjunto, e assim suscessivamente.
Este é um poderoso conceito lógico que, se corretamente implementado, tornará o desenvolvimento
de aplicações independente das características físicas de armazenamento. Esta é a base dos modelos
relacionais.
Os sistemas “baseados em cursor” (cursor-based) como o Paradox permitem que você
trabalhe somente com um registro de cada vez. Sistemas “baseados em conjuntos” (set-based)
permitem a manipulação de conjuntos de dados como se fossem uma entidade única. Esta
característica permite a simplificação do desenvolvimento de aplicações, além de melhor garantir a
integridade dos dados.
Projetos Físicos e os Impactos de Velocidade
O Paradox é um sistema-cliente no qual os dados são completamente manipulados por
clientes individuais. Quando você quiser que os dados sejam lidos ou manipulados, eles devem ser
transportados para a aplicação. Cada aplicação manipula todo o processamento por si só. Se
múltiplos usuários estiverem acessando a tabela simultaneamente sobre uma rede, cada aplicação
usuária transporta os dados requeridos para a máquina usuária.
Cada instância de aplicação Paradox não tem retorno de outra. Se uma instância precisa
garantir a estabilidade dos dados por alguma razão, ela deve proibir outras instâncias de alterarem
os dados através de um esquema de travamento (locking scheme).
Quando, em uma aplicação Paradox, precisamos procurar em uma tabela, a seguinte rotina
será efetuada: (1) os dados brutos e índices necessários devem ser carregados na memória da
máquina cliente; (2) a atividade física da procura é conduzida; (3) os resultados são gerados; e (4)
os dados tornados desnecessários após a operação são então descartados. Esta rotina é repetida para
cada operação sobre cada cliente. O servidor de arquivos que contem os arquivos de dados não faz
nada além de enviar os dados brutos requeridos, através da rede, para as máquinas clientes, sem
realizar quaisquer esforços de processamento dos dados. Funciona, assim, como um disco rígido
remoto.
Em suma, o Paradox é veloz em um disco rígido local mas a sua performance diminui
drasticamente em uma rede. A rede fica sobrecarregada, com um grande volume de processamentos
3
sendo realizados repetidamente na máquina cliente. Mesmo em uma rede pequena a performance é
rapidamente afetada quando um novo usuário é conectado.
O InterBase é um sistema “baseado em servidores” (server based). Em vez de diferentes
processos manipulando fisicamente os dados armazenados, somente um processo central,
“rodando” na máquina servidora, possui acesso direto aos dados. Todas as aplicações clientes
desenvolvem políticas de requerimento ao processo servidor, o qual é processado diretamente na
máquina servidora enquanto o cliente aguarda.
Quando o servidor termina ele transmite apenas os resultados de volta ao cliente, que
retoma então suas atividades. O impacto mais direto deste esquema é que a rede não necessita ficar
congestionada com grandes volumes de dados redundantes sendo enviados pelos clientes. Alem
disso, as tarefas frequentemente complexas de processamento de dados podem ser delegadas de
máquinas clientes, normalmente menos poderosas, para as normalmente mais poderosas máquinas
servidoras.
Deve-se perceber que tudo sobre o desenvolvimento em InterBase implica em um ambiente
multi-usuário. O InterBase foi desenvolvido desde o princícpio como um sistema multi-usuário. O
Paradox, por outro lado, foi basicamente desenvolvido para um único usuário, sendo que
características que visavam permitir o atendimento a múltiplos usuários foram depois sendo
adicionadas.
InterBase Não é Para Navegação
Conforme foi mencionado anteriormente o InterBase constitui-se em um verdadeiro
RDBMS (Sistema Relacional de Gerenciamento de Banco de Dados) mas a performance de
algumas operações são realmente mais lentas do que em tabelas Paradox. Esta questão torna-se
evidente quando temos uma tabela com uma quantidade muito grande de registros. Se você utilizar
o método Last com o objetivo de mover o ponteiro para o último registro da tabela certamente
perceberá uma grande diferença na performance dos dois sistemas. Portanto, para estas operações,
a utilização de tabelas Paradox torna a aplicação mais veloz do que em tabelas InterBase.Em
tabelas Paradox o índice aponta para um endereço físico onde se encontra o registro.
O cursor na tabela Paradox moverá quase que instantaneamente para a posição determinada
porque ele conhece a localização física (endereço) deste registro na tabela. Esta operação na tabela
InterBase poderá apresentar alguns problemas. Primeiro porque os dados encontram-se
desordenados e existe uma questão sobre o que constitui o “Último”. A operação deve impor uma
ordem antes de decidir qual registro é o último. Por default o último registro será considerado
aquele registro cuja Chave Primária possui o maior valor.
Portanto, é necessário determinar o valor da maior Chave Primária. Uma vez que este valor
foi determinado o registro que possui este valor pode ser recuperado. Se for necessário recuperar os
últimos registros (como no caso da apresentação dos dados em um grid) o processo deve ser
repetido algumas vezes, tornando-se um pouco complicado. Para recuperar o penúltimo registro, o
InterBase deve agora encontrar o maior valor da chave primária que seja inferior ao valor máximo
desta. Para o antepenúltimo registro, ele deve procurar o valor mais próximo ao mais próximo do
valor máximo da chave primária, e assim consecutivamente, até o número necessário de registros
ser recuperado. Uma operação que é uma “moleza” para o Paradox torna-se uma tremenda “dor-decabeça”
para o InterBase. Em geral, a navegação de trás para frente através de tabelas SQL é
ineficiente. O BDE armazena grupos de registros para minimizar este problema, mas se você
avançar muito para trás em tabelas relativamente extensas, acabará tendo que aguardar por pausas
significativas.
4
Travamento (locking)
Quando dois usários tentam acessar a mesma faixa de dados podem surgir problemas
ameaçando a integridade do banco de dados. O Paradox e o InterBase lidam com estes problemas
de maneiras diferentes.
Como o Paradox não possui nenhum conhecimento do que outro processo Paradox está
fazendo, ele utiliza um esquema pessimista de travamento (Pessimistic Locking Scheme). Assim
que um usuário tenta mudar um registro o registro é travado. Nenhum outro usuário pode fazer
alterações neste registro até que o primeiro usuário termine as alterações ou cancele a operaçao.
Por um lado, este esquema de travamento é positivo se considerarmos que o usuário que obteve o
travamento poderá concluir com sucesso a sua operação de alteração. Por outro lado, isto é
negativo no sentido em que um usuário poderá mononopolizar um registro indefinidamente. Isto
seria um problema, por exemplo, num sistema de reserva de viagens. Um viajante indeciso poderia
“trancar” um assento por um longo período, levando os outros a acreditarem que assento já foi
tomado, sendo que no final o indeciso pode acabar desistindo do assento.
O InterBase, por outro lado, lida com a manipulação de todos os dados através de um
esquema de concorrência otimista (Optimistic Concurrency Scheme). Na verdade, quando um
usuário processa uma alteração o registro não impedirá que outras pessoas tentem também alterar
este registro. Quando um usuário começa a alterar um registro InterBase uma cópia do registro
original é salva. O usuário executa seu serviço, mas os outros usuários não estão sob nenhuma
forma impedidos de acessar o mesmo registro.
Quando algum usuário termina sua alteração e efetua um post (atualização no banco) a
cópia do registro original é comparada com o registro corrente. Se os valores são diferentes
(provavelmente porque outro usuário alterou mais rapidamente o mesmo registro) as alterações
efetuadas pelo usuário no registro são rejeitadas.
Isto significa que usuários individuais não podem travar o acesso de outros usuários ao
mesmo registro. No exemplo anterior de reservas de viagens, o primeiro passageiro a confirmar a
reserva ficaria com o lugar, mesmo se vários outros usuários estivessem simultaneamente
considerando o mesmo lugar. O lado ruim da estória, porém, é que as alterações são rejeitadas
apenas no momento em que se tenta efetuar a atualização no banco, após todo o trabalho de
alteração ter sido efetivado. Isto pode ser corrigido relendo-se (pelo método refresh) os campos
alterados e tentando-se novamente efetuar a atualização. Os camponentes TTable ou TQuery
tornam esta operação transparente através da propriedade UpdateMode. A verificação, quando
enviamos comando de atualização no banco, pode ser feita dependendo do valor desta propriedade,
em todos as campos, somente nos campos alterados ou somente nas chaves primárias.
Estas duas visões refletem as diferenças básicas nas duas filosofias. O modelo pessimista
Paradox assume que as colisões serão frequentes e deverão ser tratadas de uma forma rigorosa,
enquanto o modelo otimista InterBase assume que as colisões serão ocasionais e maximiza a
habilitação dos usuários para o compartilhamento de dados sem interferência de um com o outro,
enquanto estiver sendo mantida a integridade.
Um importante benefício do modelo do InterBase é que um usuário que quer visualizar um
conjunto de dados estáveis, talvez para gerar uma série de relatórios que precisam refletir a
situação atual dos dados, não sofrerá interferencia de outro usuário que estiver naquele momento
alterando os dados. Em tabelas Paradox, o gerador de relatórios deverá colocar um “write lock” na
tabela para garantir que os dados não sejam alterados e ninguém poderá efetuar transações na
tabela até que este lock tenha deixado de existir.
No InterBase as versões dos registros mais antigos, são retidas durante o tempo em que o
usuário estiver algum interesse sobre elas. Isto significa que nem os leitores dos dados impedem a
ação dos “editores” e nem os últimos comprometem o resultado dos primeiros. InterBase é o único
banco SQL que torna isto transparente. Quando os adeptos do InterBase são questionados sobre as
5
vantagens do banco, este controle da disponibilidade do registro é normalmente a primeira
vantagem a ser mencionada.
Processamento de Transações
Como você já sabe, o modelo “baseado em conjuntos” constitui-se em um conjunto de
dados que podem ser tratados como entidades individuais, levando em consideração o conteúdo
específico destes conjuntos. O processamento de transações é uma extensão destas idéias. Uma
transação é um grupo de operações onde ou todas elas são bem ou mal sucedidas. Nunca deverá
ocorrer a situação onde apenas algumas sejam bem ou mal sucedidas.
Por exemplo, um caixa automático realiza transações com bancos de dados. Sempre que
você retira dinheiro, duas operações devem ser realizadas para que o banco possa contabilizar seu
ativo apropriadamente: o saldo da sua conta deve ser reduzido e o saldo de dinheiro disponível no
banco deve ser reduzido na mesma quantia. Obviamente, a situação preferível é aquela na qual as
duas operações sejam bem sucedidas, mas se acabar a energia no meio de uma operação, é
totalmente inaceitável que uma conta seja atualizada e a outra não – ambas operações deveriam
“falhar” para manter uma contabilização apropriada.
O processamento de transações permite que isto aconteça. As operações em uma transação
não são permanentes até que seja efetuado o commit na transação. Até que isto aconteça, as
operações podem ser desfeitas, retornando-se ao ponto de partida. Um Rollback pode ser
implementado explicitamente, utilizando-se o método Rollback, ou automaticamente, quando
ocorre uma falha do sistema.
O InterBase suporta totalmente o conceito de transações. Na realidade, todas as operações
ocorrem dentro de um contexto de transação. Na ausência de um controle explícito do
programador, o BDE automaticamente envolve todas as operações na sua própia transação. Por
exemplo, toda vez que você atualiza um registro, a transação é inicializada (started) e finalizada
(commited) automaticamente após cada confirmação (post). Usando o componente TDataBase você
pode explicitamente controlar uma única transação, e também fazê-la conter quantas operações
você quiser.
O Paradox porém não suporta transações. Sempre que um registro é atualizado no banco, as
mudanças são permanentemente gravadas na tabela. Será necessária uma nova alteração para
desfazer manualmente as alterações anteriores se um Rollback for desejado. Além disto, o sistema
não irá garantir que, em um grupo de operações, todas elas serão bem sucedidas ou todas elas
falharão. É possível simular algumas destas características através de certos truques de
programação e tabelas temporárias, mas eventualmente, haverá a necessidade de se modificarem os
registros um de cada vez, em lote, o que deixaria aberturas para a ocorrência de falhas. Além disto,
é impossível de se programar um aplicativo Paradox para se recuperar de uma falha de sistema
como queda de força ou danos na memória secundária.
Gatilhos (triggers) e procedimentos (procedures)
Uma Stored Procedure consiste em um “pedaço” de código armazenado em um banco de
dados junto aos dados que este contém. Isto permite ao servidor efetuar manipulações complexas
de dados inteiramente no próprio servidor. As vantagens principais disto são que processos ainda
mais complexos podem ser delegados ao servidor, e qualquer número de diferentes aplicações
clientes podem chamar os mesmos procedimentos. Se o procedimento for modificado no servidor,
nenhuma das aplicações necessitará ser reescrita, desde que a interface do procedimento continue a
mesma.
Um trigger consiste em uma Stored Procedure que não é explicitamente chamado por uma
aplicação, mas é executado em resposta a uma ação ocorrida com determinados dados, como por
6
exemplo, uma inserção de novos registros. A utilização de triggers permite que você realize
validações de dados extremamente complexas, sendo que as operações planejadas ocorrerão
garantidamente no interior da mesma transação que disparou o “engatilhamento”. Se alguma das
operações falhar, todas as alterações feitas por triggers associados a esta operação serão também
desfeitas (rolled back).
O InterBase suporta Stored Procedures que retornam Result sets, os quais são tratados
exatamente como tabelas somente de leituras, assim como triggers que simplesmente executam
transações de dados e não retornam nenhum resultado. O InterBase suporta essencialmente um
número ilimitado de triggers para cada tabela os quais podem ocorrer antes ou depois das
operações de inserção, alteração e remoção de registros. Se mais de um trigger é associado a uma
operação a ordem de execução pode ser especificada. Triggers podem efetuar mudanças que
disparem outros triggers, numa reação em cadeia, mas estas ações em cascata continuarão contidas
numa única transação.
O Paradox não suporta nenhum destes conceitos. Todos os processamentos de dados devem
ser realizados no cliente. Cada aplicação deve conter a mesma codificação para manutenção dos
dados, e cada uma delas deve também ser modificada caso o método de manipulação de dados
necessitar ser alterado.
Não existe uma garantia que uma aplicação será completada uma vez que tenha sido
iniciada. Por exemplo a operação de se efetuar uma deleção em cascata de registros “detalhe” após
a deleção de um registro “mestre” pode falhar no seu meio, deixando alguns registros detalhe sem
serem apagados. Se esta “cascata” fosse implementada por meio de triggers no InterBase, ou todos
os registros ou nenhum deles seriam apagados. Além disto, numa aplicação Paradox, a codificação
para perpetuar a deleção deveria ser escrita em cada uma das aplicações diferentes que utilizassem
os dados do sistema Paradox. Utilizando-se InterBase, por outro lado, a codificação necessita ser
escrita apenas uma vez, no trigger. A aplicação simplesmente deleta o registro “mestre” e o
InterBase cuida da deleção dos registros “detalhe”.
Fazendo a melhor escolha
Escolher entre Paradox e InterBase pode ter implicação importante para o seu projeto.
Portanto, é essencial saber o que é mais adequado em cada situação. A figura 1 mostra alguns
princípios gerais que podem ajudá-lo a tomar a melhor decisão.
Isto são sugestões e não devem ser encaradas como regras. A maioria pesume que uma rede
estará envolvida. Se você está implementando um sistema mono-usuário, o Paradox é usualmente a
melhor escolha. O servidor InterBase local pode ser indicado para um sistema mono-usuário, mas
sem os aspectos de concorrência, as vantagens básicas do InterBase não estarão sendo utilizadas.
Conclusão
É importante relembrar que o Paradox e o InterBase são sistemas consideravelmente
diferentes, mesmo que o BDE crie uma ilusão de semelhança. Esta é uma sedutora mas perigosa
idéia pois converter uma aplicação de um mecanismo para outro (InterBase em Paradox ou vice e
versa) envolve muito mais do que uma simples mudança de Alias. Requer na verdade, significativas
diferenças de conceito e projeto.
Escolher qual sistema utilizar é uma decisão crucial que deve ser tomada no início do
projeto. Esta decisão terá um impacto profundo no desenvolvimento da sua aplicação.
Paradox é melhor quando… InterBase é melhor quando…
7
a aplicação é utilizada com menos de 10 usuários
concorrentemente
a aplicação é utilizada com mais de 10 usuários
concorrentemente
dados e estruturas de dados devem ser facilmente
modificados por usuários finais
dados devem ser centralizados, mantidos e protegidos
a máquina cliente é proporcionalmente mais potente
que a máquina servidora
a máquina servidora é muito mais potente que a
máquina cliente
largura de banda da rede satisfatória rede está carregada
velocidade e “conveniencia” são mais importantes que
integridade
integridade de dados é crucial
baixa disponibilidade de administradores de rede e
banco de dados qualificados
disponibilidade de administradores de rede e banco de
dados qualificados
somente uma aplicação acessará rotineiramente os
dados
várias aplicações poderão acessar os dados
as aplicações serão as responsáveis pela manutenção
da integridade de dados
o banco será o responsável pela integridade de dados
independentemente das aplicações
pequena ou moderada quantidade de dados (< 100
MB)
moderada a grande quantidade de dados (> 100 MB)

GOSTOU SIGA O SITE

Construção de Comandos SQL

Em bancos de dados relacionais as informações são guardadas em tabelas. Para
recuperar uma informação necessaria ao usuário, deve-se buscá-la em várias tabelas
diferentes, estabelecendo-se um relacionamento entre elas. Esta é a origem do nome
deste paradigma de banco de dados.
Tabelas são na verdade conjuntos. Por exemplo, quando em um sistema existe uma
tabela de vendas, esta tabela corresponde ao conjunto de todas as vendas feitas por uma
empresa. A tabela de vendedores corresponde ao conjunto de vendedores que trabalham
em uma empresa. Cada linha ou registro da tabela corresponde a um elemento do
conjunto.
Consultas e alterações na base de dados correspondem a operações realizadas sobre
conjuntos. Estas operações são definidas pela álgebra relacional.
Por exemplo, determinar quais os vendedores com tempo de casa maior que
um determinado patamar, significa determinar um subconjunto do conjunto de
vendedores, onde todos os elementos possuam uma determinada propriedade. Para
determinar as vendas destes vendedores, é necessário realizar a operação já citada e
depois, para cada elemento do subconjunto “vendedores veteranos” é necessário
determinar o subconjunto do conjunto de vendas, contendo a propriedade de ter sido
realizada pelo vendedor em questão. O resultado final da consulta será a união de todos
estes subconjuntos.
O problema apresentado possuí também outra forma de solução. Podemos, em um
primeiro momento, determinar para cada vendedor, quais as suas vendas. Teríamos então
vários subconjuntos, cada um contendo as vendas de um vendedor. Feito isto,podemos
verficar quais os vendedores são veteranos, formando o resultado final a partir da união dos
subconjuntos associados a cada um.
Consultas em banco de dados não passam de problemas de álgebra relacional. Assim como
acontece com a álgebra “tradicional”, os operadores possuem algumas propriedades. Sabemos
que 2 x 3 = 3 x 2. Isto significa que, quando precisamos contar uma expressão de álgebra
relacional para chegar a um determinado resultado,podemos faze-lo de mais de uma forma, pois
várias expressões levam ao mesmo resultado. Em outras palavras, quando o banco de dados
precisa montar uma expressão algébrica para encontrar um resultado, ele deve escolher uma entre
várias. Apesar de apresentarem o mesmo resultado, as expressões são diferentes, e a diferença
fará com que o banco de dados adote um diferente caminho para resolver cada uma.
Escolher o caminho mais curto é uma das grandes atribuições do banco de dados. Está é a
missão do otimizador, um subsistema do banco da dados, responsável por determinar o plano
de execução para uma consulta.
A linguagem SQL (Search and Query Language) é um grande padrão de banco de dados.
Isto decorre da sua simplicidade e facilidade de uso. Ela se opõe a outras linguagens no sentido
em que uma consulta SQL especifica a forma do resultado e não o caminho para chegar a ele.
Ela é um linguagem declarativa em oposição a outras linguagens procedurais. Isto reduz o
ciclo de aprendizado daqueles que se iniciam na linguagem.
Vamos comparar:
descrição declarativa:
“quero saber todas as vendas feitas por vendedores com mais de 10 anos de
casa.”
descrição procedural:
“Para cada um dos vendedores, da tabela vendedores, com mais de 10 anos
de casa, determine na tabela de vendas todas as v @ destes vendedores. A
união de todas estas vendas será o resultado final do problema.”
Na verdade, fui bem pouco honesto na comparação. Minha declaração procedural tem
muito de declarativa, o que a torna mais simples. Se ela fosse realmente
procedural, seria ainda mais complicada.
O fato é que, ter que informar o como fazer, torna as coisas mais difíceis. Neste
sentido, SQL facilitou muito as coisas.
Porém, a partir do nosso “o que queremos”, o banco de dados vai determinar o “como
fazer”. No problema das “vendas dos veteranos”, descrevi duas formas de solucionar o
problema, a primeira certamente melhor que a segunda. O objetivo deste texto é
apresentar formas de dizer para o banco de dados o que queremos, ajudando-o a
determinar uma forma de fazer que tenha esforço mínimo. Para chegarmos a este
objetivo, lamentavelmente, teremos que nos preocupar com o “como fazer”. É fato que
parte da necessidade da nossa preocupação com o “como fazer” é decorrência do estágio
atual da tecnologia, que ainda pode evoluir. Porém, por melhor que seja o otimizador de
um banco de dados, ele poderá trocar a consulta fornecida pelo usuário por outra
equivalente segundo a álgebra relacional. Em algumas situações uma consulta é
equivalente à outra apenas considerando-se a semântica dos dados. Neste caso, se nós não
nos preocuparmos com o “como fazer “, teremos uma performance pior.
Uso de índices
Quando fazemos consultas em uma tabela estamos selecionando registros com determinadas
propriedades. Dentro do conceito de álgebra relacional, estamos fazendo uma simples operação
de determinar um subconjunto de um conjunto. A forma trivial de realizar esta operação é
avaliar cada um dos elementos do conjunto para determinar se ele possui ou não as propriedades
desejadas. Ou seja, avaliar, um a um, todos os seus registros.
Em tabelas grandes, a operação descrita acima pode ser muito custosa. Imaginemos que
se deseje relacionar todas as apólices vendidas para um determinado cliente, para saber seu
histórico. Se for necessário varrer toda a tabela de apólices para responder esta questão o
processo certamente levará muito tempo.
A forma de resolver este problema é o uso de índices. Índices possibilitam ao banco de dados
o acesso direto às informações desejadas.
Fisicamente, a tabela não está organizada em nenhuma ordem. Os registros são
colocados na tabela na ordem cronológica de inserção. Deleções ainda causam mudanças nesta
ordem. Um índice é uma estrutura onde todos os elementos de uma tabela estão
organizados, em uma estrutura de dados eficiente, ordenados segundo algum critério. Um
registro no índice é composto pelo conjunto de valores dos campos que compõem o índice e pelo
endereço fisico do registro na tabela. Ao escrever uma consulta SQL, não informamos
especificamente qual índice será usado pela consulta. Esta decisão é tomada pelo banco de
dados. Cabe a nós escrever a consulta de forma que o uso do índice seja possível. É preciso que
nossa consulta disponibilize o índice.
Possibilitando uso de colunas para acesso indexado
Na verdade, a consulta disponibiliza colunas que podem ser usadas em acesso à índices.
O banco de dados, a partir das colunas disponíveis e dos índices existentes, determina a
conveniência de se usar determinado índice.
Para permitir que uma coluna seja usada em acesso à índice, ela deve aparecer na cláusula
where de um select.
Por exemplo, a consulta:
select campol
from tabela
where campol = 3
and campo2 > 4
and campo3 <> 7
and campo4 between 10 and 20
and campo5 + 10 = 15
and to – number (campo6) = O
and nvl (campo7, 2) = 2
and campo8 like ‘GENERAL%’
and campo9 like ‘%ACCIDENT’
Disponibiliza o uso de índices nos campos campo 1, campo2 e campo4. Nos casos dos campos
campo2 e carnpo4, o acesso a índice será para buscar registros que possuam valor numa
determinada faixa.
A condição campo3 <> 7 não disporúbieza índice por ser uma relação de
desigualdade.
De fato, se a tabela possuir n registros, um dos quais com campo3 = 7, não parece
razoável um índice para recuperar N – 1 elementos.
A condição campo.5 + 10 = 15 não permite uso de índice pela coluna campo5 por igualar ao
valor 15 uma expressão envolvendo a coluna, e não a coluna isolada. De fato, uma técnica
para se inibir o uso de índice em uma coluna, quando desejado, é usar expressões tais como:
· nome-coluna + O = 15, para campos number ou date, ou
· nome-coluna || ‘ = ‘ABCD’, para campos char.
As expressões envolvendo as colunas campo6 e campo 7 também não disponibilizam índice pelo
mesmo motivo. Foram incluídas aqui por se tratarem de casos em que, freqüentemente, as
pessoas acham que o uso de índice seria possível.
A expressão envolvendo campo8 disponibiliza índice, pois ela é na verdade como se
escrevêssemos: campo8 >= ‘GE cccc… ‘and campo8 < = ‘GEddd…’ onde c é o menor caracter
na ordem da tabela ASCIII, dentro do domínio possível de valores para o campo é d o maior. Já
a expressão envolvendo campo9 não permite uso de índice.
Se houver um índice único na tabela pelo campo 1, o acesso disponibilizado por este índice é um
unique scan: o banco de dados faz um acesso ao índice para buscar um único registro.
Mesmo que haja um índice único pelo campo2, será feito um range scan na tabela, ou seja, uma
busca para recuperar vários registros. O mesmo ocorre para o campo4.
Escolhendo um índice
Dadas as colunas que podem ser usadas para acesso indexado, o banco de dados passa a decisão
sobre qual índice será usado. Para isto, ele determinará os índices disponíveis para então
escolher um.
Um índice estará disponível se um prefixo dos campos que o compõem estiver disponível. Por
exemplo, se o índice for composto pelas colunas campo1, campo2, campo3 e campo4, o índice
estará disponível se estiverem disponíveis as colunas:
campo1 ou
campo1 e campo2 ou
campo], campo2, e campo3 ou
campo1, campo2, campo3 e campo4.
Neste último caso, o uso do índice será completo, se ele for usado.
A seleção entre os índices para determinar qual será realmente usado é feita a partir de
heurísticas, como por exemplo, é melhor usar um índice único que um índice não único. Esta
seleção pode considerar também informações sobre os dados armazenadas na tabela, dependendo
da configuração do servidor de banco de dados.
Qual o melhor índice?
O critério básico para escolha de índices é a seletividade. Quando o banco de dados resolve uma
consulta, freqüentemente, ele precisa percorrer mais registros do que aqueles realmente
retomados pela consulta. Os registros percorridos que forem rejeitados representarn o trabalho
perdido. Quanto menor for o trabalho perdido, mais perto estaremos da performance ótima para
resolver a consulta. Portanto, o melhor índice para uma consulta é aquele que apresenta a maior
seletividade. Vejamos a consulta abaixo:
select campol
from tabela
where campo2 = 2 and campo3 = l and campo4 = 3;
tabela possui os índices:
índice 1: campo2, campo5
índice 2: campol
índice 3: campo3, campol
índice 4: campo4
índice 5: campo5, campo4
Neste caso, estão disponíveis para consultas indexadas os campos campo2, campo3 e campo4 o
que permite o uso dos índices 1, 3 e 4. O índice mais seletivo será aquele que recuperar o mínimo
número de registros.
Se houver 10 registros com campo2 = 2, 2000 registros com campo3 = 1 e 50
registros com campo4 = 3, o índice 1 será o mais seletivo. Nossa melhor alternativa é portanto
um range scan no índice l . Vale a pena ressaltar que o fato do índice 1 possuir também a coluna
campo5 prejudica.um pouco a consulta. Ou seja, seria melhor, para esta consulta, que o índice 1
possuísse apenas o campo2.
Para resolver a consulta, o banco de dados fará o acesso ao índice, onde irá recuperar o
endereço fisico, na tabela, dos registros candidatos a compor o resultado. Com este endereço,
ele verifica cada registro quanto às outras condições. Os que satisfizerem as outras
condições comporão o resultado.
Em alguns casos, este cantinho pode ser mais simples. Veja o exemplo abaixo:
Select campo1 from tabela where campo2 = 2;
Tabela possui os índices:
índice 1: campo1 , campo3
índice2: campo2, campo1, campo3
índice3: campo1, campo2
Neste caso, o banco de dados apenas pode usar o índice 2. A consulta pode ser resolvida sem
acesso à tabela, usando apenas o índice. Uma vez que o índice também possui os valores para
campo1 de cada registro, não há necessidade de se recuperar este valor da tabela.
Campos nulos não entram
Toda vez que um registro possuir valores nulos para todos os campos que compõem um índice,
este registro não será colocado no índice.
Isto causa problemas de performance em sistemas mau projetados. Suponha que a modelagem
de dados de um sistema de contas a pagar tenha resultado em um projeto onde existe uma tabela
de contas (ou compromissos, ou títulos) a pagar, contendo, entre outros, dois campos: data de
vencimento e data de pagamento. A primeira seria a data em que o título deve ser pago. A
segunda a data em que o título foi efetivamente pago. Suponha ainda que a dinâmica do sistema
determine que todo título, ao ser inserido no sistema, tenha valor nulo para o campo data de
vencimento. Quando o pagamento vier a ser efetuado, o campo será atualizado. É bastante
possível que seja construída uma consulta para recuperar todos os títulos não pagos. Neste caso,
não será possível o uso de índices, pois estamos procurando campos com valor nulo. Se
tivermos, nesta tabela, 200000 títulos, dos quais 500 não pagos, esta consulta terá desempenho
bastante aquém do possível. Uma solução melhor, seria iniciaüzar o campo data de vencimento
com o valor 01/01/1998, significando conta não paga.
Tabelas pequenas
Como última consideração sobre consultas em uma tabela, vale lembrar que quando fazemos
uma consulta a uma tabela bastante pequena, não compensa usar índices. o trabalho envolvido
em acessar o índice pegar o endereço e, depois, acessar a tabela é maior que o esforço de ler a
tabela inteira.
Consultas em várias Tabelas
Consultas envolvendo várias tabelas são feitas através de joins. Na teoria da álgebra relacional,
estas consultas são produtos cartesianos entre os conjuntos (tabelas) envolvidos. Para cada
elemento do conjunto resultado do produto cartesiano, será verificado se ele possui ou não um
determinado conjunto de condições, imposto ao resultado da consulta.
O banco de dados irá tirar proveito de propriedades matemáticas para otimizar estas consultas.
Imagine que tenhamos dois conjuntos, um de retângulos e um de círculos. Tome como objetivo
obter o subconjunto do produto cartesiano destes dois conjuntos que apenas contenham círculos
amarelos e retângulos azuis. Há duas formas de resolver isto. Uma é fazer o produto cartesiano,
e, a partir do resultado, excluir os elementos que não atendem a premissa. Outra é determinar o
subconjúnto dos círculos amarelos e o subconjunto dos retângulos azuis, fazendo um produto
cartesiano dos dois subconjuntos. Apesar de equivalentes quanto ao resultado, o segundo
método é bastante mais eficiente em termos de performance.
Normalmente, quando se faz uma consulta em duas ou mais tabelas, existe alguma informação
que as une. Por exemplo, você quer relacionar registros de um determinado empregado apenas
ao registro do departamento onde este empregado trabalha. Esta condição é chamada de
condição de join. Normalmente, esta condição evita que seja necessária a realização de um
produto cartesiano de fato. Vejamos o exemplo:
select depto.nome, emp.nome
from empregados emp, departamentos depto
where emp.data_admissao < ‘Ol-jan-92’
and depto.id – departamento = emp.departamento and depto.area-de~negocio = ‘FAST~FOOD’;
Neste caso, estamos trabalhando sobre dois conjuntos: empregados e departamentos.
Possuímos restrições sobre estes dois conjuntos e uma restrição que serve para juntá-/os.
O banco de dados pode resolver a consulta acima
de duas formas. A primeira envolve determinar o subconjunto dos empregados e
departamentos que obedecem as restrições nestes conjuntos. Posteriormente, geramos o
resultado a partir dos dois subconjuntos, respeitando a condição de join. A segunda forma
envolve escolher um conjunto para iniciar a solução, por exemplo o de departamentos.
Deterrminamos o subconjunto deste que possua a propriedade apresentada (determinada área
de negócio). Para cada elemento deste subconjunto, faremos sua associação ao elemento
correspondente no outro conjunto, segundo a condição de join. Finalmente, verificamos se o
registro formado possui a restrição no outro conjunto. A primeira forma de solução é
chamada de sort-merge join. A segunda é chamada de nested-loops.. O banco de dados
sempre usa uma destas duas técnicas para resolver consultas em múltiplas tabelas. Ele pode
mesmo, combinar as duas.
Na maioria dos casos, o método de nested-loops apresenta melhores resultados. Ern alguns
casos complexos, o sort-merge é indicado.
Outer join
O.outer join(ou junção extema) é um caso particular do join. Quando se faz um join
simples, a impossibilidade de se encontrar em alguma tabela um registro associado ao resultado
intermediário anterior, determina que o join não retomará nenhuma informação.
Quando uma tabela entra no join através de um outer join, quando não houver registros na
tabela associados ao resultado intermediário, urna linha imaginária será adicionada à tabela em
questão, contendo valor nulo para todos os seus campos. Esta linha será juntada aos registros de
resultado intermediário, compondo o novo resultado intermediário.
Um Outer join não causa uma lentidão de processamento muito maior que a de um
join.
Sub Select
Outro mito que ronda a construção de SQL diz que é melhor usar Sub Select do que
usar um join. Dependendo de quem reproduz o mito, a situaçao se inverte, e o join passa
a ser melhor que o Sub Select. Na verdade, deve-se fazer uma análise caso a caso. As
duas técnicas podem inclusive, serem equivalentes.
Vejamos o exemplo:
select campo1
from tabela1
where campo2 in (Select campo2
from tabela2 where campo4 = constante)
e
select campol
from tabelal, tabela2
where campo4 = constante and
tabela1.campo2 = tabela2.campo2
Neste caso, primeiro devemos notar que as duas consultas só são equivalentes se houver
unlcídade nos valores do carnpo3. Caso contrário, pode haver diferença de resultados, quanto ao
número de registros retornados. Imagine que as duas tabelas tenham três registros cada uma,
todos com o mesmo valor para carnpo2 (na tabelal) e o mesmo valor para campo3 (na tabela2).
Imagine também que todas as linhas da tabelal tenham o mesmo valor para campo 1. No caso da
sub select, a consulta retorna três linhas como resultado. No caso do join, retorna 9 linhas.
Portanto, para serem equivalentes de fato, é necessário que exista unicidade nos valores de
campo3 ).
Se houver a unícidade, o uso do sub select . ou join (com relação à perforrnance) é
absolutamente equivalente. De fato, para resolver esta consulta, em qualquer dos dois casos, o
banco de dados irá determinar os registros da tabela2 que possuem “campo4 = constante’. Irá
recuperar então o valor de campo3 para estes registros. Para cada valor, obterá os registros da
tabelal com campo2 igual a este valor. Os valores de campo1 nestes registros comporão os
conjuntos resultados.
Vejamos unia situação onde precisamos saber todas as notas fiscais que contenham
itens fabricados por um determinado fornecedor, em um determinado dia.
Sub Select:
select num nota
from notas Fiscais
where data-emissao = constante and exists (select ‘x’
from produtos , itens-nota
where produtos.num-nota = itens-nota.num- nota and
produtos.produto = itens-nota.produto and
fornecedor = constante)
Join:
select distinct num – nota
from produtos , itens – nota , notas-fiscais
where notas-fiscais.data-emissao = constante and
itens-notas.num-nota = notas-fiscais.num-nota and
produtos.produto = itens-nota.produto and
produto.fornecedor = constante
Existe uma diferença apreciável de performance entre as duas consultas. Note que, o importante
é saber se existe pelo menos um item de uma nota fiscal associado a um determinado fornecedor.
Não é necessário determinar todos os itens deste fornecedor. Este é o ponto onde a consulta com
join torna-se pior, em termos de performance que a consulta com sub select. Note que a data da
nota foi incluída para ser um fato seletivo e justificar o exemplo. Se não houvesse tal restrição, o
jeito certo de construir a consulta seria determinar todos os produtos do fornecedor, depois os
itens de nota com este produto e finalmente as notas correspondentes. Desde, é claro, que um
fornecedor seja razoavelmente seletivo. Neste caso, teríamos um exemplo onde join é melhor do
que sub select. Apenas por uma diferença sutil de existência de um critério de data.

 

GOSTOU SIGA O SITE

TÉCNICAS DE TESTE DE SOFTWARE

TÉCNICAS DE TESTE DE SOFTWARE E ESTRATÉGIAS DE TESTE

A atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão de especificação,
projeto e codificação.
Objetivos da Atividade de Teste
1. A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro.
2. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto.
3. Um teste bem sucedido é aquele que revela um erro ainda não descoberto.
Teste de Caminho Básico
O método de caminho básico possibilita que o projetista do caso de teste derive uma medida da complexidade lógica de um projeto
procedimental e use essa medida como guia para definir um conjunto básico de caminhos de execução.
Teste de Estrutura de Controle
Estes testes ampliam a cobertura dos testes e melhoram a qualidade dos testes.
l Teste de condição: Põe em prova as condições lógicas contidas num módulo de programa. Uma condição simples é uma variável
booleana ou uma expressão relacional, possivelmente precedida por um operador NOT ( ‘ ) . Uma expressão relacional assume a
forma E1<operador relacional>E2. Uma condição composta é constituída de duas ou mais condições simples, operadores
booleanos e parênteses, OR ( | ). AND ( & ) e NOT ( ‘ ). Uma condição sem expressões relacionais é chamada expressão booleana.
O método de teste de condição concentra-se em testar cada condição do programa.
l Teste de Fluxo de Dados: Seleciona caminhos de teste de um programa de acordo com as localizações das definições e usos de
variáveis no programa.
l Teste de Laços: Se concentra exclusivamente na validade das construções de laços, laços simples, aninhados, concatenados, nãoestruturados.
Particionamento de Equivalência
Este método divide o domínio de entrada de um programa em classes de dados a partir das quais os casos de teste podem ser derivados. O
particionamento de equivalência procura definir um caso de teste que descubra classes de erros, assim reduzindo o número total de casos de
teste que devem ser desenvolvidos. Uma classe de equivalência representa um conjunto de estados válidos para condições de entrada.
Análise de Valor Limite BVA
A análise de valor limite leva à escolha de casos de teste que põem à prova os valores fronteiriços. A análise de valor limita é uma técnica
de projeto de casos de teste que complementa o particionamento de equivalência. Em vez de selecionar qualquer elemento de uma classe de
equivalência, a BVA leva à seleção de casos de testes nas extremidades da classe. Em vez de se concentrar somente nas condições de
entrada, a BVA deriva os casos de teste também do domínio de saída.
Teste de Sistemas de Tempo Real
Neste tipo de deste, encontramos o elemento de combinação alinhado ao teste que é o tempo. Os testes de software devem levar em
consideração o impacto das falhas de hardware sobre o processamento do software. Tais falhas podem ser extremamente difíceis de ser
simuladas realísticamente.
Estratégia global para sistemas de tempo real:
1. teste de tarefas: O primeiro passo da atividade de testes de tempo real consiste em testar cada tarefa independentemente. Este teste
revela erros de lógica e de função, mas não revelará erros comportamentais ou de timing.
2. Teste comportamental: É possível simular o comportamento de um sistema de tempo real e examinar seu comportamento como
uma conseqüência de eventos externos. O comportamento do software é examinado a fim de detectar erros de comportamento.
3. Teste intertarefas: As tarefas assíncronas, que sabidamente comunicam-se entre si, são testados com diferentes taxas de dados e
cartas de processamento para determinar se ocorrerão erros de sincronização intertarefas.
4. Teste do sistema: O software e o software são integrados e uma variedade completa de testes de sistema é levada a efeito, numa

ESTRATÉGIAS DE TESTE DE SOFTWARE
Um esqueleto (template) de teste de software deve ser definido para o processo de engenharia do software. Esqueleto é um conjunto de
passos no qual podemos alocar técnicas de projeto de casos de teste e métodos de teste específico.
Uma estratégia de teste de software deve acomodar teste de baixo nível que seja necessário para verificar se um segmento de código-fonte
foi corretamente implementado, bem como teste de alto nível que valide funções importantes do sistema contra requisitos do cliente.
Verificação e Validação
A verificação refere-se ao conjunto de atividades que garante que o software implemente corretamente uma função específica. A validação
refere-se a um conjunto diferente de atividades que garante que o software que foi construído é rastreável às exigências do cliente.
Os métodos de análise, projeto e implementação (codificação) atuam no sentido de aumentar a qualidade ao oferecer técnicas uniformes e
resultados previsíveis.
A análise e o projeto de software (juntamente com a codificação) são tarefas construtivas , ou seja, o engenheiro de software cria um
programa de computador, sua documentação e estruturas de dados correlatas. Do ponto de vista do construtor, a atividade de teste pode ser
destrutiva, pois sempre vão ser descobertos erros no programa.
Uma Estratégia de Teste de Software
Teste unitário, este teste concentra-se em cada unidade de software de acordo com a implementação do código-fonte, ele exercita caminhos
específicos da estrutura de controle de um módulo, a fim de garantir uma completa cobertura e máxima detecção de erros.
Teste de integração, a atenção encontra-se no projeto e na construção da arquitetira de software, este teste cuida das questões associadas
aos duplos problemas da verificação e construção em programas.
Teste de validação, os requisitos estabelecidos como parte da análise de requisitos de software são validados em relação ao software que foi
construído, o teste de validação oferece a garantia final de que o software atende a todas as exigências funcionais, comportamentais e de
desempenho.
Teste de sistema, neste teste o software e outros elementos do sistema são testados como um todo, ele verifica se todos os elementos
combinam-se adequadamente e se a função/desempenho global do sistema é conseguida.
Critérios para a Conclusão de Teste
A atividade de teste jamais terá completada, a carga simplesmente transfere-se de você (o projetista) para o cliente.
Teste de Unidade
O teste de unidade concentra-se no esforço de verificação da menor unidade de projeto de software – o módulo. Caminhos de controle
importantes são testados para descobrirem erros dentro das fronteiras do módulo.
A interface com o módulo é testada para ter a garantia de que as informações fluem para dentro e para fora da unidade de programa que se
encontra sob teste. A estrutura de dados local é examinada para ter a garantia de que os dados armazenados temporariarmente mantêm sua
integridade durante todos os passos de execução de um algoritmo. As condições de limite são testadas para ter a garantia de que o módulo
opera adequadamente nos limites estabelecidos para demarcarem ou restringirem o processamento.
Entre os erros mais comuns de computação estão:
1. precedência aritmética incorreta ou mal compreendida;
2. operações em modo misto;
3. inicialização incorreta;

Os casos de teste devem descobrir erros tais como:
1. comparação de diferentes tipos de dados;
2. operadores lógicos ou precedência incorretos;
3. término do laço impróprio ou inexistente;
Teste de Integração
Este teste é uma técnica sistemática para a construção da estrutura de programa realizando-se, ao mesmo tempo, testes para descobrir erros
associados a interfaces. O objetivo é, a partir dos módulos testados no nível de unidade, construir a estrutura de programa que foi
determinada pelo projeto.
Freqüentemente, existe uma tendência para tentar a integração não-incremental; ou seja, construir o programa usando uma abordagem “big
bang” onde todos os módulos são combinados antecipadamente. O programa completo é testado como um todo.
A integração incremental é a antítese do big bang. O programa é construído e testado em pequenos segmentos, onde os erros são mais
fáceis de ser isolados e corrigidos; as interfaces têm maior probabilidade de ser testadas completamente; e uma abordagem sistemática ao
teste pode ser aplicada.
Integração Top-Down: é uma abrdagem incremental à construção das estruturas de programa. Os módulos são integrados movimentando-se
de cima para baixo através da hierarquia de controle, iniciando-se do módulo de controle principal(programa principal).Os módulos
subordinados ao módulo de controle principal são incorporados à estrutura de uma maneira depht-first (primeiramente pela profundidade)
ou breadth-first (primeiramente pela largura).
Integração Bottom-Up: inicia a construção e os testes com módulos atômicos (isto é, módulos localizados nos níveis mais baixos da
estrutura de programa). Uma vez que os módulos são integrados de baixo para cima, o processamento exigido para os módulos
subordinados em determinado nível está sempre disponível, e a necessidade de stubs é eliminada.
A maior desvantagem da abordagem top-down é a necessidade de ter stubs e as dificuldades de teste resultantes que podem ser
compensados pela vantagem de testar logo as principais funções de controle. A maior desvantagem da integração bootom-up é que o
programa não existe como entidade até que o último módulo seja adicionado.
Os critérios que estão citados a seguir são aplicados a todas as fases de testes:
Integridade de interface: As interfaces internas e externas são testadas à medida que cada módulo é incorporado à estrutura.
Validade funcional: Testes projetados para a descoberta de erros funcionais são aplicados.
Conteúdo de informação: Testes projetados para a descoberta de erros associados às estruturas de dados globais e locais são aplicados.
Desempenho: Testes projetados para a verificação dos limites de desempenho estabelecidos durante o projeto de software são aplicados.
Teste de Sistema
O teste de sistema é na verdade , uma série de diferentes testes, cujo propósito primordial é por completamente à prova o sistema baseado
em computador. Não obstante cada teste tenha uma finalidade diferente, todo o trabalho deve verificar se todos os elementos do sistema
foram adequadamente integrados e realizam as funções atribuídas.
Teste de Recuperação
O teste de recuperação é um teste de sistema que força o software a falhar de diversas maneiras e verifica se a recuperação é
adequadamente executada.
Teste de Segurança
Este teste tenta verificar se todos os mecanismos de proteção embutidos num sistema o protegerão, de acessos indevidos.
Durante o teste de segurança, o analista desempenha papéis de pessoas que desejam penetrar no sistema, qualquer coisa vale, tentando
desarmar o sistema, e derrubar as defesas que tenham sido construídas.

GOSTOU SIGA O SITE DIGITANDO SEU E-MAIL

Enter your email address:

Delivered by FeedBurner

Técnicas de Análise de Sistema

Conceitos Básicos

Derivado do grego analýein – desatar, soltar, significa dissolução de um conjunto em
suas partes. Em sentido amplo, empregam-se os termos “análise” e “analisar” como
sinônimos de exame e examinar, pesquisa e pesquisar, verificação e verificar.
1.2 Processo
Série de fenômenos sucessivos com relação de causa e efeito; por exemplo, uma
empresa é uma série de causas (matérias primas, recursos humanos, tecnologia, etc.) que
geram um efeito (produtos).
1.3 Programa
Escrito em que se dão os pormenores de um espetáculo, de uma cerimônia, das
condições de um concurso, dos procedimentos para execução de uma tarefa.
1.4 Análise de Sistemas
Representa o estudo detalhado de uma área de trabalho (processo), que antecede
uma ação que, quase sempre, implica no desenvolvimento de um conjunto de programas
integrados(sistema) destinado à execução controle e acompanhamento do processo.
1.5 Sistemas
Como veremos, existe uma definição “oficial” do termo sistema no dicionário, que
parecerá bastante abstrata. Existem, porém, muitos usos comuns do termo que lhe
parecerão perfeitamente familiares, e existem muitos tipos comuns de sistemas com que
temos contato todos os dias.
É importante estar familiarizado com diferentes espécies de sistemas por pelo
menos dois motivos. Primeiro, mesmo que seu trabalho como analista se concentre em um
tipo de sistema – um sistema automatizado de informações, computadorizado – ele
normalmente fará parte de um sistema maior. Desse modo, você pode estar trabalhando em
um sistema de pagamentos, que é parte de um sistema maior de “Recursos Humanos”,
que, por sua vez, é parte da organização comercial geral ( que constitui um sistema), que é,
por sua vez, componente de um sistema econômico geral, e assim por diante. Ou você
pode estar trabalhando em um sistema de controle de processos que é parte de uma
refinaria química, ou em um sistema operacional que seja parte de um “pacote” de software
de sistemas distribuídos por vendedores. Assim, para que o seus sistema tenha sucesso, é
preciso conhecer os outros sistemas com os quais ele vai interagir.
Muitos dos sistemas de computadores que elaboramos são substituições ou novas
implementações de sistemas não-computadorizados que já existem; além disso, a maioria
dos sistemas computadorizados interage ou tem uma interface com vários sistemas
existentes (alguns podem ser computadorizados ou não). Para que nosso sistema
computadorizado seja bem-sucedido, precisamos conhecer, detalhadamente, como o
sistema atual se comporta.
Em segundo lugar, embora muitos tipos de sistemas pareçam ser totalmente
diferentes, eles têm muitas semelhanças; existem princípios comuns, filosóficas e teorias
que se aplicam notavelmente bem a virtualmente todos os tipos de sistemas. Assim,
podemos muitas vezes aplicar o que aprendemos sobre outros sistemas – com base em

nossa experiência diária, bem como na experiência de cientistas e engenheiros em diversas
áreas – aos sistemas que elaboramos na área da computação. Por exemplo, um dos
importantes princípios de sistemas que primeiro foi observado no campo da biologia é
conhecido como a lei da especialização; quanto mais adaptado for um organismo a um
determinado ambiente, mais difícil será para esse organismo a adaptação a outro. Isso
ajuda a explicar o desaparecimento dos dinossauros quando o clima da Terra modificou-se
radicalmente; ajuda, também, aos analistas de sistemas a compreenderem que se
otimizarem um sistema computadorizado de forma a tirar a máxima vantagem de uma
determinada UCP, de uma linguagem de programação e de um sistema de gerenciamento
de banco de dados, poderão vir a ter sérios problemas em adaptar o sistema a ser
processado em outra UCP ou com um diferente sistema de gerenciamento de banco de
dados.
Dessa maneira, se conhecermos alguma coisa da teoria geral dos sistemas, ela
pode nos ajudar a compreender melhor os sistemas computadorizados (automatizados) de
informações. Isso é cada dia mais importante, pois queremos construir sistemas estáveis e
confiáveis, que funcionarão bem em nossa complexa sociedade – e há, naturalmente,
muitos sistemas não-computadorizados que vêm sobrevivendo por milhões de anos: a
humilde barata provavelmente sobreviverá a todos os sistemas computadorizados já
construídos ou a construir, e a toda a humanidade, também.
Assim vamos começar com uma definição do termo básico sistema.
1. um grupo de itens que interagem entre si ou que sejam interdependentes,
formando um todo unificado <~numérico> : como
a. (1) um grupo de corpos que interagem entre si sob a influência de forças
relacionadas <~gravitacional>
(2) uma mistura de substâncias em equilíbrio ou que tende para o equilíbrio
<~termodinâmico>
b. (1) um grupo de órgãos do corpo que desempenham, em conjunto, uma ou
mais funções vitais < o ~digestivo >
(2) o corpo, considerando como uma unidade funcional.
c. um grupo de objetos ou forças naturais relacionadas entre si < um ~fluvial >
d. um grupo de dispositivos ou uma organização em rede, principalmente para a
distribuição de algum produto ou servindo a um propósito comum < um ~
telefônico > < um  de aquecimento> < um  rodoviário > < um  de
processamento de dados >
2. um conjunto organizado de doutrinas, idéias ou princípios, habitualmente previsto
para explicar a organização ou funcionamento de um conjunto sistemático < o ~
da mecânica newtoniana >
3. a. um procedimento organizado ou estabelecido < o  de toques da digitação >
b. uma maneira de classificar, simbolizar ou esquematizar < um ~ taxonômico > <
o ~ decimal >
4. organização ou modelo: ORDEM
5. sociedade organizada ou situação social vista como indesejável:
“ESTABLISHMENT”.

Tipos de Sistemas
 Sistemas Naturais
Sistemas Estelares (galáxias, sistemas solares, etc.)
 Sistemas Geológicos (rios, cadeias de montanhas etc.)
 Sistemas Moleculares (organizações complexas de átomos)
 Sistemas feitos pelo Homem
 Sistemas Sociais(organizações de leis, doutrinas, costumes, etc.)
 Sistemas de Transporte (redes rodoviárias, canais, linhas aéreas, petroleiros, e
semelhantes).
 Sistemas de Comunicação (Telefone, telex, sinais de fumaça, sinais manuais, etc.)
 Sistemas de Manufatura (Fábricas, linhas de montagem, etc.)
 Sistemas Financeiros (contabilidade, inventários, livros-razão, controle de estoque,
entre outros)
 Sistemas Automatizados
 Hardware de computadores – UCP, terminais, impressoras, unidades de fita
magnéticas, etc.
 Software de computadores – programas de sistemas, como sistemas
operacionais, sistemas de bancos de dados e programas de controle de
telecomunicações, além dos programas aplicativos que executam as funções
desejadas pelo usuário.
 Pessoas – aquelas que operam o sistema, que fornecem as entradas e utilizam as
saídas, e as que desempenham atividades de processamento manual em um
sistema.
 Dados – as informações que o sistema conserva por um período de tempo.
 Procedimentos – determinações e instruções formais para a operação do sistema.
 Análise Estruturada
Análise Tradicional
 Segunda Geração
Até 1965 os computadores de grande porte instalados em nosso país eram
classificados como de segunda geração, como por exemplo o 1401-IBM.
Máximo no desenvolvimento de sistemas, era um sistema de folha de pagamento, e
um sistema de controle de estoque.
 Folha de pagamento (20 a 24 horas) para classificação de 10 mil funcionários.
 Não existia formação profissional.
 Sem documentação.

Terceira Geração
 1965, chegada do COBOL (considerada auto documentável).
 Aumento considerável no número de usuários em informática.
 Documentação era compreendida somente pelo profissional que desenvolveu.
 A documentação representava somente a parte física da aplicação.
 As lógicas não existiam em lugar nenhum.
O Software e o Hardware tem se desenvolvido de forma acentuada mas a documentação
continua em muitos CPD’s sem metodologia alguma, visando apenas como feito a
aplicação(software), ou seja, uma documentação física, dedutiva, difícil manutenção e difícil
entendimento.
 Relacionamento Usuário e Analista
 Analista união entre os usuários e os projetistas.
 Conclusão da etapa de requisitos funcionais do sistema.
 O Analista reponde pelo usuário a qualquer dúvida que o projetista vem a ter.
 Esta ferramenta, diminui possíveis duvidas a serem levantadas durante a fase de
projeto.
 É preciso definir bem as responsabilidades de cada um, O analista é responsável
por: estudos de viabilidade e alternativas, custo/benefícios, especificações, prazos e teste
de aceitação, enquanto o usuário é o recebedor final do sistema. Este é o responsável pela
decisão de integração do sistema dentro das operações da empresa, ou não. Somente ele,
o usuário pode aceitar o sistema.
 Problemas com Análise Clássica(Tradicional)
 Comunicação
Formas de interpretação diferentes, gerando interpretações erradas, e que levada
adiante continuarão a serem distorcidas cada vez mais.
 Uso excessivo de termos técnicos(AnalistaXUsuário).
 Mudanças naturais exigidas pelo sistema
 Maior nas aplicações comerciais.
 Número discreto e portarias aplicados pelos governos federal e estadual durante os
últimos anos.
 Falta de Ferramentas
 Ferramenta antiquadas de 20 anos atrás.
 Utilizando a narrativa proporcionando
 Perda de tempo.
 +50% das informações deduzidas pelo profissional de informática.
 Documentação

As empresas não adotam um padrão.
 Existe a figura do “Pai do Sistema”.
Dificuldade de manter a documentação (o trabalho manuscrito)
 Formação do Profissional
 Precária formação profissional na área de análise de sistemas.
 Adeptos da forma estruturada são submetidos a velha forma tradicional.
Dificuldade de Fixação do Problema
 Com textos narrativos na fase de levantamento das necessidades do usuário +70%
das informações da documentação.
Localização dos pontos a sofrerem alteração levam muito tempo, sem a certeza de
todos os pontos foram alterados.
 Análise Tradicional X Análise Estruturada
 Comparação
Enquanto na versão clássica qualquer produto final só pode ser analisado numa
única dimensão, na versão estruturada um sistema pode ser analisado na dimensão exata
das necessidades, tanto do analista quanto do usuário. Tudo vai depender da visão que o
interessado deseja ter do sistema, se mais abrangente ou mais detalhada.
A versão clássica é totalmente prolixa(muito longa ou difusa), enquanto que a
estruturada apresenta e expõe o que é feito e o que vai ser feito através do uso de gráficos,
o que torna a visualização e entendimento muito mais claros e objetivos.
A versão clássica entra diretamente em detalhes, pelo simples fato que o usuário
pensa no computador como a fórmula mágica para a solução de todos os seus problemas.
O trabalho de análise é dirigido às vezes até inconscientemente dessa forma. O
levantamento é feito principalmente a partir dos problemas apresentados pelo usuário, um a
um, sem a preocupação do todo. Por último levantando aquilo que na concepção do usuário
está bem, sendo que às vezes, o que ia bem, ao ser informatizado passa a ir mal,
simplesmente por falta de preocupação dos envolvidos com o todo. Na versão estruturada
isso não acontece, pois o trabalho de análise deve ser dirigido para a ferramenta e esta
exige que a análise deve ser feita de cima para baixo através de refinamentos sucessivos
até atingir-se os detalhes. Durante a parte de levantamento, não deve existir por parte dos
envolvidos analistas/usuários qualquer preocupação com problemas ou erros existentes.
Primeiro deve-se construir o modelo lógico existente para em seguida, após uma análise
conjunta bastante criteriosa, identificarmos os problemas e propormos as devidas soluções.
Por último, a versão clássica gera um produto monolítico enquanto que a versão
estruturada um totalmente particionado, do maior ao menor nível de detalhe, possibilitando
a identificação clara e simples de qualquer parte do sistema, bem como a agregação em
pequenos blocos de funções afins.
 Objetivos da Análise Estruturada
O documento a ser padronizado deve ser:
 Passível de manutenção

Gráfico
 Lógico
 Rigoroso
Conciso
 Legível
Tudo isso deve ser um sub-produto natural do trabalho. Ou seja, terminada a fase de
análise, ninguém deve necessitar de mais tempo para preparar a documentação – ela já
deve estar concluída.
 Condução do Trabalho de Análise
A condução da análise deve ser:
 Dirigida para a Ferramenta
 Mensurável/Pré-Determinada
Divisível
É de vital importância o cuidado de dirigir a análise para a ferramenta, pois caso
contrário estaremos praticando a versão clássica para, numa segunda etapa, dispor as
informações de forma gráfica. Ou seja a análise deve ser feita de cima para baixo. A
preocupação de levantar o que é feito pelo usuário deve ser constante e não, à medida em
que o usuário fala, pensar em como o analista vai mecanizar aquilo, quais vão ser as
estruturas dos arquivos físicos, quais serão os métodos de acesso e outras preocupações
mais. Estas deverão ser objeto de preocupação de quem vai desenvolver o projeto físico e
não dele, mesmo que ele venha a acumular essas funções.
 Diálogo Usuário X Analista
O diálogo usuário/analista dever ser:
 Iterativo
 Lógico
 Limitado
 As Ferramentas da Análise Estruturada
 Diagrama de Fluxo de Dados
DFD é uma representação em rede dos processos (funções) do sistema e dos dados
que ligam esses processos. Ele mostra o que o sistema faz e não como é feito. É a
ferramenta de demostração central da análise estruturada.
Um DFD apresenta as partes componentes de um sistema e as interfaces entre elas.
É um conjunto integrado de procedimentos, sendo que as partes do computados poderão
estar inseridos ou não.
Na elaboração de um DFD, utilizaremos quatro símbolos que nos permitirão, debater
e apresentar ao usuário todo o processo, sem assumir nenhum compromisso com
implementações e demostrar a sua fluência, sem a preocupação com a hierarquização e
tomadas de decisão.
São os seguintes símbolos utilizados na elaboração de um DFD:

Quadrado duplo = Entidade Externa/Origem ou
destino de Dados.
Retânculo com cantos arredondados =
Processo que transforma o Fluxo dos Dados.
Retânculo aberto = Depósito de Dados
Seta ou vetor = Fluxo de Dados

Suponhamos que uma distribuidora de produtos farmacêuticos nos contratou para
analisar seu processo atual e verificar como expandir suas operações e melhorar seu nível
de serviço.
A empresa em questão, RPC (Remédios Pelo Correio), fundada há cinco anos atua
na distribuição de medicamentos, recebendo das farmácias os pedidos de medicamentos,
fazendo encomenda aos laboratórios, com desconto, e atendendo ao pedido no ato do
recebimento do dos remédios dos laboratórios. O processo é todo controlado manualmente
através do preenchimento de formulários pré-impressos. Atualmente o volume de negócios
atinge 150 pedidos por dia, cada um com um média de 5 medicamentos, e um valor de R$
500,00 em média. A administração pretende expandir as operações através da estocagem
dos 100 medicamentos mais solicitados e atendendo solicitações de clínicas e médicos
diretamente. As encomendas poderão ser feitas de qualquer ponto do Estado via telefone
ou pelo correio.
O volume de negócios dependerá, logicamente, de fatores como divulgação do
serviço, rapidez na entrega, confiabilidade, etc., mas a empresa espera aumentá-lo para
1000 negócios/dia, ou mais.
No plano geral, podemos afirmar que, da mesma forma que o atual, o novo processo
de trabalho da empresa acatará pedidos de remédios, fará a verificação no arquivo de
disponíveis, consultará, em outro arquivo, se o crédito do cliente é bom e fará com que o
remédio solicitado seja encaminhado ao cliente com a respectiva fatura.
Demostraremos isso de forma gráfica usando um diagrama de Fluxo de dados
lógico.

Analisando a figura, verificamos que, na verdade, ela nos diz muito pouco sobre o
sistema.
Os símbolos constantes da figura e os conceitos que representam encontram-se no
nível lógico; um fluxo de dados pode estar fisicamente numa carta, numa fatura, numa
ligação telefônica, etc., ou seja, em qualquer lugar em que o dado passe de uma entidade
ou processo para outro. Um processo pode ser fisicamente um escritório repleto de pessoas
verificando e recebendo pedidos, calculando descontos, ou um programa, ou ainda uma
combinação de atividades manuais e automatizadas. Um depósito de dados pode ser um
armário de aço com gavetas, um fichário de cartões, uma fita magnética, um disquete.
Utilizando os quatro símbolos, podemos desenhar um quadro do sistema sem nos
comprometermos com sua implementação.
Vamos expandir “processar pedidos” para mostrar as funções lógicas que compõe o
processo.
Observe o diagrama a seguir, onde representamos uma expansão do anterior,
demostrando os processos “Verificar validade dos pedidos” e “Preparar requisição par o
laboratório”, além de depósitos de dados para armazenar dados de clientes, dados de
laboratórios e dados dos pedidos pendentes, ou seja, aqueles que ficam aguardando a
quantidade ótima para endereçarmos o pedido ao laboratório obtendo o maior desconto.

GOSTOU SIGA O SITE E DIGITE SEU E-MAIL

 

LCM DIZ:Receba as postagens no seu e-mail registrando-se

Termos Técnicos de Informática

É preciso conhecer os termos técnicos de informática para entender os manuais dos produtos e as informações existentes nos sites especializados e dos fabricantes. Mas é preciso também conhecer os termos populares (normalmente imprecisos) usados no comércio e quase sempre pelos usuários. Um bom técnico precisa conhecer ambos os termos.

Muitos aprendem errado desde o início, mas nunca é tarde para conhecer o certo. Profissionais como professores e técnicos têm não somente a obrigação de conhecer os termos corretos, mas também de usá-los no dia-a-dia e divulgá-los entre os usuários.
 
Módulo de memória e pente de memória

O termo pente de memória  surgiu na década de 1980, quando chegaram ao mercado os módulos SIPP. Eram pequenos módulos de memória, bem menores que os atuais DIMM/168 e DIMM/184 e tinham 30 pequenas “perninhas” (falando tecnicamente, “pinos”) que eram encaixadas em soquetes na placa-mãe. Devido a essas “perninhas”, esses módulos pareciam um pente.

Logo depois foram criados os módulos SIMM/30 com o mesmo tamanho e os mesmos 30 contatos, porém, sem as “perninhas”. Depois disso vieram outras gerações de módulos: SIMM/72, DIMM/168 e DIMM/184 são os mais populares, mas ainda assim continuam sendo chamados popularmente de “pentes”.

Memórias DIMM

Em 1997, foram popularizadas as memórias SDRAM. Era época do processador Pentium MMX. Essas memórias eram fabricadas em chips que por sua vez formavam módulos chamados DIMM/168, pois tinham 168 terminais. No comércio foi convencionado chamá-las de memórias DIMM.

Por volta de 2000, chegaram ao mercado as memórias do tipo DDR SDRAM ou simplesmente DDR, formando módulos DIMM/184. Os nomes usados popularmente para essas memórias são DIMM e DDR. Note, entretanto, que as memórias DDR também usam módulos DIMM, porém, do tipo DIMM/184. Da mesma forma como as novas memórias DDR2 usam módulos DIMM/240.

Seria tecnicamente correto chamar essas memórias de DIMM/168, DIMM/184 e DIMM/240, respectivamente; ou, então, de SDRAM, DDR e DDR2.
 
CPU

Significa central processing unit. Este termo era usado para designar a parte dos computadores de grande porte responsáveis pelo processamento. Antigamente, era um módulo inteiro do tamanho de uma estante. Em computadores mais compacto, a CPU era uma placa inteira. Nos microcomputadores, a CPU é o processador. A placa na qual o processador é instalado é chamada placa-mãe ou placa de CPU. É errado dizer que esta placa é a CPU. É apenas a placa onde fica instalada a CPU.

Popularmente, o termo CPU é também usado para designar o gabinete onde ficam as placas, discos e fonte de alimentação. O computador é formado por monitor, CPU e teclado _ está errado usar esta afirmação. Aquela caixa metálica é também chamada de gabinete ou torre. Ambos os termos são imprecisos, pois o gabinete também pode ser simplesmente a caixa metálica vazia – como é comprada nas lojas – e gabinetes também são desktops (horizontais) e não somente verticais.

Todos os termos são aceitos, mas a rigor não poderia ser chamada de CPU, já que além de processamento também realiza armazenamento e entrada/saída de dados.

BIOS

BIOS significa Basic Input/Output System, ou seja, sistema básico de entrada e saída. É um programa armazenado em uma memória Rom (mais especificamente, uma flash Rom) localizada na placa-mãe. Já que trata-se de um sistema, é correto dizer o sistema, e não “a sistema”. Portanto, o termo “a BIOS” é uma expressão errada.
 
Saídas seriais, paralelas, USB…

Algumas interfaces do computador são usadas para saída de dados (exemplo: a da impressora); outras são usadas para entrada de dados (exemplo: a do teclado). A maioria das interfaces, entretanto, é usada tanto para entrada como para saída de dados: como as seriais e USB.

Até mesmo a porta paralela é bidirecional (desde o início dos anos 90) e serve para saída (no caso da impressora) para entrada (no caso de scanners, por exemplo) e para ambas as operações (por exemplo: no caso do zip drive paralelo).

Devido a essa variedade de opções, é errado usar temos como saída USB, saída paralela, saída serial. Seria melhor dizer portas ou interfaces, ao invés de termos imprecisos como entrada e saída.

Winchester

Nos anos 80, o disco rígido era chamado de winchester. Este termo começou, aos poucos, a cair em desuso e já em meados dos anos 90 ficou fora de moda. O termo aceito mundiamente é hard disk ou disco rígido. Alguém que o chame de winchester pode dar a impressão de que acaba de chegar de 1990 em algum tipo de máquina do tempo.

Resetar o BIOS

Clear CMOS é uma operação que consiste em deixar a memória de configuração CMOS da placa-mãe sem energia por alguns segundos, provocando seu apagamento. Usamos este recurso para apagar senhas no CMOS Setup ou desfazer configurações que impeçam o funcionamento do computador (por exemplo: a programação do FSB do processador com uma velocidade errada).

Ao constatar que a memória CMOS está zerada (mais precisamente, com dados inconsistentes, através de um Checksum), o BIOS automaticamente a recarrega com valores de fábrica. Não estamos,portanto, zerando ou resetando o programa BIOS e sim zerando a memória CMOS.

Apesar das pequenas imprecisões técnicas citadas aqui, nenhuma delas causa mau funcionamento do computador. Apenas recomendamos que os técnicos valorizem mais o uso dos termos técnicos corretos

GOSTOU DEIXE UM COMENTÁRIO