Os Seis Véus da ADA - Ciência e Tecnologia da Programação

Publicado em:
Personal Computer World
(1ª parte em Setembro de 1988)
(2ª parte em Outubro de 1988)
Os Seis Véus da ADA
Fernando Brito e Abreu
INESC
"Tenho comigo seis servos leais
(que me ensinaram tudo o que aprendi)
Os seus nomes são: O Quê, Porquê e
Quando, Como, Onde e Quem. "
Rudyard Kipling
Prémio Nobel da Literatura (1907)
Resumo
Mais conhecidos pelos seis W's (What, Why, When, hoW, Where, Who), este
tipo de abordagem globalizante parece particularmente apropriada, quando
nos nossos meios académicos e industriais existe uma certa indiferença,
face a esse espectacular movimento em curso nos Estados Unidos e na
Europa em torno da linguagem ADA.
É a combinação das características intrínsecas da linguagem, com o
processo da sua própria criação, contínuo desenvolvimento dos seus
ambientes de apoio ao aperfeiçoamento, bem como a sua aceitação, por
uma comunidade internacional de utilizadores (quer na Universidade, quer
na Industria), investigadores, gestores e governos que fazem com que a
ADA não seja apenas mais uma linguagem.
A intenção deste artigo é a de levantar, um a um cada um dos véus que a
encobrem, para revelar uma ADA ainda pouco conhecida entre nós, mas que
por certo vai dar ainda muito que falar, escrever, trabalhar e também ganhar!
1. A linguagem
Porquê?
Em 1975 mais de 400 linguagens e dialectos eram utilizados nos sistemas em
desenvolvimento e em uso no Departamento de Defesa dos Estados Unidos (DoD). Mais de
metade dessas linguagens eram "assembly". Como resultado dessa proliferação, havia uma
tremenda escassez de ferramentas de desenvolvimento para cada uma das linguagens, além
das grandes dificuldades de portabilidade do software entre computadores diferentes, evitando
a partilha entre diversos projectos. Uma situação idêntica prevalecia quanto aos
programadores, muitos dos quais se tornavam altamente especializados numa dada
linguagem, tornando-se difíceis de transferir ou partilhar experiências com outros projectos.
Outros sintomas do problema eram que os projectos de desenvolvimento de software no DoD
não conseguiam cumprir prazos, ultrapassavam o orçamento previsto, eram pouco fiáveis e
muitas vezes não obedeciam às especificações originais. A somar-se a isto, as crescentes
despesas com a manutenção de sistemas já instalados.
Os custos de um tal estado de coisas eram enormes tanto mais que o DoD é o maior
"consumidor" mundial de software, por forca dos seus aviões, navios, submarinos, tanques,
mísseis, satélites, bem como sistemas de comando, controlo e espionagem. Os custos anuais
de software para tais sistemas eram de 4 mil milhões de dólares em 1980, 10 mil milhões de
dólares em 1986 e espera-se que atinjam os 30 mil milhões de dólares no princípio da década
de 90 [16]. Em 1985 o DoD estimava já as poupanças anuais devidas ao uso da ADA em cerca
de um milhão e meio de dólares [24].
Como? Quem? Quando? Onde?
Para reverter a situação vigente no DoD decidiu-se estudar a possibilidade de eliminar
gradualmente a profusão de linguagens em uso, em favor da utilização de uma única
linguagem de alto nível. Essa decisão embora óbvia hoje em dia, não o era na altura, pois
levantava sérios problemas técnicos, económicos e políticos. Mais de dez anos depois,
subsistem ainda hoje alguns espíritos renitentes [6],[14], o que per si nos faz pensar na
complexidade do problema em 1975.
Foi criado o "High Order Language Working Group" (HOLWG) composto por representantes
dos diversos ramos das forcas armadas e instituições de defesa americanas, com o intuito de
prosseguir a investigação sobre o problema. Em 1975 o Dr. David A. Fisher do Institute for
Defense Analyses (IDA) foi nomeado para criar uma especificação dos requisitos que deveria
preencher uma linguagem de alto nível que correspondesse às necessidades dos sistemas
computacionais embutidos ("embedded computer systems") em uso no DoD. Exemplos destes
sistemas, são submarinos, aviões, estacões de comutação de mensagens, equipamentos de
laboratório, sistemas de controlo de tráfego aéreo, etc. O Dr. Fisher produziu um documento de
requisitos denominado "Strawman", o qual foi enviado para um grande número de pessoas
interessadas, quer na comunidade militar, quer na civil. Foram recebidos os comentários a
esse documento, tendo sido publicada uma versão revista denominada "Woodenman", nos
finais de 1975. No ano seguinte foi publicada uma terceira versão do documento, o "Tinman".
Durante 1976, foram analisa- das as 23 linguagens mais utilizadas no DoD, tendo-se concluído
sem surpresa que nenhuma delas preenchia todos os requisitos descritos no "Tinman".
Contudo três das linguagens - Pascal, PL/1 e Algol 68 - foram indicadas como bons pontos de
partida para a criação da nova linguagem.
Em 1977 o DoD convida várias instituições a apresentarem propostas para o projecto da
linguagem, com base numa nova versão dos requisitos, o "Ironman". Das 17 respostas são
escolhidas 4 para competir entre si. Na tentativa de manter o anonimato na avaliação são-lhes
atribuídas cores:
•
•
•
•
VERDE para a Cii Honeywell Bull (França),
VERMELHA para a Intermetrics (Boston)
AZUL para a Softech
AMARELA para a Sri International.
Os projectos preliminares das quatro equipas foram analisados por vários grupos de estudo,
tendo-se escolhido entre eles o projecto VERDE e o AMARELO como sendo os mais
promissores. Aos dois finalistas foi dado mais um ano para aperfeiçoarem os projectos em face
da especificação final dos requisitos então publicada, o "Steelman".
A linguagem a criar era necessariamente grande dada a extensão dos requisitos expressos no
documento.
A 2 de Maio de 1979, após discussão pública dos dois projectos finalistas, o projecto VERDE
(Cii Honeywell Bull) liderado por Jean Ichbiah, é declarado vencedor e o DoD anuncia que a
nova linguagem será conhecida por ADA em honra de Augusta Ada Byron, Condessa de
Lovelace (1815-1852), assistente e patrocinadora de Charles Babbage, considerada a primeira
programadora da história (vide apêndice A).
Foi então publicado um documento com as especificações da linguagem, designado por
"Preliminary ADA" e outro documento, denominado "Rationale", em que se descrevem as
razões de ser de muitas das características específicas da linguagem. Cerca de 80 equipas de
programadores, usaram o "Preliminary ADA" para escrever (no papel, pois por essa altura não
havia ainda nenhum compilador) partes de sistemas que já tinham codificado noutras
linguagens.
Em Outubro de 1979 realiza-se em Boston um Workshop em que são debatidos os resultados
dessas equipas e os de um grupo de peritos em linguagens denominados os "Distinguished
Reviewers", reunindo-se um total de cerca de 900 comentários detalhados. Seguiu-se um
período de revisão da linguagem em que participaram universidades, indústrias e software
houses de 15 países diferentes, num total de mais de 7000 contribuições [16] e que
culminaram com a publicação em Julho de 1980 da primeira versão definitiva da linguagem.
Esta versão foi proposta como norma ao American National Standards Institute (ANSI).
O processo de normalização pelo ANSI levou mais de dois anos e resultou numa série de
pequenas alterações à linguagem. A maior parte destas alterações foi pequena, mas de subtil
significância, especialmente para a escrita do compilador [3]. Em Fevereiro de 1983, foi
publicado pelo ANSI como norma, o "Language Reference Manual". O DoD, que juntamente
com o ANSI, também publicou a norma da linguagem (military standard MIL-STD-1815A),
declarou que a partir de 1 de Julho de 1984, a utilização da ADA era condição imprescindível
em todos os novos desenvolvimentos e actualizações dos sistemas de defesa. Mais ainda, não
seriam aceites subconjuntos ou extensões à linguagem. O AJPO (ADA Joint Program Office),
em delegações nos EUA, Franca, Alemanha Ocidental e Reino Unido, ficou encarregue dos
processos de validação dos compiladores ou interpretadores a desenvolver. Sem esta
validação, que envolve a efectivação de mais de 2500 testes, os compiladores e
interpretadores não podem usar o nome ADA (que é uma marca registada do DoD).
Iniciou-se então a corrida às validações e, em 11 de Abril de 1983, dois meses apenas depois
da norma ANSI (e DoD), foi validado o interpretador ADA/ED desenvolvido na New York
University. O segundo sistema foi validado em 14 de Junho do mesmo ano, tratando-se do
compilador da Rolm Corporation de Santa Clara na Califórnia.
Em Agosto de 1986 já existiam 50 compiladores validados, mais de 60 organizações nos EUA,
Europa e Japão estavam envolvidas no projecto de compiladores ADA e produtos
relacionados, quer para computadores militares quer para modelos comerciais. Alguns
exemplos são a Digital Equipment Corporation, Data General, IBM e Honeywell. Curiosamente,
a Intermetrics e a Softech duas das quatro empresas que ficaram para trás no concurso para o
desenvolvimento da linguagem (que como já foi dito foi ganho pela Cii Honeywell Bull em
Franca), aparecem agora com os seus compiladores ADA, utilizando a conhecida técnica "se
não consegues vencê-los junta-te a eles!"
Muitas das vezes, os computadores utilizados no desenvolvimento de programas ("host"), são
diferentes das máquinas a que se destina ("target systems") o código máquina gerado pelos
compiladores. Exemplos de computadores ("host") em que têm sido instalados os
compiladores são Apollo, Sun, Control Data, Data General, Gould, Digital, Hewlett Packard,
Honeywell, IBM, Rational, Rolm e Tektronix. Exemplos de máquinas a que se destina o código
produzido são sistemas incluindo processadores da família Intel (86, 186, 286, 386), da família
Motorola MC 68000, da família Zilog Z8002 ou máquinas MIL-STD-1750 (Norma Militar), para
além obviamente, de código produzido para os próprios computadores de desenvolvimento,
para efeitos de teste.
Em 1986 a International Organization for Standardization (ISO) aceita também o ADA como
norma [23].
2. O ambiente de desenvolvimento
Porquê?
Durante as fases de especificação e desenvolvimento da linguagem, tornou-se cada vez mais
claro que para além do compilador e das ferramentas de desenvolvimento habituais (editores,
debuggers, etc.), algo mais deveria ser feito para que a nova linguagem permitisse obter as
esperadas profundas alterações no ciclo de vida do software produzido. Isto é tanto mais
verdade quanto se sabe que a ADA foi particularmente concebida para a implementação de
sistemas grandes e complexos que podem exceder as 500 mil linhas de código [29]. Pensando
em programação modular, se cada módulo não exceder, como e de boa pratica, as 100 a 250
linhas de código, teremos 2 a 5 mil módulos diferentes! A integração de uma tão grande
diversidade de módulos ("programming-in-the-large", na literatura em língua inglesa), de forma
a construir um "sistema", e uma actividade intelectual completamente diferente e bastante mais
complexa que o projecto de cada um dos módulos individualmente. Para alem disso, a
linguagem ADA tem uma grande quantidade de capacidades, dificilmente abarcáveis na
totalidade por um programador normal. A utilização de todas essas capacidades apenas por
super-programadores, não e certamente a solução mais viável. Nem o e também,
convencionar a utilização de um subconjunto da linguagem, cujos limites os programadores
não compreenderão realmente e que, acidentalmente excedidos, poderão ter consequências
imprevistas ou mesmo catastróficas. A solução passa portanto pela utilização de um ambiente
de apoio ao desenvolvimento de software, que inclua, para alem das ferramentas habituais,
outras que auxiliem na descrição, analise, organização e gestão dos muitos módulos que
constituem os grandes sistemas, bem como outras ferramentas que ajudem o programador a
dominar as complexidades da linguagem.
Como? Quem? Quando? Onde?
Desde os fins dos anos 70 que o DoD tinha encarregue uma comissão de definir o conjunto de
requisitos que um ambiente de apoio ao desenvolvimento em ADA deveria preencher. Desse
trabalho resultaram duas versões preliminares, o Sandman e depois o Pebbleman. Em
Fevereiro de 1980 foi publicado o Stoneman, documento final dos requisitos sobre o qual
adiante se falara.
Em Janeiro de 1982 o Ada Joint Program Office (AJPO) iniciou um projecto com a finalidade
de desenvolver as interfaces através das quais as ferramentas de um ambiente de apoio ao
desenvolvimento em ADA (APSE) pudessem comunicar com o sistema operativo, entre si e
com uma base de dados comum. Esse projecto foi levado a cabo por duas equipas, uma
governamental, o KAPSE Interface Team (KIT) e outra representando a industria e
universidades, o KAPSE Interface Team from Industry and Academia (KITIA). Em Novembro de
1985 foi publicada uma primeira versão das interfaces definidas no KAPSE, com o nome de
CAIS (Common APSE Interface Set). Em Agosto de 1986 já existiam nove empresas
desenvolvendo protótipos do CAIS [16].
Dez países da NATO (Espanha, Franca, Bélgica, Holanda, Alemanha, Itália, Noruega, Reino
Unido, Estados Unidos e Canadá) assinaram em Marco de 1986, uma declaração de intenções
no sentido da reunião de esforços no âmbito dos ambientes ADA. Para alem de cooperação no
desenvolvimento de protótipos do CAIS e representação no KIT de todos os signatários,
pretendia-se fazer uma analise comparativa entre o CAIS e o PCTE (Portable Common Tool
Environment), um esforço europeu em que tem estado envolvidas a Siemens, Olivetti, Bull,
Nixdorf e ICL, entre outras.
Para alem de ter patrocinado o desenvolvimento da linguagem DIANA, de que adiante
falaremos, o AJPO apoiou também um projecto de avaliação e validação (E & V Project) cujo
objectivo era o de desenvolver métodos de avaliação de performances de diversos APSEs,
bem como critérios que permitam determinar da aplicabilidade de um dado APSE para o
desenvolvimento de um sistema especifico. O grupo responsável pelo projecto, que integra
participantes da indústria, produziu um conjunto de "benchmarks" para a avaliação de
performances de compiladores ADA.
Ainda no mesmo âmbito, o grupo de trabalho ARTEWG do SIGADA, tem como finalidade o
estabelecimento de normas, critérios e linhas de acção para ambientes ADA, por forma a
facilitar a reutilização e transportabilidade de componentes de software escritos em ADA,
melhorar a performance desses componentes, bem como a avaliação de sistemas de
desenvolvimento.
O que é?
Tradicionalmente, as ferramentas de software tendem a ser dependentes do sistema operativo
em que estão instaladas. Por isso, não e trivial a sua transferência para outro sistema
operativo. Para evitar este problema definiu-se uma interface comum com o sistema operativo,
constituída por um núcleo (kernel) que virtualiza a maquina.
O problema atrás descrito foi um dos muitos que se levantaram no processo de elaboração do
Stoneman. Este documento de especificações previa a existência de três níveis: KAPSE,
MAPSE e APSE global.
O KAPSE (Kernel Ada Programming Support Environment) e o núcleo do ambiente e suporta
as funções básicas do sistema operativo, base de dados e comunicações. E este núcleo que
garante a transportabilidade do ambiente, tal como acima referimos. A base de dados e uma
peca fundamental no ambiente de desenvolvimento, uma vez que serve de repositório a toda a
informação associada a cada projecto, ao longo de todo o seu ciclo de vida.
O MAPSE (Minimal Ada Programming Support Environment) fornece um conjunto de
ferramentas básicas incluindo editor, compilador, linker, loader, debugger, entre outras.
O APSE global (full Ada Programming Support Environment) inclui as ferramentas necessárias
a implementação prática de uma dada metodologia. Estas poderão destinar-se a apoiar a
definição de objectivos, as especificações funcionais, gestão do projecto, etc, constituindo
assim um conjunto de ferramentas aplicáveis em todas as fases do ciclo de vida de um
sistema.
Muitas das ferramentas operam sobre o programa fonte escrito em ADA, o que geralmente
obriga a que possuam uma forma de representação interna que permita a localização eficiente
das unidades sintácticas. Foi precisamente no sentido de normalizar essa representação, o
que permite uma mais fácil interacção entre ferramentas e menores custos de
desenvolvimento, que foi projectada, com o patrocínio do AJPO, a linguagem DIANA. Esta
linguagem consiste numa representação em arvore do código fonte, em que cada no tem um
ou mais atributos.
Este tipo de representação tem a vantagem de ser facilmente manipulável, dado serem
conhecidos muitos algoritmos para operar sobre estruturas em árvore. As conversões ADA ->
DIANA e DIANA -> ADA são relativamente simples, existindo versões (de ferramentas
baseadas em DIANA) em uso [22]. Um exemplo de um sistema de desenvolvimento para ADA
e o CAEDA desenvolvido na Universidade de Carleton no Canada [1]. Este APSE utiliza uma
interface gráfica (numa estação de trabalho SUN) para capturar a estrutura lógica do sistema a
projectar, guardando-a numa base de dados do projecto. A partir desta ultima, pode ser gerado
código fonte em ADA, semiautomaticamente. Esta última fase foi desenvolvida em Prolog.
Outro exemplo de um APSE, este desenvolvido na indústria (Rolm Corporation) e
comercializado pela Data General e o ADE - Ada Development Environment.
Os ambientes de programação para ADA têm constituído uma fonte inesgotável de assuntos
para projectos de investigação em curso em muitas universidades, tal como se poderá
constatar pela lista de referências no fim deste artigo. Tem-se efectuado inúmeros congressos,
reuniões e workshops em que têm sido apresentados os resultados desses projectos. Alguns
dos campos de investigação, motivados pelos APSEs, centram-se em torno das bases de
dados para os projectos, interfaces com o utilizador, reutilização de software, ambientes
distribuídos, relação entre metodologia e ambiente, bem como arquitecturas de ambientes [1].
Note-se que a maior parte destes assuntos são independentes da linguagem (embora as
implementações práticas tendam a ser desenvolvidas em ADA), o que suscita ainda mais o
interesse da comunidade científica, sendo a ADA um meio e não um fim em si própria.
Referências
[1]
[Adatec85]
ACM ADATEC, "Future Ada Environment Workshop", ACM Sigsoft
Software Engineering Notes Vol 10 no2, Abril 85
[2]
[Baker85]
Baker, T.P. / Riccardi, G.A. (Florida State University), "Ada Tasking:
From Semantics to Efficient Implementation", IEEE Software vol 2 no2, Março 85
[3]
[Barnes84]
Barnes, J.G.P. (SPL International), "Programming in Ada", Addison
Wesley Publishing Company, 84
[4]
[Buzzard85]
Buzzard, G.D. / Mudge, T.N. (University of Michigan), "Object-Based
Computing and the Ada Programming Language", IEEE Computer, Março 85
[5]
[Clapp86]
Clapp, Russel M. / Duchesneau, Louis / outros (University of Michigan),
"Toward Real-Time Performance Benchmarks for Ada", Communications of the ACM vol 29
no8, Agosto 86
[6]
[Crenshaw86] Crenshaw, Jack W. (Honeywell), "Comment on a Preliminary Study of
Ada Expansion Ratios", ACM SIGSOFT Software Engineering Notes vol 11 no3, Julho 86
[7]
[Darpa83]
DARPA (DoD), "ADA Reference Manual", 83
[8]
[Freeman84]
Freeman, Peter / Wasserman, Anthony I. / Houghton, Raymond C.
(University of California), "Comparing Software Development Methodologies for Ada: A Study
Plan", ACM SIGSOFT Software Engineering Notes vol 9 no4, Julho 84
[9]
[Friel85]
Friel, Patricia / Sheppard, Sallie (Texas University), "Implications of the
ADA Environment for Simulation Studies", Simuletter vol 16 no2, Abril 85
[10]
[Goering84]
Goering, Richard, "ADA Kit Cuts Compiler Development Time",
Computer Design, Novembro 84
[11]
[Helmbold85] Helmbold, David / Luckam, David (Stanford University), "Debugging
Ada Tasking Programs", IEEE Software vol 2 no2, Marco 85
[12]
[Hookway85] Hookway, Raymond J. (Case Western Reserve University - Cleveland),
"Verifying ADA Programs", ACM SIGSOFT Software Engineering Notes vol 10 no4, Agosto 85
[13]
[James83]
James, Carol L. / Morrill, Duncan E., "The Real Ada, Countess of
Lovelace", ACM SIGSOFT Software Engineering Notes vol 8 no1, Janeiro 83
[14]
[Klumpp83]
Klumpp, Allan R. (Jet Propulsion Laboratory, California Institute of
Technology), "Space Station Flight Software: HAL/S or ADA ?", IEEE Computer, Março 85
[15]
[Ledgard81]
Ledgard, Henry, "ADA - An Introduction", Springer Verlag, Fevereiro 81
[16]
[Lieblein86]
Lieblein, Edward (Tartan Laboratories Incorporated - Pittsburgh), "The
Department of Defence Software Initiative: A Status Report", Communications of the ACM vol
29 no8, Agosto 86.
[17]
[Luckham85] Luckham, David C. / Henke, Friedrich W. Von (Stanford University),
"An Overview of ANNA, a Specification Language for ADA", IEEE Software vol 2 no2, Março 85
[18]
[McHugh85]
McHugh, John (Research Triangle Institute) / Nyberg, Karl (Verdix
Corporation), "ADA Verification Using Existing Tools", ACM SIGSOFT Software Engineering
Notes vol 10 no4, Agosto 85
[19]
[Porcella83]
Porcella, Maria / Freeman, Peter / Wasserman, Anthony I. (University
of California), "ADA Methodology Questionnaire Summary", ACM SIGSOFT Software
Engineering Notes vol 8 no1, Janeiro 83
[20]
[Reynolds85] Reynolds, Robert G. (Wayne State University), "PARTIAL: A Tool to
Monitor the Stepwise Refinement of Ada Programs", ACM SIGSOFT Software Engineering
Notes vol 10 no3, Julho 85
[21]
[Rice83]
Rice, John R. (Purdue University), "Remarks on Software Components
and Packages in ADA", vol 8 no2, Abril 83
[22]
[Rosenblum85] Rosenblum, David S. (Stanford University), "A Methodology for the
Design of ADA Transformation Tools in a DIANA Environment", IEEE Software vol 2 no2,
Março 85
[23]
[Sammet86]
Sammet, Jean E. (IBM), "Why ADA is not just another programming
language", Communications of the ACM, Agosto 86
[24]
[Suydam85]
Suydam, William E., "ADA Programs Emerge as Compilers Vault
Validation Hurdles", Computer Design, Junho 85
[25]
[Urban85]
Urban, Joseph E. (University of Southwestern Louisiana) / Fisher,
David A. (Incremental Systems Corporation), "ADA Environments and Tools", IEEE Software
vol 2 no2, Março 85
[26]
[Wasserman82] Wasserman, Anthony I. / Freeman, Peter (University of California),
"ADA Methodologies: Concepts and Requirements", ACM SIGSOFT Software Engineering
Notes vol 8 no1, Novembro 82
[27]
[Wegner84]
Wegner, Peter (Brown University), "Accomplishments and Deficiencies
of ADA", IEEE Software, Julho 84
[28]
[Wiener84]
Wiener, Richard S. / Sincovec, Richard F. (University of Colorado),
"Software Engineering with MODULA-2 and ADA", John Wiley & Sons, 84
[29]
[Wolf85]
Wolf, Alexander L. / Clarke, Lori A. / Wileden, Jack C. (University of
Massachussets), "ADA - Based Support for Programming-in-the-Large", IEEE Software vol2
no2, Março 85
Apêndice A - Quem foi a verdadeira Ada ?
"E tomou Lamech para si duas mulheres:
o nome de uma era Ada
e o nome da outra era Zila."
(in GENESIS, cap.4, v.19)
Ada é a segunda mulher mencionada na Bíblia, a primeira depois de Eva...
Trata-se contudo de uma curiosidade, pois a Ada que deu o nome à linguagem é bastante mais
recente e menos litúrgica que essa nossa "antecessora"!
Passemos à história. Em 1813 o poeta inglês Lord Byron, então com 25 anos, apaixona-se e
mantém uma relação incestuosa com a sua meia-irmã, Augusta Leigh. Dois anos mais tarde,
casa-se com uma jovem puritana de boa família, amante das matemáticas, Annabella
Milbanke. Byron, que com sua vida e a sua obra criou o protótipo do herói romântico -jovem
melancólico, devasso mas audacioso, tinha uma personalidade incompatível com a sua esposa
e algumas semanas depois da sua única filha legitima, Augusta Ada Byron, ter nascido (10 de
Dezembro de 1815), separou-se.
Algum tempo depois, os rumores sobre o seu caso anterior ao casamento, destruíram-lhe a
reputação e aceitação social, forçando-o a abandonar o país. Viveu no castelo de Chillon perto
de Montreux na Suíça. Embora nunca mais tivesse visto a sua filha, muitas das suas cartas e
poesia demonstravam uma preocupação carinhosa por ela. Morreu novo, em 1824, quando
Augusta Ada tinha ainda oito anos.
Quanto a Ada, sua mãe Lady Byron encorajou-a a desenvolver, desde criança, os seus
talentos naturais para a matemática. Entre os seus tutores, eminentes cientistas e
matemáticos, contava-se Augustos de Morgan, um amigo de família aliás.
Em 1835 casa-se com William King, mais tarde Lord Lovelace, o qual também encorajava Ada
a prosseguir a sua carreira científica.
Aos 29 anos publica o seu trabalho científico mais notável. Trata-se de um estudo aprofundado
que acrescentou à sua tradução para Inglês de um trabalho famoso (Menabrea) sobre a
máquina analítica de Babbage. Esse estudo demonstrava bem o seu domínio das teorias
matemáticas e técnicas numéricas utilizadas nas máquinas computacionais de Babbage,
sendo essas aptidões conhecidas e apreciadas pelos cientistas britânicos de nomeada de
então, como Charles Wheatstone, Michael Faraday, Mary Sommerville e o já referido Augustus
de Morgan.
Nos seus últimos anos (faleceu em 1852, aos 36 anos vítima de um cancro), para além de
várias perturbações físicas e psíquicas devidas a medicamentação indevida, envolveu-se em
apostas nas corridas de cavalos, tendo inclusivamente empenhado as jóias da família.
A seu pedido foi sepultada ao lado de Lord Byron aceitando assim a sua identidade e a de seu
pai que fora ensinada a desprezar.
Apêndice B - Dicionário ADA
O movimento ADA tem suscitado a mobilização e mesmo a criação de um número crescente
de organizações e publicações. O leitor que deseje aprofundar os seus conhecimentos sobre
ADA, irá encontrar na maioria dos artigos, toda uma profusão de nomes e siglas que já fazem
parte do jargão dos iniciados. Sem a convicção de cobrir a totalidade, aqui se incluem, para
facilitar posteriores leituras.
ABICS (ADA Based Integrated Control System ) - Projecto incluído no programa STARS, com o
fim de desenvolver e demonstrar a viabilidade da reutilização de software para sistemas
aeronáuticos.
ADAIC (ADA Information Clearinghouse Newsletter ) - Publicação bimestral do AJPO que
fornece informações gerais sobre serviços e actividades relacionadas com a ADA.
ADA Letters - Publicação bimestral do ACM (Association of Computer Manufacturers)
ADATec - Grupo Técnico criado em 1981 no âmbito da ACM (Association of Computer
Manufacturers), reunindo personalidades da comunidade científica para aprofundar
experiências nos domínios de investigação relacionados com ADA
ADAM (ADA - based language for Multiprocessing) - Linguagem baseada em ADA para
utilização em aplicações de multi processamento. Foi desenvolvida na Universidade de
Stanford.
ADE (ADA Development Enviroment) - APSE desenvolvido pela Rolm Corporation em San
Jose na California em 1983. É comercializado pela Data General e está instalado (o KAPSE)
sobre o sistema operativo AOS/VS.
AJPO (ADA Joint Program Office) - Instituição criada no âmbito do Gabinete do Secretário da
Defesa dos E.U.A., em 1980, encarregada de acompanhar todo o processo de
estandardização da linguagem ADA, definir políticas bem como efectuar os mais de 2500
testes de validação aos compiladores, para que possam usar o nome ADA.
ANNA (ANNotated ADA) - Extensão da linguagem ADA que visa acrescentar potencialidades
no campo da especificação formal[17]. Foi desenvolvida na Universidade de Stanford, no
âmbito do programa STARS.
APSE (ADA Programming Suport Environment) - Ambiente de apoio à programação em ADA.
ARTEWG (ADA Run-time Environment Working Group) - Grupo de trabalho que se formou no
seio do SIGADA e em cooperação com o AJPO, com o objectivo de estabelecer critérios e
linhas de acção para ambientes ADA, que facilitem a reutilização e transportabilidade de
componentes de programas bem como avaliar e melhorar a performance de tais componentes.
ASEET (ADA Software Engineering Education and Training Team) - Equipa de trabalho criada
no AJPO com o intuito de identificar as necessidades de formação em ADA no seio do DoD, o
desenvolvimento em conjunção com o SEI de material para cursos de Engenharia de Software
em ADA e definir planos de formação e reciclagem, tudo isto em cooperação com a indústria.
AUR (Automation of User's Requirements) - Projecto incluído no programa STARS, cuja
finalidade é a de desenvolver técnicas de especificação e validação dos requisitos de
aplicações, por forma a que estes sejam traduzidos fácilmente (semiautomáticamente) para
programas fonte em ADA.
CAEDE (CArleton Embedded system Design Environment) - Ambiente de projecto para ADA. A
versão de Setembro de 1984 [1] incluía um sistema de captura gráfica da estrutura lógica do
sistema a projectar. A informação capturada era armazenada numa base de dados do projecto,
a partir da qual era gerado código fonte em ADA. Este ambiente foi desenvolvido em Prolog.
CAIS (Common APSE Interface Set) - Documento de definição das interfaces do KAPSE, cuja
primeira versão foi publicada em Novembro de 1985.
CAMP (Common ADA Missile Packages) - Projecto incluido no programa STARS, com o intuito
de utilizar os conceitos de reutilização no desenvolvimento de software para mísseis.
CREASE (Catalog of Resources for Education in ADA and Software Engeneering) - Lista de
cursos, seminários, programas de treino, livros e outras publicações sobre ADA e conceitos de
Engenharia de Software suportados pela linguagem. É publicada pelo AJPO e actualizada
anualmente com a informação recebida das empresas que fornecem esses serviços e das
editoras.
DARPA (Defence Advanced Research Projects Agency) - Instituição de investigação no âmbito
do DoD, em sistemas cruciais de defesa.
DIANA - Linguagem intermédia para utilização em compiladores e outras ferramentas de
programação para ADA[22]. Foi desenvolvida nos Tartan Laboratories Inc. em Pittsburg.
DoD (United States Department of Defense) - Departamento de Defesa dos Estados Unidos.
Provocou o arranque e suportou financeiramente o projecto de desenvolvimento da linguagem
ADA.
DoD Software Initiative - nome por que era conhecido inicialmente o programa STARS.
Embedded Computers - Computadores que fazem parte/controlam sistemas maiores como
submarinos, aviões, navios, automóveis ou mesmo fogões de microondas.
HOLWG (High Order Language Working Group) - Grupo constítuido em 1974 por
representantes dos diversos ramos das forças armadas e organismos de defesa norte
americanos, com o objectivo global de desenvolver uma metodologia sistemática para melhorar
o uso do software pelos militares.
IDL (Interface Description Language) - Linguagem de especificação de dados que permite uma
considerável abstração dos pormenores de representação. Um tradutor de IDL pode
automatizar a conversão das especificações para código ADA.
Ironman - Quarto documento de requisitos da linguagem a desenvolver, publicado em 1977,
tendo servido de base para a primeira fase da competição em que se envolveram quatro
equipas de projecto na definição da nova linguagem.
KAPSE ( Kernel ADA Programming Suport Environment) - Núcleo do ambiente de apoio à
programação em ADA. Implementa a interface com o sistema operativo, base de dados e
comunicações.
KIT (KAPSE Interface Team) - equipa governamental formada pelo AJPO com o fim de
desenvolver as interfaces do KAPSE.
KITIA (KAPSE Interface Team from Industry and Academia) - equipa representando a indústria
e as universidades, com um fim idêntico ao do KIT.
MAPSE (Minimal ADA Programming Support Environment) - camada do ambiente de apoio ao
desenvolvimento em ADA que, utilizando os serviços do KAPSE, fornece um conjunto de
ferramentas essenciais à programação (editor, compilador, linker, etc).
Methodman - Documento que descreve os requisitos de uma metodologia de desenvolvimento
de software. Foi publicado pelo DoD em 1982.
PACT (Pilot ADA Capabilities Transition) - Projectos conduzidos no âmbito do programa
STARS, SEI e AJPO. São desenvolvidos na indústria, sob contrato e destinam-se a promover a
inserção de novas tecnologias no processo de desenvolvimento, obtendo-se assim 'feedback'
das potencialidades reais (resultantes da prática) dessas mesmas tecnologias, suportadas pela
ADA.
PCTE (Portable Common Tool Environment) - Iniciativa europeia (Bull, ICL, Nixdorf, Olivetti e
Siemens) para definir um ambiente de desenvolvimento para ADA, com as desejáveis
qualidades de generalidade e portabilidade.
SEI (Software Engineering Institute) - Instituição de investigação e desenvolvimento, criada em
Dezembro de 1984 e sediada na Universidade de Carnegie-Mellon em Pittsburgh. É suportada
pelo governo dos E.U.A. e resultou de um concurso formal realizado a partir de Junho de 1984.
O seu propósito é o de actuar como catalizador nos processos de transição dos resultados da
investigação para a sua utilização prática em grandes projectos, em tudo o que diga respeito à
Engenharia de Software.
SIGADA (Special Interest Group on ADA) - Grupo criado sob os auspícios da ACM (Association
of Computer Machinery) e que resultou dum anterior comité técnico criado em 1981, o ACM
ADATec. Em 1986 o SIGADA já tinha 3800 membros, com reuniões efectuando-se
trimestralmente, patrocinando conferências e organizando grupos de trabalho em áreas de
investigação de ponta, como por exemplo o ARTEWG.
SJPO (Stars Joint Program Office) - Instituição encarregue de levar a bom termo o programa
STARS do DoD.
STARS (Software Technology for Adaptable Reliable Systems) - É um programa do DoD
iniciado em 1983 cujos objectivos são a melhoria da produtividade, qualidade e fiabilidade do
software, incentivo ao desenvolvimento e utilização de software reutilizável, bem como a
redução do tempo e custos de desenvolvimento do software de defesa.
Steelman - Quinto e último documento de requisitos, publicado em 1978, o qual serviu de base
para a segunda parte da competição no projecto de definição da linguagem (entre as duas
equipas finalistas).
Strawman - Primeiro documento de especificação dos requisitos a que deveria obdecer uma
linguagem de alto nível para servir a generalidade dos projectos desenvolvidos no DoD. Foi
elaborado em 1975 pelo Dr. David A. Fisher do IDA (Institute of Defense Analyses).
Tinman - Terceiro documento de requisitos da linguagem que o DoD necessitava. Foi
publicado em 1976 e resultou da revisão provocada pelos comentários e sugestões recebidas
sobre o "Woodenman".
Woodenman - Segundo documento de requisitos da linguagem a desenvolver, publicado em
fins de 1975 e resultante da revisão provocada pelos comentários e sugestões recebidas sobre
o "Woodenman".
Apêndice C - Não há bela sem senão
A ADA não foge ao ditado, até porque a perfeição não existe! Tendo nascido e desenvolvido
numa época de grande evolução tecnológica, além de ser herdeira de muitos dos paradigmas
das linguagens dos anos 70, ela é alvo de críticas de vários quadrantes, algumas das quais se
irão expor de seguida.
Niklaus Wirth, o inventor do Pascal e Modula-2, exprimiu assim a sua opinião [24]:
"A linguagem ADA é pouco económica. Ela atira-nos com demasiados conceitos. Contudo,
receio que a tendência seja no sentido de sistemas cada vez mais complexos. É aí que o uso
de linguagens de alto nível, com muitos testes redundantes, prova ser não só benéfico, mas
indispensável"
Espera-se que o surto de utilização da ADA venha a suscitar o aparecimento de uma indústria
de desenvolvimento de software, em particular no que respeita às bibliotecas de funções.
Contudo, poderá estar nesse fenómeno, uma razão para a ruína da ADA como linguagem
standard e comum. Com efeito, dado que o desenvolvimento de programas envolve a
utilização de pacotes de funções por exemplo para entradas/saídas e para operações
matemáticas complexas, cada pequena comunidade ADA irá utilizar bibliotecas de um dado
fabricante (eventualmente desenvolvidas ou adaptadas localmente).
O resultado será que os programas desenvolvidos numa instalação x, não terão portabilidade
(a menos que se levem a reboque todas as bibliotecas utilizadas, o que não parece ser uma
boa solução), pois, por exemplo utilizam as funções ASIN, ACOS e ATAN, enquanto que na
comunidade Y se utilizam as funções SIN-1, COS-1 e TAN-1 e na comunidade Z as funcões
ARCSIN, ARCCOS, e ARCTAN.
Outro aspecto importante é o de que, uma vez que com a ADA se pretendem obter fiabilidades
próximas dos 100%, não se deveria correr o risco, como se receia que esteja a acontecer, de
se traduzirem bibliotecas já existentes (escritas noutras linguagens), com o pretexto de que
elas têm servido bem nos últimos 10 a 20 anos e esperar que a interacção com os utilizadores
permita melhorar a sua fiabilidade. A experiência acumulada com outras linguagens [21], indica
que a influência dos utilizadores não permite melhorar a fiabilidade para além dos 85 a 95%.
Algumas características indesejáveis das linguagens dos anos 60, perduram ainda no seio da
ADA, como o sejam a estrutura de controlo "go to" e a possibilidade de existência de variáveis
globais sem restrições de acesso. Outros factores em seu detrimento são a possibilidade de
efeitos colaterais ("side-effects") devido à invocação de funções, ocorrência de excepções
durante a avaliação de expressões e a falta de uma ordem explícita de avaliação dos
operadores de uma expressão.
O facto de os pressupostos tecnológicos em que se baseou o projecto de definição da
linguagem ADA, quer a nível de hardware, quer a nível de software, sofrerem de alguma
obsolescência, por via do rápido desenvolvimento nos últimos anos, limita actualmente a
ambição de generalidade que a linguagem possuía à partida. Assim, faltam na linguagem
mecanismos que suportem eficazmente o desenvolvimento de sistemas distribuídos e sistemas
em tempo-real. Para evitar esta situação, alguns compiladores correntes, apresentam
características não incluídas no manual de referência da linguagem [7] para suportar esses
tipos de sistemas. Um dos assuntos ainda em aberto é o encadeamento de tarefas ("Task
Scheduling") [1].
Um dos argumentos mais fortes da ADA, tem sido a sua normalização. Já se referiu até, que o
DoD proibiu a utilização interna de subconjuntos ou extensões da linguagem.
Contudo a normalização também apresenta o "reverso da medalha". As inadequações de uma
norma propagam-se a todos os seus utilizadores e a outras normas que o usem como ponto de
partida. A ADA encontra-se precisamente nesta situação uma vez que os esforços do DoD na
definição de um ambiente padronizado de apoio à programação em ADA (APSE), foram
conduzidos no sentido da obrigatoriedade de utilização da ADA para o desenvolvimento das
ferramentas de apoio [27]. Além disso, uma vez adoptada uma norma, ela pode ser inflexível,
evitando o progresso. Esta desvantagem é particularmente sensível dado o rápido
desenvolvimento tecnológico em curso, em particular nas arquitecturas de computadores.