Autor: Vidal Martins - GPT - Ramal 381

A evolução constante e rápida das ferramentas de trabalho dos profissionais de informática exige um acompanhamento rigoroso das mudanças nesse mercado. E, atualmente, é tempo de Delphi. Este artigo tem o objetivo de apresentar uma comparação entre as principais ferramentas de front-end disponíveis no mercado, usadas no desenvolvimento de aplicações cliente/servidor: Delphi Client/Server Suite, Visual Basic Enterprise Edition, SQL Windows e PowerBuilder Enterprise for Windows.

Há muitas semelhanças entre esses produtos. Por exemplo, todos possuem uma forma rápida de gerar formulários a partir dos campos de uma tabela ou de uma query; todos acessam programas externos (DLLs), geram aplicações orientadas a eventos e aplicações cliente OLE, usam linguagem SQL e suportam ODBC; todos têm bons geradores de relatório, facilidades de check-in/check-out e controle de versões. Enfim, embora existam diversas diferenças entre as ferramentas, elas são capazes de produzir, basicamente, os mesmos resultados.

Para facilitar sua leitura, estruturamos o artigo nas seguintes seções:

Resumo da Avaliação: indica a fonte de pesquisa consultada e apresenta um resumo da comparação entre os produtos;

Performance: descreve detalhadamente como foi calculada a nota de performance desses produtos, durante a avaliação;

Versatilidade: descreve detalhadamente como foi calculada a nota de versatilidade dos produtos, durante a avaliação;

Nosso Ponto de Vista: lista vantagens e desvantagens do Delphi, segundo o nosso ponto de vista, baseado no curso que fizemos sobre o produto e na experiência com SQL Windows.

Resumo da Avaliação

A avaliação das ferramentas de front-end reproduzida neste artigo foi divulgada em uma publicação técnica chamada Software Digest, de março de 1996. A Software Digest é publicada pelo NSTL (National Software Testing Laboratories), uma divisão da Companhia McGraw-Hill que avalia software e hardware para PC e LAN.

Para elaborar esse teste, foram utilizados equipamentos Dell Dimension XPC P90 como estação de trabalho, dispondo de 24 Mb de RAM, 1 Gb de disco e sistema operacional Windows NT Workstation 3.51. O banco de dados de teste estava em uma máquina Digital DECpc Lpx 560 com 32 Mb de RAM, 1 Gb de disco, sistema operacional Windows NT Server 3.51 e sistema gerenciador de banco de dados Microsoft SQL Server 6.0.

A base de dados de apoio ao teste continha informações sobre pedidos de compra de livros. As tabelas dessa base eram: livros, autores, autor-livro, pedidos e itens do pedido. Cada item do pedido era, na realidade, um livro a ser comprado. A carga inicial da base de dados era a seguinte: 125.000 livros, 25.000 autores, 250.000 registros de ligação autor-livro (10 livros por autor, sendo 2 co-autores por livro), 50.000 pedidos e 250.000 itens (5 para cada pedido). Antes de iniciar o teste de cada produto, foi restaurada a base de dados, a partir de um backup, e reinicializado o servidor de banco de dados. O teste explorou a potencialidade das ferramentas para consultas de diversas formas, atualização da base de dados e geração de relatórios. Mais detalhes sobre os programas que foram codificados podem ser encontrados na seção Performance deste artigo.

Os critérios de avaliação adotados nesse comparativo foram os seguintes:

• facilidade de aprendizado: qualidade da documentação do software para descrever a conectividade com bancos de dados, o processo de desenvolvimento de aplicações simples e complexas, a geração de relatórios e o gerenciamento da aplicação;
• facilidade de uso: ergonomia do software em relação aos mesmos assuntos do item anterior - conectividade com bancos de dados, desenvolvimento de aplicações simples e complexas, geração de relatórios e gerenciamento da aplicação;
• versatilidade: para avaliar este critério, foram consideradas mais de 250 características dos produtos, agrupadas em três categorias:
• acesso aos dados: trata de como o produto acessa os dados em um ambiente cliente/servidor, bem como das facilidades para o desenvolvimento de protótipos localmente e da portabilidade desses protótipos para o ambiente cliente/servidor. Também inclui os vários bancos de dados suportados, e o uso das características específicas de cada engine;
• características das aplicações: trata das funcionalidades que podem ser incorporadas às aplicações, tais como formulários, queries, relatórios, facilidades para a manipulação de eventos e gerenciamento de objetos;
• gerenciamento das aplicações: trata das facilidades para melhorar a produtividade do desenvolvedor e o gerenciamento do ambiente de desenvolvimento, incluindo características de workgroup, armazenamento de objetos e a instalação de aplicações runtime.
• performance: tempo de resposta em 12 procedimentos diferentes, explicados na próxima seção.

O resultado final da avaliação foi este:

Vamos analisar mais algumas informações interessantes sobre cada produto estudado.

Delphi Client/Server Suite 2.0

Requisitos: processador 486/25, 8 Mb de memória para desenvolvimento (12 Mb recomendado) e 8 Mb para a execução das aplicações, 50 Mb de espaço em disco, sistema operacional Windows 95 ou Windows NT 3.51.

Pontos fortes: performance excepcional, versatilidade geral excelente, fácil de desenvolver aplicações que acessam dados, bom suporte para componentes customizados.

Limitações: relativamente difícil de aprender, relativamente fraco em ferramentas para relatório.

Facilidade de aprendizado: o NTSL avaliou uma versão prerelease do Delphi, com muitas falhas de documentação.

Facilidade de uso: fornece os mecanismos mais convenientes para permitir que as aplicações acessem bancos de dados (Fields Editor, Mestre/Detalhe, Controle de Navegação - que permite consulta e atualização-Data Modules); compila uma aplicação inteira gerando um único arquivo executável; tem boas facilidades para armazenar objetos customizados e disponibilizá-los para as aplicações; o tratamento de eventos a nível de registro é mais difícil do que nos outros produtos; oferece dois geradores de relatório, um que não está bem integrado com a ferramenta (ReportSmith) e outro muito bem integrado, mas difícil de usar.

Outras características: permite sincronizar datasets mestre e detalhe sem programação adicional; permite incluir, excluir e alterar registros sem qualquer programação adicional; possui o suporte para automação remota mais completo; tem o depurador mais robusto (mostra a pilha de chamadas a procedimentos e funções, característica necessária quando se faz grande reuso de código); oferece mais opções de instalação; não executa um evento cada vez que o usuário se movimenta para um novo registro na tela.

Visual Basic Enterprise Edition 4.0

Requisitos: processador 486/25, 6 Mb de memória para desenvolvimento e 6 Mb para a execução das aplicações, 20 Mb a 80 Mb de espaço em disco, sistema operacional Windows 3.1, Windows 95 ou Windows NT.

 Pontos fortes: boa performance, excelentes ferramentas de relatório, bom suporte para automação remota, excelente depurador.

 Limitações: faltam facilidades para desenho de formulários que os outros possuem; é fraco em administração de banco de dados; conexão com banco de dados apenas via ODBC.

Facilidade de aprendizado: a documentação do Visual Basic não é tão extensa, mas é bem organizada com bons índices para busca de informações em cada manual; embora não seja o único produto a oferecer automação remota, permitindo, portanto, o particionamento de aplicações, é o único produto que oferece documentação clara e completa sobre como implementar essa funcionalidade; falta um pouco de referência cruzada; as diferenças sintáticas entre os métodos de acesso a banco de dados (Remote Data Objects e Jet) podem confundir usuários novos.

Facilidade de uso: é similar ao Delphi em muitas coisas, porém, o acesso a dados da Microsoft é mais interessante em alguns aspectos; por exemplo, a navegação está incorporada no data control e não existe controle data source separado das tabelas e queries; é mais fácil gerenciar o código relacionado aos objetos do formulário do que no Delphi; oferece o melhor suporte a OLE 2.0 entre todos os produtos; possui as melhores ferramentas para desenho e incoporação de relatórios nas aplicações; muitas características controladas pela configuração de propriedades no Delphi requer programação no Visual Basic; usar stored procedures do SQL Server no Visual Basic é mais difícil do que nos outros produtos. Requer arquivos diferentes de runtime, dependendo dos componentes utilizados.

Outras características: fornece excelente suporte para automação remota.

SQL Windows 5.0

Requisitos: processador 486 para o desenvolvimento e 386 para a execução de aplicações, 8 Mb de memória para o desenvolvimento e 4 Mb para a execução de aplicações, 24 Mb de espaço em disco, sistema operacional Windows 3.1, Windows 95, Windows NT e Win/OS2.

Pontos fortes: excelentes recursos para trabalho em equipe, acesso a bancos de dados robusto, excelente versatilidade em geral.

Limitações: performance inferior, não suporta aplicações 32-bits, relativamente difícil de usar.

Facilidade de aprendizado: o SQL Windows é o produto mais complexo e oferece apenas manuais de referência para os vários componentes, ao invés de descrições de procedimentos (instruções how-to).

Facilidade de uso: possui um conjunto padrão de arquivos runtime para distribuição; o Team Windows fornece o suporte mais compreensivo para desenvolvimento em equipe, mas ele não está bem integrado com o resto da ferramenta; o Outliner do SQL Windows é a interface menos amigável de todos os produtos, sendo que a alternância entre o formulário visual e o código do programa é um tanto desajeitada; um ponto positivo é que o Outliner permite selecionar eventos, funções, variáveis, etc., de caixas de listagem, durante a codificação; os usuários podem desenhar formulários através de ferramentas visuais como Quest e QuickForms, mas o NSTL não pôde usá-las devido à limitação em 32.768 registros; para datasets maiores é necessário usar cursores SQL e transferir os dados desses cursores para os campos da tela via programação; emprega um conjunto complexo de procedimentos para controlar relatórios produzidos através do Report Windows.

Outras características: a manipulação de eventos do SQL Windows é a mais completa; suporta a maior quantidade de características específicas dos bancos de dados.

PowerBuilder Enterprise for Windows 4.0

Requisitos: processador 386, 8 Mb de memória para desenvolvimento e 8 Mb para a execução das aplicações, 19 Mb de espaço em disco, sistema operacional Windows 3.0 e Windows NT.

Pontos fortes: excelente documentação, fácil de aprender, fácil de desenhar formulários.

Limitações: performance inferior, ferramentas de relatório pouco integradas, poucos recursos para trabalho em equipe.

Facilidade de aprendizado: fornece um conjunto excepcional de manuais, organizados logicamente para facilitar tanto o aprendizado quanto referências de usuários dos mais diversos níveis.

Facilidade de uso: possui um conjunto padrão de arquivos runtime para distribuição; fornece excelentes ferramentas visuais que permitem a criação rápida de objetos DataWindow para acesso ao banco de dados; um ponto negativo é que o DataWindow é tratado como um único objeto, requerendo movimento entre o Window Painter e o DataWindow Painter para customizar a aparência; o tratamento de eventos relacionados aos componentes individuais dentro de um DataWindow requer programação complexa; o módulo InfoMaker é uma ferramenta excelente para desenho de relatórios, porém, é extremamente difícil incorporar relatórios InfoMaker em aplicações PowerBuilder.

Outras características: não possui controle de versões embutido; não possui repositório de objetos; falta suporte para automação remota; tem o depurador mais fraco de todos.

Performance

Com relação à performance, a Software Digest faz a seguinte citação: "...O Delphi não tem rival nas operações de consulta em grandes datasets, pois gasta menos de um quarto do tempo do seu competidor mais próximo para acessar o result set completo, e menos da metade do tempo para aplicar um filtro. Quando ele não é o mais rápido, fica muito próximo do líder, em todos os casos. A única exceção é para relatórios complexos, onde o ReportSmith requer tempo extra para conectar com o database; mesmo assim, ele é o segundo mais rápido, neste caso..."

Para esclarecer de que forma o NSTL chegou a esta conclusão, apresentaremos a seguir as doze operações que eles programaram, executaram e cronometraram, a fim de medir o desempenho dos produtos.

Foi registrado o tempo necessário para executar a query, para mostrar a primeira página do relatório no modo preview, para se movimentar até o fim dele nesse modo, e para imprimir a última página cheia do relatório. O número apresentado no gráfico representa o tempo acumulado dessas operações. Para um relatório deste tamanho e complexidade é mais viável usar o ReportSmith do Delphi. Embora tenha sido gasto um tempo extra para carregar o ReportSmith, e a velocidade de impressão tenha sido um pouco mais lenta, a sua velocidade de recuperação de dados foi substancialmente mais rápida neste teste. No relatório simples ele foi mais do que duas vezes mais lento que o componente integrado.

1. Análise de String

Leitura de arquivo texto contendo registros cujos valores são separados por tabulações e vírgulas. O programa quebra o string em partes, realiza processamento baseado nos valores dessas partes e carrega os resultados para uma tabela do formulário. Ele não faz acesso a banco de dados

2. Pesquisa pelo ISBN

O usuário entra com um ISBN e o programa mostra todas as informações do respectivo livro, incluindo uma listagem dos co-autores. Em seguida, o usuário entra com a quantidade que deseja comprar e o programa adiciona uma linha na tela para esse item do pedido.

3. Pesquisa por Autor

O usuário entra com nome parcial e o programa lista todos os autores correspondentes a esse nome. Em seguida, o usuário seleciona o autor da lista e o programa lista todos os livros escritos por esse autor. Finalmente, o usuário seleciona um livro e o processamento continua como na pesquisa pelo ISBN.

4. Pesquisa pelo Título

O usuário entra com um título parcial de livro e o programa lista todos os livros correnpondentes. Em seguida, o usuário seleciona um livro e o processamento continua como na pesquisa pelo ISBN.

5. Inclusão de Pedido

O pedido construído durante os três testes anteriores é cadastrado. Isto envolve a inclusão de um registro na tabela de produtos e, para cada item solicitado, a inclusão de um registro na tabela de itens e atualização do livro correspondente. Delphi e Visual Basic contróem um único comando para realizar todos os inserts e updates, e manda isso como uma única operação para o banco de dados. PowerBuilder e SQL Windows usam comandos padrão SQL com variáveis de programa. O SQL Windows empacota em uma única operação todos os inserts na tabela de itens.

6. Consula à Tabela de Pedidos

Foi registrado o tempo necessário para carregar a tela de consulta dos pedidos. Isto envolve a leitura dos registros da tabela de pedidos e a apresentação do primeito deles, acompanhado dos itens correspondentes (mestre/detalhe). O SQL Windows permite passar o controle da aplicação para o usuário imediatamente após recuperar os registros necessários para completar uma tela, e continua lendo os demais registros do result set em background. Por isso, a sua superioridade neste teste. O PowerBuilder também oferece esta opção, mas quando ela é usada para acessar o result set completo em operações de filtragem e pesquisa, ela fica muito limitada. O tempo do Delphi é extraordinário, se considerarmos que ele acessou o dataset completo (50.000 registros) e então, diferente do SQL Windows, requer pequeno ou nenhum tempo adicional para acessar outros registros no dataset.

7. Acesso Completo ao Dataset

Foi medido o tempo necessário para se movimentar até o último registro do result set, partindo do teste anterior, e para mostrar esse registro na tela, juntamente com os itens de pedido correspondentes. Esse tempo somado ao do teste anterior representa o tempo total necessário para um acesso completo ao dataset. O Delphi realmente leva um puco mais de tempo que o Visual Basic e o PowerBuilder para fazer essa movimentação (respectivamente 1.1, 0.9, 0.6), porém o seu tempo total de acesso ainda está completamente isolado.

8. Atualização do Registro

Depois que um usuário modificou o valor de um campo do formulário, foi registrado o tempo necessário para gravar a mudança no banco de dados e retornar o controle ao usuário. O Visual Basic tem um método de atualização de linha associado ao remote data control, enquanto o Delphi tem um botão de update no navigation control. O SQL Windows usa um comando SQL explícito para atualizar o registro corrente. O PowerBuilder executa atualizações a nível de DataWindow. Isto permite que múltiplos registros sejam modificados antes que as alterações sejam gravadas no banco de dados, mas também requer que seja verificado em todo o dataset se houve mudança antes de executar o update.

9. Pesquisa por um valor específico

Usando o formulário de consulta de pedidos, o programa procura por um registro que contenha o nome do cliente especificado pelo usuário e mostra esse registro, juntamente com os itens de pedido correspondentes. O Delphi muda o índice corrente para fazer a pesquisa. Isto altera a ordem de classificação dos dados na tela. Para manter a classificação original é necessário fazer duas pesquisas. O Delphi gasta menos tempo para fazer essas duas pesquisas do que os outros produtos para fazer em apenas uma. Visual Basic e SQL Windows não têm facilidades de pesquisa embutidas, tornando necessário o uso de consultas SQL para encontrar o registro procurado, determinar sua posição no result set original, e então mover-se até essa posição.

10. Aplicação de Filtro

Usando a tela de consulta de pedidos, o programa aplica um filtro para mostrar apenas os registros com CEPs dentro do intervalo especificado. Este teste é parecido com aquele chamado Consulta à Tabela de Pedidos, mas recupera menos registros. Aparentemente o SQL Windows é menos eficiente que os seus competidores para abrir um cursor e recuperar seu primeiro registro.

11. Relatório Simples

Este teste gera um relatório contendo registro de uma única tabela, pertencentes a um intervalo especificado, e classificados por um campo diferente daquele usado para seleção. Foi medido o tempo necessário para executar a consulta na qual o relatório está baseado, para mostrar a primeira página no modo preview, para se movimentar até o fim do relatório no modo preview e para imprimir a última página cheia do relatório. O número apresentado representa o tempo acumulado. SQL Delphi, Visual Basic e SQL Windows executaram o relatório usando suas conexões existentes com o banco de dados, ao invés de carregar um programa gerador de relatório separado e estabelecer uma nova conexão. O Delphi e o Visual Basic transformaram essa vantagem em um tempo de execução bem superior aos competidores. O Windows desperdiçou essa vantagem com uma recuperação de dados lenta.

12. Relatório Complexo

Este teste gera um relatório contendo os pedidos pertencentes a um intervalo especificado, todos os itens desses pedidos, incluindo o título do livro, e todos os autores de cada livro solicitado. O relatório está baseado em um join de 5 tabelas e possui 2 níveis de agrupamento aninhados. O título do livro excede a largura do relatório. Portanto, a parte que sobra é jogada para linha de baixo sem hifenização (word-wrapped). A ordem de classificação está baseada em um campo diferente daquele usado para a seleção dos dados.

Versatilidade

No relatório original do NSTL, cada item de versatilidade tem uma definição associada. A partir dessas definições foram avaliados todos os produtos. O objetivo era garantir igualdade de condições nos testes, pois o NSTL reconhece que os diversos produtos podem usar a mesma terminologia com significados diferentes. Cada característica de cada produto foi estudada usando a documentação disponível e teste prático. Os resultados foram verificados com os vendedores. A decisão final de dar ou não o crédito ao produto para uma característica foi do NSTL, depois de comparar a sua própria definição com a documentação do produto.

A tabela abaixo contém todas as características que foram apreciadas para medir a versatilidade dos produtos, e uma marca indicando quem recebeu o crédito. Uma descrição detalhada sobre o que significa cada característica pode ser encontrada no relatório original do NSTL.

Legenda

ABL Apenas banco de dados local.

ABS Apenas banco de dados SQLBase.

AF Aplicando filtro.

AP Apenas partida.

DOB Se suportado pelo driver ODBC do banco de dados.

DPA Disponível em produtos add-on.

ECN Extensões aos comandos nativos para processar resultados de queries (INTO e FETCH).

FE Usa funcionalidade equivalente do BDE.

FE Visual SourceSafe possui funcionalidade equivalente mas não em BD cliente-servidor.

IVP Pode ser implementado via programação.

JAS Jet Engine aceita comandos SQL.

JET Somente usando Jet Engine.

PS Disponível em produto separado.

PT Produto de terceiros.

PV Disponível na próxima versão.

RMD Pode definir relacionamentos mestre-detalhe.

RSB Simulado através da recuperação de status do banco de dados.

SPO Pode ser simulado pelo evento OnCalcFields.

TSP Mantido nas tabelas de sistema do PowerBuilder.

UCC Usando campos calculados

UIP Usando interface PVCS

Nosso Ponto de Vista

Embora o NSTL tenha feito um trabalho bem completo de avaliação, gostaríamos de acrescentar algumas vantagens e desvantagens do Delphi, especificamente em relação ao SQL Windows, que é a ferramenta padrão da Celepar, atualmente.

Vantagens do Delphi

• Arquitetura escalável: a mesma ferramenta permite criar soluções desktop, departamentais (two-tier) e corporativas (multi-tier). Além disso, possui drivers nativos para os RDBMS mais usados no mundo.

Soluções abertas:

• Existe uma série de empresas construindo componentes para o ambiente de desenvolvimento Delphi;
• O código fonte da própria ferramenta é aberto, isto é, você pode personalizá-la. Por exemplo, o Delphi possui um componente chamado Hint para implementar aquelas dicas que explicam a função de um botão do formulário, mas esse componente constrói dicas de uma linha apenas. Isto significa que, embora ele seja muito parecido com os helps de contexto, não poderia ser usado para montar uma explicação de múltiplas linhas. Se nós precisássemos realmente disso, poderíamos abrir o código do Hint, adaptá-lo para múltiplas linhas e criar um novo componente;
• A Borland comprou a OEC (Open Environment Corporation), uma empresa pioneira no desenvolvimento de soluções cliente/servidor altamente escaláveis. A OEC já possui uma família de produtos, chamada Entera, que suporta a criação de aplicações multi-tier, simplificando o uso de tecnologias de computação distribuída como RPC, CORBA, DCE, DCOM, acesso a bancos de dados corporativos e a aplicações mainframe.
• Alta performance: além de usar drivers nativos para conexão com RDBMS, o compilador Delphi gera 100% de código objeto, a partir do fonte Object Pascal, ou seja, não há necessidade de interpretadores runtime.
• Modularização: as Units são compiladas individualmente, o que torna a aplicação mais modular e agiliza o tempo de compilação para o projeto. Quando as Units são compiladas, elas criam um arquivo com a extensão DCU (Delphi Compiled Unit) com o mesmo nome do arquivo PAS. As DCUs nos permitem esconder o código fonte.
• Orientação a Objetos: o Delphi trabalha baseado em componentes; já o SQL Windows não incentiva o uso de Quick Objects, devido a questões de performance.

Flexibilidade:

• a auto-criação de fomulários em Delphi torna a carga da aplicação mais lenta, consome mais memória, mas simplifica o gerenciamento do sistema; se houver a necessidade de otimizar a carga da aplicação e economizar memória, o próprio programador pode controlar a criação e a destruição dos formulários;
•  Permite selecionar diversos objetos do formulário simultaneamente. Após essa operação, o Object Inspector apresentará apenas as propriedades comuns a todos os objetos selecionados, permitindo que elas sejam padronizadas, ou seja, o valor atribuído a cada propriedade está sendo configurado simultaneamente para todos os objetos selecionados;
•  Permite criar menu popup (menu de contexto).

Simplicidade:

• devido aos Data Modules, as aplicações Delphi estão naturalmente preparadas para three-tier;
• Os datasets são componentes de software (classes) que disponibilizam os métodos INSERT, DELETE, EDIT, FIRST, NEXT, etc. Em outras palavras, o programador não precisa conhecer SQL e cursores, pois o componente encapsula a execução desses comandos.
• Em tempo de projeto você acessa a base de dados e vê o que está acontecendo.
• Cultura: a linguagem Pascal é muito mais conhecida que SAL.

Desvantagens do Delphi

• Integridade: quando se apaga um botão, as rotinas criadas para ele não se apagam. Nisto, o SQL Windows é melhor. A Borland argumenta que esse fato se deve ao uso de um paradigma chamado Modelo de Delegação, através do qual mais de um objeto pode referenciar a mesma rotina de tratamento de evento.
• Os erros de compilação são reportados acrescentado-se o caminho completo de onde se encontra a Unit. Há dois problemas em relação a isso: consome espaço na tela; e não existe barra de rolagem para ver o final da linha.
• Sempre que é acionada a guia Localizar do help, o Delphi refaz a lista de palavras e essa operação é muito lenta. Além disso, a documentação não está completa. É possível obter na Internet um complemento de aproximadamente 10 Mb para essa documentação.
• Existem quatro opções de salvamento diferentes. Quem não sabe exatamente como funciona cada uma delas tem bastante dificuldade para armazenar o trabalho realizado e recuperar mais tarde.
• O Outliner do SQL Windows permite obter nomes de constantes, variáveis, funções, formatos de comandos, etc., a partir de caixas de listagem. Os objetos disponíveis nessas caixas dependem do contexto. Por essa razão, é mais difícil cometer erros de codificação no SQL Windows.
• As mensagens Yes, No, Cancel, etc., não assumem a configuração do Windows. Para traduzí-las temos que comprar o Borland Language Packet, produto adicional para a localização de software.
• O ambiente de programação do Delphi é SDI. Quando se abrem diversos formulários simultaneamente, a distribuição deles na tela fica confusa e não há como organizá-los automaticamente.