Parabéns Android que continue sempre assim.

Fonte: Distimo

Este trabalho apresenta os aspectos gerais para o desenvolvimento de uma aplicação especifica como ferramenta de monitoramento e qualificação de rede baseada em analises de variáveis de QoS para sistema operacional Android, considerando aspectos relacionados à ferramenta e ambientes. O Artigo expõe ainda, algumas contribuições recentes, encontradas na literatura, que apresentam casos de sucesso no desenvolvimento de aplicações para essa plataforma e dados expressivos que justificam sua utilização. Por fim apresentamos a ferramenta concluída e resultados obtidos com seu desenvolvimento e melhorias a serem realizadas.

Desenvolvimento Android - Apresentação CONNEPI 2011 (28)

Para baixar o aplicativo vá no Market: https://market.android.com/details?id=br.com.redrails.wa

ou use o QRCODE

Qualquer dúvida me contacte

Código simples, mostrando como criar botões dinamicamente através de um array definido por arquivos XML nos resources do projeto Android.E pegando o evento de onClick e compartilhando da maneira que quiser, facebook, orkut, dropbox via sms, email etc…

public class DinamicButtonsActivity extends Activity implements OnClickListener {

    @Override

    public void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.home);

        Resources res = getResources();

        String[] button_texts = res.getStringArray(R.array.button_texts);

        LinearLayout layout = (LinearLayout) findViewById(R.id.ButtonsGroup);

        LinearLayout.LayoutParams p = new LinearLayout.LayoutParams(

                LinearLayout.LayoutParams.FILL_PARENT,

                LinearLayout.LayoutParams.WRAP_CONTENT

        );

        for (int i = 1; i < button_texts.length; i++) {

            Button button = new Button(this);

            button.setText(button_texts[i]);

            button.setOnClickListener(this);

            layout.addView(button, p);

        }

    }

    @Override

	public void onClick(View v) {

		String text = (String) ((Button) v).getText();

		String text = (String) ((Button) v).getText();

		Intent i = new Intent(Intent.ACTION_SEND);

		i.setType("text/plain");

		i.putExtra(Intent.EXTRA_TEXT, text);

		startActivity(Intent.createChooser(i, "Compartilhe"));

	}

}

Agradecimentos ao pessoal da AndroidBrasil-Dev e da StackOverFlow pela ajuda.

Tive a oportunidade de possuir o Sansung Galaxy 5 e o Motorola Spice XT300 ao mesmo tempo e poder comparar os dois em vários aspectos.

Desempenho:
Em velocidade considerei o Galaxy 5 bem mais rápido que o Spice, tanto para ligar quanto para realizar tarefas de sistemas, quanto para executar aplicações e ainda na resposta ao toque.

Qualidade de Vídeo:
Qualidade visual da tela do Galaxy é bem superior a do Spice,  mas a qualidade de vídeo do spice não chega a ser ruim e ainda é um pouquinho mais larga.

Usabilidade:
O teclado Qwerty do motorola Spice provê uma maior usabilidade, possui botões de controle tanto físico quanto lógico, e sua tela ainda é muilti touch. Enquanto o Galaxy não possui tela muti touch nem querty, e apenas botões de controle lógicos. Ponto para o Spice

Sistema Operacional:
O Galaxy na grande maioria dos casos vem com Android 2.1, assim como o Spice, mas no Galaxy pode-se fazer upgrade para a versão 2.2.

Câmera:
Mesmo o Spice possuindo uma resolução maior  (3.1mp, contra 2 mp do Galaxy) na prática a mesma foto tirada em mesmas condições de luz mostram de o Galaxy consegue uma melhor aparência em suas cores.

Preço
Varia muito de acordo com a loja o Galaxy 5 é encontrado de 380 até R$ 699,00 em média, enquanto o Spice está em uma faixa de R$ 407,00 a 699,00.

Foto tirada do motorola Spice

Foto tirada do galaxy 5

O problema de partição de números consiste em: dado um conjunto de N números, o objetivo é subdividi-lo em dois subconjuntos (chamados de partições) de tal forma que, a diferença entre os valores das somas dos números dessas duas partições seja a menor possível. Por exemplo, considere o seguinte conjunto com quatro números (23, 20, 56, 48). As partições (20,56) e (23,48) consistem no particionamento ótimo para este conjunto e, seu valor é 5. Apesar da simplicidade do enunciado, este é um problema de otimização combinatória que pertence à classe NP-difícil. Observe que, para um conjunto com N números têm-se 2N possíveis maneiras de subdividi-lo em duas partições.

Nosso problema consiste em dado uma seqüência [10,20,30,11,25,23,32,9,7,19,17,31,48,27,5,21,35,13,38,16,14,33,5] devemos criar um vetor de sinais (- ou +) para cada numero disposto, de modo a alcançarmos o menor valor (tendendo a 0) considerando o módulo do resultado das operações realizadas.

EX: para o vetor [10,20,30,11] geramos um vetor [1,1,0,0] considerei para esse exemplo que um representa + e 0 representa -, sendo assim nosso vetor seria [+,+,-,-]. O que geraria +10+20-30-11, resultando no valor 11, considerando seu módulo.

Entendido esse conceito vamos ao código.

Criaremos uma classe chamada Individuo com dois atributos @code e @value que recebem respectivamente o código binário (que representa os sinais) e o valor da função objetivo (ou em nosso caso o resultado da sentença) daquele individuo em questão.

class Individuo
   attr_reader :code,:value
 def initialize
   @code = ((0+rand(8_388_608)).to_s(base=2)).rjust(23,"0")
   @value = to_value(@code)
 end

 def to_value(binary)
   a = [10,20,30,11,25,23,32,9,7,19,17,31,48,27,5,21,35,13,38,16,14,33,5]
   sign = {"0"=>-1,"1"=>1}
   value = index = 0
   binary.each_char do |c|
     value = value+a[index]*sign1
     index+=1
   end
   (value<0 ? value*-1:value ) #MODULO
 end

end

E pronto, agora podemos gerar quantos indivíduos quisermos sem o menor esforço. Vou dar um exemplo de criação de 100 individuos.

  população = 100.times.collect{Individuo.new}

Não é tão difícil quanto parece. Podemos implementar uma segunda classe mais bonitinha para realizarmos nossos experimento abaixo um exemplo de implementação da classe Raca (Raça) que vai nos dar uma interface facilitadora para gerar nossa população.

require 'individuo'
class Raca

 attr_reader :populacao,:quantidade,:populacao_ordenada
 attr_accessor :valor_total

 def initialize(quantidade)
   @quantidade = quantidade
   @populacao = criar_populacao(@quantidade)
 end

#método que realiza a criação da população Inicial
 def criar_populacao(quantidade)
   quantidade.times.collect{Individuo.new}
 end

#apenas ordena o vetor do melhor idividuo para o pior
 def selecao_natural
   @populacao.collect { |ind| [ind.value,ind.code] }.sort
 end

#sobrescrevendo o to_s para uma visão melhor da população
 def to_s
   out =  "Valor".ljust(10)+"     Código Genético ".ljust(25)+"\n\n"
   @populacao.each do |individuo|
     out << "#{individuo.value.to_s.ljust(10)} #{individuo.code.ljust(25)}\n"
   end
   out
 end
end
#rodando código
anfibios = Raca.new(12)
puts anfibios

Esse código tem como resultado algo parecido com isso :

Valor          Código Genético   

1          11100010001111000001100 
73         00110110100011000001100 
29         10001011010011010011100 
237        01111011111110000111110 
5          11101000000110001101100 
99         01000010101001000011011 
173        01111110011110101001101 
35         11010011100010100010110 
109        10100010101000110001111 
23         10011001001101000110111 
135        01000111111101101011010 
119        10001100011001110010000

O Código está disponível aqui: Exemplo do Algoritmo Genético (51)

III System Overview

Consideramos nesse artigo a presença de um dispositivo real de decodificação de DTV(Plataforma de desenvolvimento Micronas IDTV) no dispositivo Android, que é responsável pela integração entre o SoC (system on chip) e os dispositivos periféricos. O SoC contém um processador dedicado para Linux de 240Mhz MIPS 24Kc, múltiplos processadores dedicados para decodificação de Áudio e Vídeo, unidade de processamento gráfico (GPU) , acelerador gráfico (GA), controlador USB e ainda Kernel Linux 2.6.21.7 com drivers competíveis (para todos os dispositivos no SoC), GNU gcc/glibc cross toolchain, biblioteca gráfica com suporte a DirectFB, etc.

IV Portando o Android

O processo necessário para portar o Android para uma plataforma big-endian (Arquitetura de ordenação numérica) pode ser dividida em três etapas. Primeiro a importância da utilização a Plataforma Micronas fornecido pelo Kernel do Linux versão 2.6.21.7 que é considerado velho comparando-se com os Kerneis atuais, mas que torna o processo de utilização pelos frameworks da plataforma de drivers do Kernel nessa versão mais fácil que em versões superiores e consequentemente os drivers do Kernel utilizados pelo Android precisam de um backport para o Kernel em questão. A segunda fase da portabilidade exige um processo de extensão do ambiente de desenvolvimento do Android para suportar a Plataforma big-endian MIPS; essas configurações de ambiente devem ser definidas no processo de compilação. A última fase da portabilidade da arquitetura de pilhas do Android consiste na integração de drivers de áudio e suporte ao DirectFB vídeo frame-buffer.

1. Backport para Kernel do Linux
   Alguns drivers precisaram ser adicionados na raiz do Kernel para dar suporte à plataforma Android, são eles: 
   • ASHMEM (Anonymous SHared MEMory, Memória compartilhada anônima) – É um gerenciador de memoria compartilhada similar ao POSIX SHM, mas com diferentes comportamentos; tem suporte à API baseada em arquivos simplificada.
   • Binder for Android (Android) – um CORBA semelhante ao IPC (inter process comunication, ou processo de comunicação interno).
   • Android event logger – Um drive responsável por receptar e catalogar as mensagens de depuração diretamente no Kernel.

   A raiz do Kernel 2.6.21.7 teve que ser modificada várias vezes para conceder o suporte necessário à plataforma Android e todos os novos drivers já mencionados anteriormente.

2. Modificação do Ambiente de Desenvolvimento AndroidO Android é facilmente portável em plataformas little-endian MIPS, mas devido as diferentes plataformas endianes (nosso caso a big-endian) inúmeras modificações na Arquitetura do Android são necessárias.
   • O primeiro tipo de modificação a ser realizada é em relação aos binários nativos da plataforma, principalmente em bibliotecas open sources e programas escritos em C/C++ (o suporte endianes é normalmente mantido nos sistemas internos de compilação (na maior parta das vezes no “autoconf”)). O Sistema de criação de makefiles do Android também deve ser alterado para dar suporte as variáveis que faltavam no big-endian e defines.
   • O Segundo tipo de alteração foi em relação ao código necessário para desenvolver ferramentas para um endian pouco utilizado. Bugs assim são raros e difíceis de encontrar, e geralmente resultam na falha ao compilar o Android e impossibilitam a plataforma de iniciar. Entre os programas que foram afetados estão o Android pre-linker Apriori, Soslim, gerenciador de recursos aapt (Android Asset Packaging Tools), etc.
   • O terceiro e último tipo de modificação inclui um impulsionamento extra no aprendizado em codificações de bibliotecas e programas endians . Como exemplo temos a Dalvk Virtual Machine(que apoia, abertamente, as plataformas endians). O uso de ponteiros para atribuições de tipos de dados variáveis funciona corretamente para a arquitetura little-endian, mas impossibilita que o código seja portado para plataformas big-endian. A culpa disso está na estrutura JValue que em todo o código da VM, utiliza muitos valores como containers de tipos. Problemas da mesma espécie foram encontrados na biblioteca do logger. Algumas outras poucas modificações foram realizadas correção de problemas com cores, na ordenação endian , no Skia engine e na superfície deflectora (Surface Flinger).
3. Suporte ao DirectFB no Android DirectFB (Direct Frame Buffer) framework é uma biblioteca baseada no GNU/Linux/UNIX com baixo consumo de memória que permite aceleração gráfica, manipulação de dispositivos de entrada, etc. sobre o frame-buffer do Linux. Por ser open source, vários produtores de SoC DTV o utilizam para implementar seus drivers para frame-buffer IPs.O Android suporta o driver para frame-buffer padrão do Linux como camada principal de desenho. Como os principais fornecedores de SoC DTV implementam a aceleração de hardware com drivers de vídeo do DirectFB, o suporte para essa tecnologia é implementado em várias níveis dentro da Arquitetura de Pilha do Android, dando suporte ao processo de desenho da interface (UI) e para aceleração de gráficos via hardware.
   • Alocação Gráfica do DirectFB foi implementada para suportar alocação da memória do frame-buffer de vídeo primário, bem como todos os outros tipos de camadas com escala de cores diferentes.
   • A biblioteca DirectFB copybit foi implementada para dar suporte a aceleração de hardware 2D blitter. Caso o driver fornecido do DirectFB suporte as operações 2D blittings (blit, stretch-blit, entre varias escalas de cores) a unidade central de processamento será poupada de processar as blit tasks.

   A única resistência em usar o DirectFB como frame-buffer da interface gráfica é por ele não suportar aceleração 3D. O constante emprenho no desenvolvimento da biblioteca DirectFB ao longo dos últimos dois anos (houve tentativas de implantar o OpenGL como mecanismo de aceleração 3D) indica que será possível a Aceleração de Hardware 3D, se a Aceleração de Hardware 3D IP estiver presente.

Artigo: Google’s android as an application environment for DTV decoder system
Kuzmanovic, N. Maruna, T. Savic, M. Miljkovic, G. Isailovic, D.
Fac. of Tech. Sci., Univ. of Novi Sad, Novi Sad, Serbia

Google Android e TV Digital

Hoje em dia, DTV’s (TV Digitais) e set-top boxs[equipamento que se conecta a um televisor e a uma fonte externa de sinal] (ainda mais em dispositivos multimídia) são controlados por softwares proprietários (Aplicações e sistemas operacionais), geralmente escritos para apenas um tipo específico ou grupo de modelos semelhantes de dispositivos. A Reutilização de código entre diferentes modelos desses dispositivos é muito rara e o desenvolvimento acaba exigindo muito tempo e esforço no ciclo de desenvolvimento para cada plataforma.

A diferença entre os Hand-Helds e os dispositivos tecnológicos multimídia utilizados em casa está diminuindo gradativamente e seus respectivos hardwares (poder de processamento da CPU, RAM disponível, tamanho da memória flash e a presença de outros dispositivos como Redes, Wi-FI, Bluetooth, Aceleração de gráficos via Hardware, etc.) estão se tornando mais semelhantes. Ao longo do tempo o principal objetivo desses dispositivos não é alterado, embora características novas e mais avançadas sejam incorporadas constantemente(Gravação de Vídeo, Internet, TV, Internet e etc..)

Android é o primeiro sistema operacional para dispositivos móveis totalmente aberto e livre, foi desenvolvido pela Open Handset Alliance (Grupo com mais de 30 empresas lideradas pela Google).  O Android está se tornando muito popular no mercado dos aplicativos móveis por duas razões principais. Primeiro que seu código conte é totalmente gratuito e não há taxas de royality para a Java VM, assim cada fabricante pode modifica-lo de acordo com suas necessidades. Segundo é que essa nova plataforma está em fase de expansão, valorizando muito desenvolvedores que atuam nessa área.

Este artigo apresenta uma abordagem sobre a utilização do Google Android como um ambiente para desenvolvimento de aplicações para dispositivos móveis embutidos, principalmente TV Digital e sistemas decodificador como set-top box. A utilização da portabilidade e a possibilidade de modificação do Android, por sua disponibilidade (por ser código aberto) e por utilizar camada de abstração de Hardware do Kernel do Linux fundamenta sua utilização no projeto. A Arquitetura e pilha utilizado pelo Android e o Kernel do Linux concedem aos desenvolvedores acesso aos recursos de multimídia e telefônicos, conectividade por rede, interface gráfica dentre outros.

II Arquitetura do Android

Arquitetura em Pilhas do Android

O Android depende de serviços do sistema central do Kernel do Linux, como recursos de segurança, gerenciamento de memória, gerenciamento de processos, pilha de rede e sistema de drivers. O Kernel atua, também, como uma camada de abstração entre o hardware e todo o resto do sistema.

As Bibliotecas nativas do Android são escritas em C/C++ e utilizadas por vários componentes do sistema operacional. Os recursos são disponibilizados para os desenvolvedores através do Android Application Framework. Podemos destacar algumas das principais bibliotecas e recursos presentes na plataforma como: System C Library(Implementação da C system library(libc), derivada da BSD, e modificada para sistemas embutidos para dispositivos baseados em Linux), Bibliotecas de Mídias (baseada em PureVideo OpenCORE; bibliotecas de reprodução e gravação dos mais populares formatos de áudio e vídeo, assim como arquivos de imagens), bibliotecas do Webkit (Motor de navegação moderno e muito conhecido que alimenta o browser do Android), Bibliotecas do OpenGL ES 3D (utilizam aceleração de hardware 3D, e se disponível, uma otimizada implementação de software de “rasterização” 3D), FreeType(renderização de fontes tanto vetoriais quanto oriundas de bitmaps), SQLite (um poderoso e leve banco de dados relacional disponível para todas as aplicações), além de outros tantos recursos possíveis.

O Android run-time inclui um conjunto de bibliotecas que disponibiliza uma considerável parte dos recursos existentes na linguagem de programação Java. Cada instância de uma aplicação Android roda em processos separadamente, utilizando-se da Dalvik VM (Máquina Virtual baseada em registros, executa classes compiladas em Java, transformando-as em Executáveis Dalvik(.dex) formato otimizados para dispositivos embarcados, com baixo consumo de memória). A Dalvik VM usa o Kernel do Linux para funcionalidades subjacentes, tais como segmentação de memória em baixo nível.

Ao conceder pleno acesso à API, os desenvolvedores estão livres para aproveitar dos recursos do Framework Android, como: hardwares, informações sobre localização, serviços em segundo plano, definir alarmes, adicionar notificações e ainda reutilizar e substituir componentes existentes. Resumindo, o Android fornece uma plataforma de desenvolvimento aberta, oferecendo condições para que se possa desenvolver aplicações modernas e poderosas.

A camada de aplicação é posicionada no topo da pilha do sistema, essa camada acomoda a maioria das aplicações integradas (programa de SMS, cliente de e-mail, calendário, mapas, navegador web, telefone, etc.) bem como aplicações desenvolvidas por terceiros baixadas da internet ou instaladas via Cartão de Memoria (SDcard).

Tradução do Artigo: Google’s android as an application environment for DTV decoder system
Kuzmanovic, N. Maruna, T. Savic, M. Miljkovic, G. Isailovic, D.
Fac. of Tech. Sci., Univ. of Novi Sad, Novi Sad, Serbia

Figura 1: Mapeamento de Tabelas – Simples

Porém, nem sempre o mapeamento é tão simples assim. No caso de uma estrutura hierárquica, várias classes podem ser mapeadas para uma tabela, bem como uma classe pode ser mapeada para várias tabelas. Esse mapeamento mais complexo de classes e tabelas pode ser observado na Figura 2.

Figura 2: Mapeamento     de Tabelas – Complexo

As tabelas Classe1 e Classe2 possuem, respectivamente, relacionamento com as tabelas Tabela1 e Tabela3. Esse mapeamento seria de certa forma trivial, e poderia ser tratado como relacionamento simples. Um terceiro relacionamento feito pelas duas tabelas impossibilita esse tratamento, pois ambas possuem atributos na Tabela2. Dessa forma é necessário que haja uma especificação de quais atributos pertencem a cada classe na Tabela2.

Ao tratar do mapeamento de atributos de uma classe para colunas em tabelas de um banco de dados relacional, deve-se levar em conta que os atributos podem ser de tipos de dados primitivos como inteiros, pontos flutuantes, caracteres, booleanos e binários, bem como ser de tipos de dados complexos como tipos baseados criados pelo usuário. Os atributos podem ser ainda multivalorados, o que viola as regras de normalização do modelo relacional.

Além disso, podem existir atributos de controle ou utilizados em cálculos, que geralmente não necessitam serem mapeados (AMBLER, 1999). Desta forma, os atributos simples podem ser mapeados diretamente para colunas em uma tabela, já os atributos complexos e multivalorados podem necessitar de tabelas adicionais para seu armazenamento. Estes atributos complexos, geralmente, possuem características recursivas, ou seja, são classes que possuem outros atributos e, assim, sucessivamente.
O mapeamento segue o seguinte conceito: as classes mapeiam cada uma das tabelas do banco de dados de modo que as linhas dessas tabelas se tornam objetos e as colunas referem-se aos atributos dessa classe. Esse conceito pode ser visualizado na Figura 3.

Figura 3: Mapeamento de Tabelas, Objetos e Atributos

Essa técnica possibilita mais do que códigos limpos, permite que persistências de objetos no banco de dados sejam feitas sem simples e transparente.

O ORM se comporta como uma camada que possui uma gama de métodos que cuidam dessa tarefa, tais como: create (cria um novo objeto da classe a partir dos dados da tabela), find (busca um determinado registro no banco e o torna um objeto da classe), delete (exclui registros do banco) e update (atualiza registros de uma tabela de acordo com as solicitações). Esses métodos variam de acordo com a linguagem utilizada.

Na Tabela 1, é possível observar um pouco das facilidades e de como a legibilidade do código fica melhor ao se utilizar o ORM ao invés de se injetar dentro de seu código o SQL puro, o que fere as boas práticas de programação, que sugere que códigos SQL estejam separados dos códigos de desenvolvimento (RODRIGES; COSTA; SILVEIR, 2001).

Essa camada, chamada de persistência, encontra-se entre a camada de negócio (onde estão as classes de domínio da aplicação, ou seja, classes que definem as regras de negócio) e o banco de dados. Esta camada permite que o impacto das modificações em uma delas seja atenuado em relação à outra. Isto diminui o grau de dependência do banco de dados e aumenta a facilidade de manutenção do código. Na Figura 4 pode-se analisar a disposição dessas camadas.

Figura 4: Camada de Persistência

Toda responsabilidade por persistir objetos fica a cargo da camada de persistência, liberando a aplicação destas tarefas, e assim aumentando a produtividade no desenvolvimento (YODER; JOHNSON; WILSON,1998). Na camada de persistência está a definição das estratégias de mapeamento do modelo orientado a objetos para o modelo relacional, apresentadas anteriormente.
A camada de classes representa todo o conjunto de classes (controllers, views dentre outras) que podem utilizar métodos da camada de persistência. Assim, as transações com o banco de dados ficam transparentes.
Artigo da série:

Segundo Herrington (2003), a geração de código é a técnica pela qual se constrói código utilizando programas. Os geradores de código podem trabalhar por meio de linhas de comando ou de interfaces gráficas, estas últimas são as formas mais interativas. Estes podem construir código em várias linguagens de programação, bem como efetuar a geração dos códigos de uma única vez ou em etapas. As entradas e saídas são definidas conforme a necessidade, sendo que o desenvolvedor especifica parâmetros de saída de forma manual. Portanto, é de extrema relevância que o programador saiba a priori o que se deseja obter como resultado.

De acordo com Herrington (2003), a utilização de geradores para desenvolvimento de softwares traz enormes vantagens aos códigos gerados, tais como:

• qualidade: a escrita de grande quantidade de código vai gradualmente diminuindo a qualidade final do software. Na geração automática, a qualidade do software está diretamente ligada à qualidade dos templates. Esse, por sua vez, não possui qualidade associada à quantidade de código a ser desenvolvida, visto que os templates possuem uma estrutura fixa que não é alterada pelo tamanho do projeto;
• consistência: o código gerado tende a ser consistente, pois possui uma padronização de nomenclatura de classes, métodos, variáveis e localização (pastas e subpastas), o que torna o código de fácil entendimento e modificação;
• único ponto de conhecimento: caso seja necessária uma alteração de alguma estrutura de entrada do projeto, necessita-se apenas saber o local onde essa modificação deve ser realizada. Após isso, o código gerado se propagará para todos os processos seguintes à alteração, gerando sempre um código compatível com as entradas;
• maior tempo para o projeto: considerando-se o uso de uma biblioteca externa (API), podem acontecer alterações nessa fonte obrigando assim que modificações sejam feitas em todas as partes do código em que aquela modificação irá influenciar. Com a utilização do gerador, esse processo poderá ser feito apenas nos templates do gerador e uma nova geração efetuará as mudanças necessárias no código. Essa característica faz toda a diferença em cronogramas de projetos que utilizam ou não geradores (forma manual);
• abstração: como, normalmente, os geradores utilizam os modelos abstratos de dados (templates) do código alvo, fica fácil migrar de uma plataforma/linguagem para outra, necessitando apenas uma revisão no escopo de abstração, ou seja, modificar os templates de acordo com as necessidades da plataforma/linguagem alvo;
• agilidade: uma característica chave da geração de código é a maleabilidade do código de saída. No nível de negócio, o software será de mais fácil manutenção e implementação de novas funcionalidades. Mesmo considerando-se o tempo que se economiza no ato da geração, podemos afirmar que essa técnica dá um grande percentual de agilidade ao desenvolvedor.

E ainda, segundo Herrington (2003), a construção de um gerador de código pode seguir as seguintes etapas de desenvolvimento:

• a definição de qual a saída se deseja obter;
• a identificação de qual entrada será utilizada e como essa será analisada;
• a definição de padrões na entrada, de como eles serão interpretados para obtenção e geração de uma saída formatada de acordo com as expectativas predefinidas; e
• a geração da saída a partir das informações extraídas da entrada.

Geradores de código são uma boa forma de agilizar o desenvolvimento e melhorar o nível de qualidade no início do projeto. Fatores, esses, que podem decidir o futuro de uma aplicação.

Artigo da série: