Joel  Spolsky é um dos maiores nomes na área de desenvolvimento de software. Simplesmente uma referência, seja pela sua experiência profissional na Microsoft ou pela sua extensa contribuição à comunidade técnica. Em 09 de agosto de 2000 ele escreveu um teste chamado The Joel Test: 12 Steps to Better Code (O teste do Joel: 12 passos para ter um código melhor). O propósito dele era estabelecer uma lista de perguntas simples e rápidas para medir o quão bom um time de desenvolvimento de software é. Confira:

1. Você usa controle de versão?
2. Você pode gerar uma build em um único passo?
3. Você faz builds diárias?
4. Você tem um banco de dados com os bugs registrados?
5. Você corrige os bugs antes de escrever código novo?
6. Você tem uma agenda atualizada?
7. Você tem uma especificação?
8. Os programadores possuem boas condições de trabalho?
9. Você usa as melhores ferramentas que o dinheiro pode comprar?
10. Você tem testadores?
11. Os novos candidatos escrevem código durante as entrevistas?
12. Você faz testes de usabilidade?

Enquanto o Software Engineering Institute da Universidade Carnegie Mellon tentou chegar à mesma resposta através de inúmeras teorias, o Joel foi preciso o suficiente nas suas perguntas para que as resposta fossem “sim” ou “não”. São 12 questões e cada “sim” corresponde um ponto a mais. Depois de responder todas perguntas do teste você poderá obter algumas conclusões com base no total de pontos atingido:

• 12 ou 11 pontos: situação perfeita, o time é bom;
• 10 pontos ou menos: problemas sérios, o time pode e deve melhorar.

É fácil perceber que o autor é exigente: ou o time é bom ou não. Não existe meio termo. Isto parece preciosismo demais, mas não é o foco do post, portanto não será discutido aqui. Outro fato importante é que, segundo o autor, grande parte das empresas existentes atingem no máximo 2 ou 3 pontos no teste, enquanto que empresas como a Microsoft chegam nos 12 pontos durante todo o processo de desenvolvimento.

E como o Visual Studio Team System ajuda a responder estas questões?

O Visual Studio Team System (VSTS) é uma ferramenta completa para o gerenciamento do ciclo de vida das aplicações, ou no termo original em inglês, Application Lifecycle Management (ALM). Isso significa que um projeto de software pode ser concebido do início ao fim utilizando o VSTS. Em outras palavras, a análise, desenvolvimento, gerenciamento, testes, etc, tudo isso está integrado de alguma forma com o VSTS. Agora que você já conhece alguns conceitos básicos, vamos responder as questões propostas pelo Joel.

Primeira questão: você usa controle de versão?

O controle de versão é um dos pré-requisitos mais básicos para o sucesso de um projeto. Sem ele os envolvidos não conseguem ver de forma rápida e eficiente quem fez alterações no código e também correm o risco de não conseguirem voltar para uma versão mais antiga do produto, além de diversos outros problemas. Para esta primeira questão a resposta com o VSTS é simples: use o Team Foundation Version Control (TFVC).

O TFVC é um poderoso controle de versão construído totalmente do zero, portanto não tem relacionamento algum com o Source Safe. Ele roda sobre o SQL Server e é integrado com as políticas de segurança do Windows, além de possuir todo o conjunto de requisitos básicos para um controle de versão: check-out, check-in, branches, labels, merges, histórico, changesets, etc.

Um ponto. Faltam só 11.

Segunda questão: você pode gerar uma build em um único passo?

Nesta questão o Joel não está se referindo à build do projeto através da ferramenta de desenvolvimento, aquela que usamos diversas vezes durante o dia para compilar e testar o código escrito. O que ele quer saber é se você consegue disponibilizar uma nova versão do software para o cliente em apenas um passo. Com o VSTS isso é possível e muito simples e rápido utilizando um Team Build Type.

O Team Build Type é o recurso do VSTS que permite definir novos processos de builds. Para responder a segunda pergunta do teste, deve-se criar um novo Team Build Type de acordo com o contexto atual (projeto em questão, forma de distribuição do software e outras políticas específicas). Desta forma, sempre que for preciso gerar uma build em um único passo você conseguirá iniciar todo o processo rapidamente e o servidor do VSTS junto com o MSBuild farão todo o resto do trabalho.

+1 ponto. Já temos 2.

Terceira questão: você faz builds diárias?

A geração diária de builds faz parte de um processo conhecido como Integração Contínua. Integrar continuamente significa garantir que todo o código hospedado no controle de versão estará funcionando quando for requisitado. Essa necessidade surgiu a partir do momento que diversos desenvolvedores começaram a trabalhar paralelamente no mesmo projeto. O VSTS responde a questão do Joel através das opções da build disponíveis no Team Build Type.

É possível definir que uma build será executada a cada check-in, semanalmente, a cada intervalo de tempo ou ainda diariamente. Toda esta configuração é visual no VSTS e pode ser feita rapidamente nas opções da build. Além do mais, não existe problema  ao agendar duas ou mais builds para um mesmo horário, pois o servidor do VSTS consegue gerenciar todas as requisições.

+ 1 ponto, já são 3!

Quarta questão: você tem um banco de dados com os bugs registrados?

A única certeza que temos sobre bugs no desenvolvimento de um software é que eles irão existir. Cabe a nós gerenciá-los de maneira eficiente e corrigi-los o quanto antes. Para resolver este problema, o VSTS possui um recurso chamado Work Item, ou em português, Item de Trabalho. Cada item de trabalho possui um tipo, sendo que um dos tipos disponíveis é o Bug. Portanto para registrar e gerenciar bugs, você pode e deve usar os itens de trabalho.

+ 1 ponto, somamos 4 no total.

Quinta questão: você corrige os bugs antes de escrever código novo?

A maneira mais fácil para que um programador corrija os bugs é fazer com que ele saiba que eles existem. Outro ponto fundamental é fornecer as informações necessárias para a reprodução do erro. Seguindo estes dois pré-requisitos, com certeza os bugs registrados serão corrigidos antes de escrever código novo. Da mesma forma que a questão anterior, neste caso o VSTS possui o Work Item do tipo Bug para gerenciar os erros do software.

+ 1 ponto, temos 5.

Sexta questão: você tem uma agenda atualizada?

Só desenvolver um software não basta, também é preciso entregá-lo e o mais importante: na hora certa. Uma agenda atualizada, segundo o Joel, ajuda você a decidir quais funcionalidades estarão disponíveis ou não na versão final. Em outras palavras, a agenda atualizada fornece informações sobre o vencimento de prazos, portanto você pode decidir por incluir na versão final do software somente os itens mais importantes e indispensáveis, postergando os outros para versões futuras.

O VSTS mais uma vez resolve este problema. Ele trabalha completamente integrado com o Microsoft Project, de tal forma que o desenvolvedor alimenta uma base de dados que também é utilizada pelo Project. Isso significa que o gerente de projetos terá toda a informação necessária disponível e atualizada a qualquer hora do dia, pois a integração é em tempo real e sem burocracias.

+ 1 ponto, estamos na metade, 6.

Sétima questão: você tem uma especificação?

Todo mundo acredita que escrever especificações é algo excelente, entretanto grande parte das pessoas não faz isso. Por quê? O fato é que muitas ferramentas para especificação de software são incompletas e não são integradas com o ambiente do desenvolvedor. O VSTS resolve justamente estes dois problemas: suporta a especificação de softwares e, quando necessário, também integra com ferramentas de terceiros.

Nas versões 2005 e 2008 do VSTS já estão disponíveis diversos recursos para especificação de software. Um deles é o diagrama de classes, que inclusive pode ser gerado automaticamente a partir do código fonte. O segundo é o Item de Trabalho, que pode armazenar texto e imagens sobre uma determinada tarefa. Além disso, a versão 2010 do VSTS terá suporte para os principais diagramas da UML e mais alguns específicos da ferramenta.

+ 1 ponto, temos 7.

Oitava questão: os programadores possuem boas condições de trabalho?

O Joel nesta questão se refere ao espaço físico do ambiente de trabalho. Segundo ele, há um ganho de produtividade muito grande quando as pessoas são posicionadas em lugares adequados, ou seja, com chances menores de interrupção, privacidade, etc. O VSTS não pode interferir nisto diretamente, porém ele traz outros fatores que melhoram as condições de trabalho de todos os envolvidos.

A ferramenta para desenvolvimento de software é integrada com a ajuda online da MSDN. Com alguns cliques o programador consegue as informações que precisa sem interromper outra pessoa. Outro aspecto importante é o foco no negócio e nos resultados, pois quem está envolvido no projeto sabe que existe uma excelente ferramenta dando suporte a todo o ciclo de vida da aplicação.

+ 1 ponto, e agora são 8.

Nona questão: você usa as melhores ferramentas que o dinheiro pode comprar?

É praticamente impossível desenvolver um sistema moderno sem o auxílio de uma ferramenta poderosa e com recursos avançados. Gerenciamento efetivo, comunicação fácil, agilidade no desenvolvimento e testes automatizados são só alguns exemplos do que é indispensável para ganhar tempo. Neste caso, o VSTS mais uma vez oferece uma solução completa e flexível de acordo com as necessidades do cliente.

O Visual Studio Team Suite, por exemplo, é o componente do VSTS usado por desenvolvedores, arquitetos e testadores. Todas as ferramentas que ele comporta são integradas entre si e simples de usar. No aspecto gerencial, o VSTS possui um grande número de relatórios, além de possibilitar o acesso de diversas informações pela web utilizando o Visual Studio Team System Web Access.

+ 1 ponto, 9 no total.

Décima questão: você tem testadores?

Segundo o Joel, ignorar a fase de testes é perder dinheiro. Pare e pense: se um programador recebe $ 100 por hora e um testador $ 30, com qual deles o custo é menor para executar os testes? Não ter testadores é uma falsa economia, pena que muitas vezes as pessoas não percebem isso ou acham que é tempo desperdiçado. Com o VSTS e os recursos de testes disponíveis é diferente, pois há mais agilidade no processo e consequentemente o custo é menor ainda.

O testador tem à disposição uma série de maneiras para realizar os testes usando o VSTS. Uma delas é o Web Test, que permite gravar e executar por indeterminadas vezes o acesso a um site, é o que conhecemos como simulação de acesso. Outra maneira é com o Load Test que simula diversos usuários acessando o servidor simultaneamente, também conhecido como Teste de Carga. Tudo isso e muito mais está disponível no Visual Studio Team Suite.

+ 1 ponto, 10! Faltam só 2.

Décima primeira questão: os novos candidatos escrevem código durante as entrevistas?

Você contrataria um mágico sem pedir a ele que demonstrasse algum truque? É isso que o Joel quer saber com esta questão. Segundo ele, um número cada vez maior de programadores é contratado com base em entrevistas simples, que dependem somente de uma boa conversa. O pior de tudo é que frequentemente os entrevistadores fazem questionamentos já conhecidos, como aquelas perguntas básicas “por que você escolheu a empresa xyz?” ou “o que te motiva a trabalhar na área de zyx?”.

O VSTS pode ajudar também no processo da entrevista. Se for um candidato a programador, ele pode ser posto à frente do Visual Studio Development Edition e a partir daí deverá resolver uma série de problemas. Se for um aspirante a testador, a versão Visual Studio Test Edition será muito útil para conhecer o perfil investigativo do profissional. O mesmo acontece para arquitetos, DBAs, gerentes, analistas, etc. Todos eles têm um papel bem definido durante o ciclo de vida de uma aplicação e o VSTS possui ferramentas focadas para cada um deles.

+ 1 ponto. 11! Falta só 1.

Décima segunda questão: você faz testes de usabilidade?

Jacob Nielsen, uma das maiores referências sobre usabilidade na web, fala e escreve muito sobre um conceito chamado hallway usability testing. Em português a tradução é algo parecida com teste de usabilidade feito por pessoas aleatórias. Segundo ele, cinco pessoas é o número suficiente de testadores aleatórios para garantir que a usabilidade do site esteja em perfeitas condições. E o VSTS pode ajudar você a garantir um ótimo nível de usabilidade em suas aplicações.

Para projetos web hoje é indispensável uma interface rica para o usuário. O VSTS oferece recursos como Silverlight, componentes AJAX e bibliotecas Java Script integradas na ferramenta de desenvolvimento. Além disso, possui suporte para edição de código HTML e um editor robusto e flexível para CSS. Todas estas tecnologias unidas proporcionam ao usuário final uma experiência fantástica, pois dão uma base sólida para a criação de um site que utiliza os melhores conceitos de usabilidade.

+1 ponto, chegamos no nível máximo: 12!

Conclusão

O VSTS é uma solução completa para qualificar qualquer time de desenvolvimento de software. Os recursos que ele oferece para desenvolvedores, testadores, gerentes, etc, são excelentes para a criação de qualquer projeto. E o mais importante: tudo em um único conjunto de ferramentas trabalhando de maneira integrada e inteligente para facilitar as tarefas do dia-a-dia.

Fonte: Marcos Dell Antonio

Uma das grandes jogadas na programação é otimização de tempo, geração de códigos limpos e sem erros. Como quem programa é uma pessoa sujeita a erros, cansaço, falta de atenção, etc o código sempre está sujeito a problemas. Uma das formas de evitar esses problemas é a utilização de geradores de código. Na empresa onde trabalho tem um programador (Romulo Reis) que desenvolveu uma ferramenta muito boa para geração de códigos chamada DAL Creator. Segue abaixo a descrição de suas funcionalidades:

É um programa que cria automaticamente as classes de acesso à dados no modelo “Data Access Layer” (Aplicação em camadas ). Todo o código com CRUD é criado em segundos, bastando o usuário setar as configurações de conexão e as tabelas a serem mapeadas.

Porque utilizar uma aplicação distribuída em camadas?
Principais beneficios: A camada de aprensentação contém apenas o código de UI, ela não acessa o banco de dados diretamente. Migração facilitada de um BD para outro.Reaproveitando de código: o código de acesso a dados (e BLL), por exemplo, não é replicado caso tenhamos vários tipos de aplicativos cliente ou caso tenhamos múltiplas interfaces fazendo uso dos mesmos objetos;
Manutenção facilitada: como os aplicativos estão em camadas, se houver um erro ou for necessário fazer uma manutenção / correção, normalmente apenas uma camada é afetada, o que também facilita o deploy; E finalmente, estaremos usando o melhor da POO.
Principais caracteristicas do DAL Creator .net

• Diminui drasticamente o tempo de desenvolvimento.
• Código mais enxuto e com mínimas possibilidades de erros.
• Acesso à dados totalmente via Stored Procedures.
• O código gerado simples e intuitivo, facilmente customizável.
• Query Builder integrado para criação de consultas avulsas.
• Programação totalmente orientada à objetos (POO).
• Compatível com os frameworks 1.1, 2.0, 3.5
• Gera classes em Visual C# e Visual Basic .NET
• Suporte à MS SQL Server 2005/2005 Express
• Totalmente FREE.

O site da aplicação é: Dal Creator

Em minhas andanças entre as tecnologias de desenvolvimento web me deparei com o MVC da Microsoft. A medida que for me aprofundando sobre a tecnologia escreverei mais sobre o assunto. Inicialmente postarei aqui o conceito de MVC.

O modelo MVC é muito usado em aplicações para Web, onde a View é geralmente a página HTML, e o código que gera os dados dinâmicos para dentro do HTML é o Controller. E, por fim, o Model é representado pelo conteúdo de fato, geralmente armazenado em bancos de dados ou arquivos XML.

Ainda que existam diferentes formas de MVC, o controle de fluxo geralmente funciona como segue:

1. O usuário interage com a interface de alguma forma (por exemplo, o usuário aperta um botão)
2. O Controller manipula o evento da interface do usuário através de uma rotina pré-escrita.
3. O Controller acessa o Model, possivelmente atualizando-o de uma maneira apropriada, baseado na interação do usuário (por exemplo, atualizando os dados de cadastro do usuário).
4. Algumas implementações de View utilizam o Model para gerar uma interface apropriada (por exemplo, mostrando na tela os dados que foram alterados juntamente com uma confirmação). O View obtém seus próprios dados do Model. O Model não toma conhecimento direto da View.
5. A interface do usuário espera por próximas interações, que iniciarão o ciclo novamente.

(fonte : http://pt.wikipedia.org/wiki/MVC)

Alguns podem estranhar que eu esteja trabalhando com .Net. Mas não tem nada de estranho, para quem não sabe mudei de trabalho.
Estou em processo de familiarização com a linguagem com seus erros, funções, particularidades, etc.
Uma das coisas que estou me adaptando nesse momento é em relação às mensagens de erro. Fiz um apanhado na internet sobre algumas mensagens de erro comuns no .NET e estou colocando aqui.
Enquanto eu for encontrando informações que eu julgue importantes eu vou postando.

• Comandos de Manipulação de Programas Fontes
CHECK
Checa a sintaxe do objeto atualmente na área de trabalho. Pode ser substituído por
apenas ‘C’.

SAVE
Salva o programa fonte. Pode-se especificar o nome desejado logo após o comando. Pode
ser substituído por apenas “SA”.

PURGE
O comando ‘PURGE’ é usado para deletar um ou mais programas fontes do Natural
System File. O conteúdo existente em work-área não é alterado.
Se o program-name não for especificado, será exibido um mapa com os programa fontes
existentes no Natural System File, para especificação individual.

• Comandos de Manipulação de Programas Objetos
CATALOG
Cataloga o programa fonte da área de trabalho. Este comando checa a sintaxe e grava a
versão executável do programa. Não grava o fonte. Pode ser substituído por apenas ‘CAT’.

UNCATALOG
Apaga apenas o módulo carga, mantendo o módulo fonte.

• Comandos de Manipulação Mista de Programas
STOW
Checa a sintaxe do programa fonte da área de trabalho, salva e cataloga. Este comando
executa internamente as funções dos comandos CHECK, SAVE e Catalog. Porém, ele somente
salva o programa fonte se este não contiver nenhum erro.

SCRATCH
Apaga o fonte e o módulo carga informado logo após o comando. Pode ser substituído por
‘SCR’.

• Comandos de Transferência/Limpeza de Work-Area
READ
Lê e transfere para a área de trabalho o programa fonte definido após o comando.

CLEAR
Limpa a área de trabalho.

RENUMBER (n)
Renumera as linhas do programa fonte que estiver na work-area, em incrementos de 10.

SCAN
Pesquisa um determinado ‘STRING’ dentro de um ou de todos os objetos de uma
biblioteca.

• Comandos de Execução de Programas
RUN
Executa o programa atualmente da área de trabalho. O comando compila o programa
antes de executá-lo. Pode ser substituído por apenas “R”.

• Comandos de Processos Especiais
GLOBALS
Exibe menu que está definido com uma série de ações e atributos que afetam tanto o
resultado dos comandos como o resultado das instruções.
As principais funções dos parâmetros são:
· Definir característica dos relatórios e mapas;
· Estabelecer limites p/quantidades de registros lidos, de páginas de relatórios, etc.;
· Definir caracteres de controle.

HELP
Permite a exibição de mensagens de erro e comandos do Natural. Também pode ser
acesso teclando “?”. Ambas as opções permitem a passagem do código diretamente (? 3148, por
exemplo, exibe o conteúdo do código de erro 3148).

PROFILE
Mostra a profile de segurança corrente para o usuário.

Fonte: Curso Básico de Programação Natural escrito por Luciano Rogério Perdigão Braga sob a licença GNU – Free Documentation License, Version 1.1

LOGON
As bibliotecas são estabelecidas pela instrução ‘LOGON’
LOGON | biblioteca |
FIN
A instrução ‘FIN’ encerra uma sessão Natural, devolvendo o controle ao sistema de onde o
Natural foi invocado.
LIST
A instrução ‘LIST’ invoca um utilitário para listagem de diretórios de bibliotecas
(fontes/objetos), listagem de programas e de DDM’s.
Pode-se chamar um ‘MENU’ das várias funções do LIST através do formato ‘LIST *’, ou
chamar diretamente a função, como veremos a seguir:

EDIT
A instrução ‘EDIT’ exibe a cópia do programa (ou outro tipo de objeto) na ‘work-area’,
ficando inalterado o original no system file até que seja dado um comando de atualização
(‘SAVE’ ou ‘STOW’).
Pode-se chamar um ‘MENU’ das várias funções do LIST através do formato ‘EDIT *’, ou
chamar diretamente a função, como veremos a seguir.

E(DIT) | Object-Type| |Object-Name|
E(DIT) | Object-Type| * lista tudo referente ao ‘object-type’
Se não for especificado o ‘object-name’, será editado o conteúdo existente na ‘work-área’;
se não houver nenhum conteúdo na ‘work-área’, o modo de edição permitirá a criação de um
programa (ou qualquer tipo dos objetos especificados) sem o controle do compilador.

Fonte: Curso Básico de Programação Natural escrito por Luciano Rogério Perdigão Braga sob a licença GNU – Free Documentation License, Version 1.1

Comandos referentes a linha devem ser digitados no início da linha. Alguns comandos de linha
não podem ser digitados simultaneamente, pois o Natural não interpreta todos os comandos ao
mesmo tempo.

· ..I – Insere uma linha.
· ..I(n) – Insere “n” linhas.
· ..J – Join. Concatena a linha corrente com a linha de baixo.
· ..M – Move a linha. Colocar o cursor na linha de destino e teclar <ENTER>.
· ..P – Abre o editor de regras de validação do mapa.
· ..Q – Sair do editor de mapas.
· ..R – Duplica a linha.
· ..C – Centraliza a linha corrente. Deve Ter sido dado <ENTER> previamente na linha
a centralizar.
· ..D – Deleta a linha.
· ..D(n) – Apaga as “n” linhas, contando com a linha atual.
· ..E – Permite a edição de campos em tela cheia.
· ..Fc – Preenche a linha inteira com o caracter “c”.

Fonte: Curso Básico de Programação Natural escrito por Luciano Rogério Perdigão Braga sob a licença GNU – Free Documentation License, Version 1.1

Tenho trabalhado ultimamente em um projeto que utiliza ASP.NET. Apesar de já ter feito o curso da Microsoft S2B sei que aprendemos sobre qualquer linguagem de programação à medida que programamos nela.

Em uma oportunidade me deparei com o seguinte erro: You tried to assign the null value to a variable that is not a variant data type.

Como ainda não tinha prática com a linguagem, demorei um pouco para encontrar a solução. Conversando com outros desenvolvedores eles disseram ter passado pelo mesmo problema e também com certa dificuldade em resolver a intempérie. Por isso resolvi compartilhar com vocês a solução, espero que seja  bem útil.

Estou trabalhando com um “banco de dados” Access e ao criar um SQLDataSource temos como opção clicar em Advanced SQL Generation Options como aparece na tela abaixo:

Essa opção faz com que o Visual Studio (utilizo a versão 2008) gere automaticamente as strings de inserção, exclusão e alteração dos dados na tabela. O problema todo está justamente aí. Ao gerar o insert o Visual Studio informa, em sua string de inserção, que um dos parâmetros a serem informados é a chave primária. Mas como no meu caso a chave primária é autoincrement ela não deve ser informada no insert.

Para resolvermos o caso devemos procurar no código por: “InsertCommand” e retirar dali a chave primária de sua tabela. Logo depois retire “?” relativa ao parâmetro passado pela chave primária.

Minha string era assim:
InsertCommand=”INSERT INTO [tbPort] ([idTerminal], [idTerminalPort], [Berth]) VALUES (?, ?, ?)”

Corrigindo ficou assim:
InsertCommand=”INSERT INTO [tbPort] ([idTerminalPort], [Berth]) VALUES (?, ?)”

A segunda e última etapa da correção consiste em retirar da lista de parâmetros de inserção o campo da chave primária. Segue o meu exemplo:
Antes da correção:
<InsertParameters>
<asp:Parameter Name=”idTerminal” Type=”Int32″ />
<asp:Parameter Name=”idTerminalPort” Type=”Int32″ />
<asp:Parameter Name=”Berth” Type=”String” />
</InsertParameters>

Depois da correção:
<InsertParameters>
<asp:Parameter Name=”idTerminalPort” Type=”Int32″ />
<asp:Parameter Name=”Berth” Type=”String” />
</InsertParameters>

TAMANHO E FORMATO DOS CAMPOS ADABAS

(N) Numerico – de 1 até 29 bytes
(B) Binario – de 1 até 126 bytes
(A) Alfanumerico – de 1 até 253 bytes
(F) Ponto Fixo – até 4 bytes
(G) Ponto Flutuante – 4 a 8 bytes
(P) Decimal Compactado – até 15 bytes
(U) Decimal Não Compactados – até 29 bytes

TIPOS DE CAMPOS

ELEMENTAR – Contém apenas um valor de um registro.

MULTIPLO – Pode possuir até 191 ocorrencias em um mesmo registro, onde ele pode assumir diversos valores dentro de uma ocorrência de registro.

GRUPO – Consiste em vários campos elementares consecutivos da FDT combinados em apenas um. Dessa forma pode-se acessar os campos com mais facilidade melhorando o desempenho quando devidamente utilizado durante o processo de manipulação de dados.

PERIODICO – É um campo que possibilita obter diversas ocorrencias dentro de uma mesma ocorrencia, pode ser repetido até 99 vezes.

SUPERDESCRITOR – É a combinação de dois ou mais campos – pode ser completo usado todos os campos ou partes dele – um campo Alfa de 10 posições, no super você pode utilizar os dez ou o nono campo (ou menos como a quarta, quinta posição) – fica a critério do analista – importante destacar – um superdescritor tem que ter mais de dois campos – se for somente um campo pode ser Hiperdescritor – o que o super descritor faz, ele pega todos os campos contidos nele e cria uma lista uma lista invertida com o endereço daquele registro, assim sendo mais rapida a consulta.

REGISTRO – É um conjunto de campos constitui um registro Adabas, cada registro esta associado a um número seguencial interno (ISN) assinalado e administrado pelo Adabas.

BLOCO – Um bloco constitui um conjunto fisico de registros e possui tamanho fisico em função do tipo de disco utilizado. Cada vez que o Adabas transfere informações do disco para a memoria (ou vice e versa) é através do bloco fisico.

ISN – Internal Seguence Number – (Numero Seguencial Interno) Consiste num número seguencial interno associado a cada registro que entra no banco de dados Adabas, é único por arquivo, toda a manipulação de registro pelo Adabas base no ISN. O ISN tanto pode ser gerado pelo Adabas como pode ser assinalado pelo usuário.

RABM - Relative Block Number – (Numero Relativo do Bloco) O Adabas associa aos blocos dos data sets (ASSO, DATA entre outros) um número seguencial, o RBN é convertido em endereço fisíco do disco pelo método de acesso do sistema operacional (BDAM em IBM) antes de ser efetuada a operação de entrada e saida.

EXTENT – Um determinado Extent consist num conjunto de blocos fisícos contigos (de disco) alocados para uma determinada função Adabas.

FILE – (ARQUIVO) Um arquivo Adabas consiste num conjunto de blocos de dados do usuário e pode ser constituido de diversos extents fisicos.

BANCO DE DADOS – Um banco de dados Adabas consiste em um ou mais arquivos (FILE) de dados do usuário, e também todas os dados e tabelas necessarias ao Adabas na Administração do banco de dados. O banco Adabas é composto por alguns data sets. – ASSO / DATA / WORK – (PLOG / CLOG)

ASSO – O associator que contém as informações de controle para o administrar os dados dos usuários, neste data set onde estão as localizações dos dados, para melhor utilização dos discos pode ser comprimido os dados. Contém basicamente os dados de.

01 – Listas Invertidas (de superdescritor, descritor.
02 – Conversor de endereços (Tabela de ISN e RBN)
03 – Tabela de descrição de dados – FDT
04 – Outros dados de controle como memória disco disponivel, quantidade de arquivos carregados, controle de utilização de ISN entre outros.

DATA – Data Storage onde estão os dados dos usuários, o Adabas armazena os dados de formar comprimida, diminuindo o indice de utilização de memoria em disco.

WORK – Este data set pelo nucleo do banco Adabas como arquivo de trabalho que executa as tarefas abaixo:

01 – Proteção e recuperação do banco de dados.
02 – Armazenamento intermediario das listas de ISN proveniente de pesquisas.
02 – Area intermediaria para operação dos algoritimos de pesquisa.

PLOG – (Protection Log) Este data set é onde ficam armazenadas as alterações feitas no banco Adabas (é utilizada em bancos de Produção) – quando o analista descobre que alguem deletou um registro é usando o Plog que se recupera o arquivo deletado do banco.

CLOG – (Command Log) Este data set é para fazer estatisticas do banco, como exemplo de comandos de pior duração, ou de programas de consomem mais recursos entre outros, tem diversar softwares que coletam estas informações e fazem alguns relatórios bem interessante – vou passar dois, o REVIEW é da software AG (caro mais muito bom) e o TRIM da Treehouse Software muito interessante e não tão caro.

FCB – (Bloco de controle de arquivo) – Para cada arquivo do banco existe uma FCB. Contém informações sobre área de estensão e de áreas livres.

FDT – Tabela de descrição de campos – Uma FDT corresponde a descrição dos campos que compõem cada FILE (arquivo) e corresponde ao esquema dos campos do campo no banco. Como os dados são compactados e há supressão de campos brancos e nulos, a FDT é frequentemente consultada quando uma vez obtida o valor de ISN e RABN, dai se efetua o varredura sequencial dos campos de registros lógicos. Na FTD estão em detalhes a descrição fisíca de todos os campos.

Fonte: www.mainframes.com.br

Um objeto Natural nada mais é do que um componente de um sistema. Os diversos tipos de objetos Natural são:
· COPYCODE: Pedaço de código fonte, que pode ser aproveitado em vários programas. Único objeto Natural que não é compilado. Nos programas aonde o COPYCODE vai ser aproveitado, através do comando INCLUDE, ele será compilado, juntamente com o programa.
· GLOBAL:  Objeto utilizado para definição de variáveis. Todos os objetos que se referenciarem a uma GLOBAL, terão as mesmas variáveis, e estas manterão os valores após o término de um objeto, permitindo que um objeto altere valores e outro reconheça as alterações.
· LOCAL: Objeto utilizado para definição de variáveis. A diferença entre uma LOCAL e uma GLOBAL é que valores das variáveis locais somente serão reconhecidos pelo objeto onde foram declaradas, deixando de existir quando do término do mesmo.
· PARAMETER: Objeto utilizado para definição de variáveis que serão utilizadas entre programas e subprogramas.
· MAP: Utilizado para entrada e exibição de dados. Permite a definição de Regras de Validação para os campos, inclusive com acesso à Base de Dados.
· Helproutine:  Tipo de objeto que permite ser definido como ajuda a um campo de entrada de dados. Quando o cursor estiver posicionado num campo e for teclado “?”, será chamada a HELPROUTINE que estiver associada ao campo.
· PROGRAM: Principal objeto Natural. É a partir dele que são chamados os outros componentes.
· SUBPROGRAM (N): Objeto chamado por outro, com passagem de parâmetros, que permite o retorno de dados ao objeto chamador.
· SUBROUTINE: Uma sub-rotina é um pedaço de código geralmente executado mais de uma vez ou de diversas partes de um programa. Pode ser interno, definido dentro de um programa ou fora dele (externo). Quando se escolhe a segunda opção, o tipo de objeto que conterá as sub-rotinas é o SUBROUTINE.
As letras sublinhadas nos nomes dos objetos podem ser utilizadas logo após o comando EDIT, evitando a digitação completa do tipo de objeto.

Fonte: Curso Básico de Programação Natural escrito por Luciano Rogério Perdigão Braga sob a licença GNU – Free Documentation License, Version 1.1