Bernd
Pol

# Desenvolvimento em &UNIX;

## Algumas Notas Históricas

Desde o início, o &UNIX; tem mantido dois paradigmas de programação bastante diferentes. Um é o mundo das linguagens de programação das aplicações e do sistema, onde algum código-fonte é traduzido para código-máquina por um programa de tradução, normalmente um compilador ou um interpretador. A linguagem de programação C é um exemplo. O &UNIX; foi o primeiro 'kernel' de sistema operativos a ser criado numa dessas linguagens de alto nível, em vez de ser feito em Assembly altamente orientado à máquina, como era feito antes dessa altura. (De facto, a linguagem C foi mesmo inventada para escrever o 'kernel' do &UNIX; e os programas associados num computador PDP-11 da DEC.)

O outro paradigma é o mundo das linguagens de 'scripting'. Este mundo evoluiu com a invenção da linha de comandos do &UNIX;, que era a interface do utilizador com o sistema operativo — e ao mesmo tempo uma linguagem de programação de muito alto nível. Um 'script' da linha de comandos é criado a partir de um conjunto de pequenos programas utilitários, como p.ex. o `grep`, o `sed` ou o `find`. Cada um desses utilitários é desenhado para uma tarefa estritamente definida. O truque é cada utilitário pode ser ligado a outro através de um mecanismo simples de transporte, chamado de pipe, o qual direcciona o resultado do utilitário anterior para o canal de introdução de dados do utilitário a seguir. Isto cria uma ferramenta de programação muito poderosa e altamente flexível.

À medida que o tempo foi evoluindo, também ambos os mundos foram evoluindo. Embora o C ainda seja usado principalmente como uma linguagem de programação de sistemas, o C++, como uma variante do C, enriqueceu com extensões orientadas a objectos e com genericidade e encontrou o seu lugar para o desenvolvimento de aplicações complexas nos anos 90. Existem outras linguagens de programação diversas, e mesmo algumas linguagens mais antigas ainda têm lugar — o FORTRAN77 e o Ada p.ex. ainda têm a sua força nas aplicações numéricas.

## Linguagens de 'Scripting' Contemporâneas

Na área do 'scripting', houve um ligeiro desvio da linha de comandos, que sofre de problemas de portabilidade, para as linguagens que unificam todas as funcionalidades comuns necessárias para as suas bibliotecas-padrão, embora sejam à mesma capazes de interagir com o exterior através de 'pipes' se necessário.

Todas essas linguagens de 'scripting' têm em comum o facto de serem altamente portáveis entre as variantes de &UNIX;, &Microsoft; &Windows;, &Mac; OS ou até mesmo o VMS. Do mesmo modo, todas elas têm implementações distribuídas de forma gratuita.

### &perl;

O &perl; tornou-se popular como uma linguagem de processamento de texto e de administração de sistemas. No início da World Wide Web, os 'scripts' CGI escritos em &perl; eram uma forma usada em grande medida para criar páginas Web dinâmicas a partir de bases de dados. Hoje em dia, este método foi substituído em grande parte pelo 'plugin' `mod_perl` do servidor Web &apache;. Entre as potencialidades do &perl; encontra-se o seu suporte incorporado para correspondência de expressões regulares avançado e o seu arquivo rico de módulos distribuídos gratuitamente.

Para mais informações veja o 'site' Web do Comprehensive Perl Archive Network (CPAN).

### Python

O &python; brilha pela elegância do seu sistema de classes e pela facilidade e flexibilidade com que as bibliotecas externas conseguem ser incorporadas, de forma a aparecerem como classes e funções normais do &python;. Em contraste com o &perl;, o &python; tem uma &API; embebida clara e concisa, o que o torna a linguagem de escolha para tornar os programas em C ou C++ utilizáveis em 'scripts'.

### PHP

O &php; foi inventado como uma linguagem directamente incorporada nas páginas &HTML; e, por consequência, tem as suas utilizações principais a distribuir conteúdo dinâmico na Web.

## 'Scripting' de Alto-Nível

As aplicações de &UNIX; de alto-nível normalmente perdem a velocidade e flexibilidade dos mecanismos de 'scripting' da linha de comandos tradicional. Isto é especialmente verdadeiro no mundo das interfaces gráficas do utilizador (&GUI;) como &eg; o &kde;.

Têm existido algumas tentativas de oferecer mecanismos semelhantes que irão funcionar num nível aplicacional mais elevado, como o CORBA e, no ambiente do &kde;, o &DCOP;.

### O Protocolo CORBA

O CORBA (Common Object Request Broker Architecture) é uma tentativa para permitir as aplicações informáticas trabalharem em conjunto numa rede. Foi originada pelo comité normativo, privado e independente do distribuidor da OMG (Object Management Group).

Os programas baseados em CORBA usam o protocolo-padrão IIOP para comunicarem. As implementações baseadas no IIOP estão disponíveis num vasto conjunto de sistemas operativos, linguagens de programação e redes, sendo assim multi-plataforma.

A desvantagem principal do CORBA é a sua velocidade relativamente baixo. Embora isto possa ser suportável em redes, é um grande entrave para as comunicações entre aplicações num ambiente sem rede, como por exemplo o &kde; a correr num único computador.

### A Interface de &DCOP;

Outra evolução do 'scripting' semelhante ao &UNIX; é o protocolo DCOP, o qual foi destinado à comunicação entre as aplicações do &kde; para ultrapassar as limitações do CORBA.

O &DCOP; significa Desktop COmmunikation Protocol e está implementado como um mecanismo simples de IPC/RPC para operar sobre 'sockets'. De facto, isto fornece funcionalidades semelhantes às do mecanismo tradicional de 'pipes' do &UNIX;.

O 'scripting' de linha de comandos tradicional é baseado em programas utilitários relativamente pequenos que foram desenhados para funcionarem de uma forma textual muito restrita. O &DCOP; permite aos programas gráficos elaborados comunicarem uns com os outros de uma forma muito semelhante. Isto permite &eg; a um programa do &kde; enviar mensagens a outro programa do &kde; ou receber dados do mesmo para os seus objectivos próprios.

Existem desvantagens, contudo. Para usar o &DCOP; um programa precisa de ser desenhado para conter uma interface &DCOP; especial. Para além disso, o processo de comunicação do &DCOP; corre de forma um pouco lenta. De qualquer forma, ele confere muito do poder e da flexibilidade do 'scripting' em &UNIX; para os programas de alto nível que se baseiam numa interface gráfica para o utilizador.

Para mais informações, veja o artigo DCOP: Desktop COmmunications Protocol ou a referência da &API; da biblioteca do Desktop Communication Protocol &DCOP; para a biblioteca de &DCOP; do &kde;.

## Sistemas de Compilação

Excepto nos casos muito simples, o seu projecto irá consistir de um grande conjunto de blocos de construção de código-fonte, estando cada um deles colocado num ficheiro separado para uma manutenção mais simples. Para pôr isto a correr, você terá de traduzir efectivamente todas estas coisas em algumas unidades de linguagem da máquina, num formato adequado que permita ao sistema operativo carregar e executar o programa.

Para conseguir isto, as ferramentas básicas que necessárias são

- um editor de texto para escrever os ficheiros de código-fonte,

- um programa de tradução, normalmente um compilador para transformar o código-fonte em ficheiros-objecto,

- um criador de bibliotecas que junta os ficheiros-objecto em bibliotecas, para os poder reutilizar facilmente sem ter de os recompilar.

- um editor de ligações que junta os vários ficheiros-objecto e bibliotecas todos num único executável,

- um sistema de compilação que forneça alguns meios de gerir todas estas coisas e — não esquecer

- um depurador para (assim se espera) poder encontrar todos os erros no programa e possivelmente algumas outras ferramentas de diagnóstico para ter tudo a correr sem problemas.

Quando você tem um projecto grande que consiste possivelmente em centenas de ficheiros de código-fonte, o processo de compilação pode-se tornar bastante trabalhoso. Você não irá querer recompilar todos os ficheiros de cada vez que você tenha alterado apenas alguns deles. Em vez disso, você só deseja compilar aqueles ficheiros que são afectados pelas modificações. De um mode geral, não é óbvio saber quais é que são.

Quando você &eg; mudar o protótipo de uma função num ficheiro de inclusão, você terá de compilar todos os ficheiros que incluam este. Se o seu projecto contiver assim tantos ficheiros, você poder-se-á esquecer de um ou dois deles, se tiver de fazer esse trabalho manualmente. Como tal, é necessária alguma forma de automatização.

### O Processo Make

Uma ferramenta que toma conta das recompilações é o `make`. Ele mantém um registo de todo o trabalho, usando um conjunto de regras que descrevem o que fazer no caso de algum pedaço de informação (normalmente um ficheiro de código ou um ficheiro-objecto) ser alterado. Todas as regras que pertencem a um dado projecto são guardadas num ficheiro chamado `Makefile` que é processado pelo `make` de cada vez que você deseja actualizar o seu trabalho.

Cada regra consiste em vários blocos de construção, nomeadamente

- um alvo, ou seja, o ficheiro a ser criado

- um conjunto de dependências, basicamente os nomes daqueles ficheiros de que o alvo depende (&eg;, o nome de um ficheiro de código, onde então o alvo será o nome do ficheiro-objecto a ser criado) e

- os comandos que serão executados para criar o alvo (&ie;, para o compilar ou para ligar outros ficheiros-objecto em conjunto para formar um programa executável).

Basicamente, o comando `make` irá ler as regras uma a seguir à outra, verificar cada ficheiro na lista de dependências de um determinado alvo e criar esse alvo de novo, se algum destes ficheiros foi alterado, usando os comandos indicados na regra.

Existem várias possibilidades adicionais para controlar um processo do 'make' e, deste modo, uma `Makefile` poderá deste modo ficar bastante complexa. Não poderemos entrar em detalhes aqui. Contudo, recomendamos que você se vá acostumando à sintaxe do `make`. Mesmo que você não o use directamente, a compreensão dos fundamentos do sistema de compilação poderá ser útil. Veja o Manual do Make da GNU para mais informações.

Para mais detalhes específicos do &kdevelop;, veja o capítulo sobre a Gestão de Projectos e Compilações deste manual.

Existem vários tutoriais disponíveis; veja as referências no capítulo sobre gestão dos projectos e das compilações.

## Desenvolvimento de &GUI;s

Os programadores de aplicações estão incumbidos normalmente em ter não só de criar as bibliotecas e a lógica dos programas, mas também em fornecer interfaces de utilizador que sejam tanto intuitivas como funcionais. A maioria dos programadores recebem pouca ou nenhuma formação na programação de GUIs e, como tal, as interfaces do utilizador resultantes poderão ficar mal desenhadas.

Ao longo dos anos, alguns princípios de desenho foram evoluindo. É altamente recomendado que adira a eles. Desta forma, as suas interfaces de utilizador irão reter uma aparência e comportamento comuns, factores que os utilizadores da sua aplicação irão agradecer.

Para a programação de &GUI;s no &kde;, existe um guia de estilo disponível. Ele está nas Linhas-Guia de Interfaces do Utilizador do &kde; na página dos programadores do &kde;.

Poderá ser encontrada uma breve introdução aos princípios de desenho de interfaces aqui.

## Integrar os Conceitos e as Ferramentas – o IDE

Existem várias ferramentas separadas disponíveis para quase todos os passos do processo de programação — planeamento, edição, gestão de ficheiros e processos de compilação, depuração, documentação, entre muitas outras coisas. Mas, logo que os projectos cresçam, o processo de programação tornar-se-ão bastante complicados.

Muito do trabalho repetitivo tem de ser feito ao desenhar, compilar e depurar um programa. Muito do trabalho pode-se poupar através do uso de modelos e 'scripts'. O restante é feito mantendo, de forma simples, as ferramentas disponíveis facilmente e com capacidades de comunicarem umas com as outras através de uma &GUI; comum.

Por exemplo—não seria conveniente que um depurador fosse capaz de abrir o ficheiro de código em questão num editor e colocasse o cursor directamente sobre a posição do erro que foi encontrado?

Para conseguir um esquema desses mais facilmente, os Ambientes de Desenvolvimento Integrados (&IDE;s) foram criados. Um &IDE; desse género integra todos os modelos, ferramentas e programas necessários no processo de desenvolvimento num único ambiente.

Para a plataforma do &kde;, o &kdevelop; é desses &IDE;s. Ele contém um conjunto vasto de ferramentas que facilitam o desenvolvimento e manutenção dos programas, mesmo para as diferentes linguagens de programação e pelas várias plataformas.

### Funcionalidades Básicas do &kdevelop; &kdevrelease;

- Gere todas as ferramentas de desenvolvimento necessárias para a programação em C++, como o compilador, o editor de ligações, o depurador e o sistema de compilações.

- Contém um &appwizard; que gera aplicações completas e prontas a funcionar.

- Permite ao utilizador seleccionar um editor integrado, baseado no editor do programador &kwrite; ou no QEditor da Trolltech ou noutro qualquer.

- Um gerador de classes, para poder criar classes novas e integrá-las no projecto actual.

- Gestão de ficheiros para o código, os ficheiros de inclusão, documentação, etc., a incluir no projecto.

- A assistência na criação de manuais do utilizador da aplicação, feitos com as ferramentas do &kde;.

- Documentação da &API; automática e baseada em &HTML; para as classes de um projecto com referências cruzadas para as bibliotecas utilizadas.

- Suporte para internacionalização, o que permite aos tradutores adicionarem a sua língua-alvo a um projecto com facilidade, incluindo o suporte para o &kbabel;.

- O suporte para a gestão de um projecto através de um de vários sistemas de controlo de versões (&eg;, o &CVS;), fornecendo uma interface simples de utilizar para as funções mais necessárias.

- Uma interface para um depurador integrado.

- Um emulador da consola de texto.

- Realce de sintaxe nos ficheiros de código.

- Completação automática de código para as variáveis das classes, os métodos das mesmas, os argumentos das funções, entre outras coisas.

- Modelos para criar vários projectos (módulos do &kcontrol;, 'applets' do &kicker; (painel), KIOSlaves, 'plugins' do &konqueror; e estilos do ecrã).

- Quatro janelas de navegação em árvore para mudar facilmente entre ficheiros de código, ficheiros de inclusão, classes e documentação, eliminando a necessidade de um gestor de ficheiros externo.

- Suporte para compilações cruzadas, com a possibilidade de indicar vários compiladores diferentes, opções de compilação, arquitecturas-alvo, &etc;

- Suporte para projectos do Qt/Embedded (como o Zaurus e o iPAQ).

- Inclusão de vários programas que necessite para programar, adicionando-os ao menu Ferramentas, de acordo com as suas necessidades individuais.