sábado, dezembro 29, 2007

Algoritmos difíceis, adoro eles

Adoro programar. Não sei se já disse isso, então, estou dizendo agora. Mas nada de telas de cadastro e coisas do gênero - isso eu deixo para o Merlin. Pois bem, acontece que em certos momentos, esses tal de algoritmos, nos deixam de cabelo em pé.

Fazia tempo que não acontecia. Um marasmo danado, desenvolvendo coisas - quase - toscas. Mas enfim, a calmaria passou e uma coisa bem cabeluda me atasanou (minha mãe usa essa palavras às vezes, não sei se o Aurélio a define) durante uma tarde inteira.

Ela fora quase tão medonha quanto o algoritmo essencial de layout feito no Merlin, lá nos idos de Setembro do ano passado. Pois bem, estou falando de um mapa de cache hierárquico de três níveis.

Sim, programando o Magoo, precisei de uma estrutura dessas, e com objetos tipados para facilitar a vida do desenvolvedor final (e nem vão me pagar uma bira por isso).

A idéia básica da coisa é um método putAndReturn(), que a gente passa uma String com o nome de um sistema da federação (podendo usar a sintaxe CamelCase ou a notação baseada em ponto); o formulário desejado (como um JFrame ou um JDialog - no caso do Swing) e o componente de tela (como um JTextBox, JComboBox, etc.) para o sistema adicionar esse controle dentro da estrutura de mapas. Como retorno, se tem um número inteiro longo que é a sequência do controle, baseada em seu tipo e dependente do sistema, do formulário e o tipo do controle :)

A coisa complica um pouco, porque, caso os mapas estiverem vazios (e estarão nas primeiras chamadas), a estrutura deve se auto-inicializar.

Pra não enrolar mais, vai o screenshot do algoritmo. Foram 4:33h de programação para essas míseras 23 linhas de código. Em outras palavras, quase 12 minutos por linha! Ninguém merece.


Bom, pra finalizar, a graça na coisa: tudo isso depois vira software livre :)

quinta-feira, dezembro 27, 2007

Estimativa de Projeto Por Pontos de Caso de Uso

Hoje vou falar de um assunto que estou estudando para nossa metodologia de desenvolvimento, que deve rolar como parceria entre a 3Layer Tecnologia e a Pandorga Tecnologia. O tema é Use Case Points.

Para os apressados, vão para o fim do post.

Para um texto completo sobre o assunto, os artigos Project Estimation With Use Case Points, de Roy K. Clemmons e Estimating Software Based on Use Case Points, de Edward R. Carroll, são bons guias.

Motivação
Por que Use Case Points? Porque, no nosso processo, e devido às emergumenas perguntas de custo e valores que são feitas logo no início dos projetos - quando nada ainda foi detalhado, a aplicação de técnicas como COCOMO ou FPA têm pouco efeito, visto que elas necessitam, respectivamente, de um elevado histórico de projetos, ou de um grande detalhamento de requisitos. Nem um dos dois casos se aplica aos nossos projetos. E difícil seria encontrar uma empresa disposta a arcar custos de pré-análise (às vezes, durante mais de um ano de atividades) para fechar o escopo detalhado de um sistema. Aí entra o Use Case Point.

Use Case Point
Use Case Point é uma técnica muito interessante quando a equipe tem experiência na criação de Casos de Uso (e, por elegância, UML e Orientação a Objetos e algum processo derivado do RUP, como UP, o Agile ou mesmo o XP não-agressivo) e não existem detalhamentos maiores do sistema do que...os próprios Casos de Uso!

Se sua equipe não tem experiência nessas áreas...bem, então procure outra técnica; desista de estimar (e do) o projeto ou...minta para o cliente e para si mesmo :)

Se você se sentir seguro na criação de Casos de Uso, vá em frente. Tente (hic) no mínimo você terá um argumento para preencher os documentos para o cliente :)

A Fórmula Mágica
Brincadeiras à parte, a equação de três partes diz tudo:

UCP = UUCP * TCF * ECF

Mas e aí? O que é essa sopa de letrinhas? Vamos lá...

--
UCP é Use Case Point, e é o resultado que você deseja. Ele é adimensional e só tem sentido em relação a fórmula. No final ele é usado para calcular um valor de horas do projeto; mas até lá, acostume-se com ele - nada mais :)

--
UUCP significa Unadjusted Use Case Points, e nada mais é do que a somatório da multiplicação dos casos de uso por suas complexidades. Traduzindo em miúdos:

Supomos um sistema com 7 Casos de Uso simples, 13 médios e 3 complexos; o valor de UUCP é (7 * 5) + (13 * 10) + (3 * 15) = 210. Perceba os valores: casos de uso simples valem 5; médios, 10 e complexos, 15.

Essa complexidade é fixa (não existe um caso de uso muito-muito-muito complexo - em outras palavras, esse caso de uso está errado, e deve ser quebrado conforme as regras defendidas ilustramente por Cockburn em seu livro).

Uma dica simples de complexidades é (mas notem, estou sendo singelo mesmo!):
  • Simples (5 pontos) : Casos de uso para coisas como telas CRUD de uma entidade, com IU simples e sem interações externas; poucos passos no fluxo principal e pré-pós-condições baseadas em validações simples.
  • Médio (10 pontos): Casos de uso para coisas como telas CRUD mestre-detalhe de um nível e, até umas 3 entidades envolvidas; vários passos no fluxo principal e pré-pós-condições um pouco mais complexas de validação.
  • Complexo (15 pontos): Para coisas com mais de 3 entidades envolvidas, como mestre-detalhes de múltiplas tabs filhas ou mais de um grau de dependência. Muitos passos no fluxo principal e vários branches alternativos, com pré-pós-condições de validação complexas e possíveis chamadas de regras de negócio adicionais.
Na prática, converse com seu arquiteto para saber mais o que sua Infra oferece e orientar os analistas para nivelar os casos de uso.

Também, podem ser considerados os atores nas complexidades. Nesse caso, sua complexidade é dada por:
  • Simples (1 ponto): O ator é um sistema externo, acesso por uma API estável, simples e documentada.
  • Médio (2 pontos): O ator é um sistema externo, acessado via um protocolo de base como o FTP, SSH, WebServices ou TCP/IP; também pode ser uma pessoa que interage com o sistema através de uma IU modo caractere.
  • Complexo (3 pontos): O ator é uma pessoa que interage com o sistema através de uma IU gráfica; ou o ator é um sistema externo que deve ser acesso via integração de databases ou arquivos de formato intermediário de baixa documentação.
Se considerarmos os atores (e vamos considerar para engordar nosso exemplo), imaginemos 4 pessoas interagindo com o sistema através de uma IU gráfica (atores complexos) e nada mais. Assim, temos um subtotal de (4 * 3) = 12 pontos.

Somando os 21o pontos dos casos de uso com os 12 pontos dos atores, temos UUCP = 222 pontos.

--
TCF significa Technical Complexity Factor, e indica as complexidades técnicas que podem ser encontradas no sistema a ser desenvolvido. Na literatura, é comum encontrar 13 itens, cada um com pesos diferentes. Esses pesos são fixos (embora, após muitos e muitos projetos, as empresas acabam ajustando um pouco esses valores - ou mesmo adicionando outros itens). Na prática, para os iniciantes, não mexemos nisso. O que vale, nesse caso, é a relevância do item no projeto.

Por exemplo, o TCF "Easy to Use" (que indica o quão fácil de usar deve ser o sistema final para o usuário) tem um peso padrão de 0.5. Esse valor não é mexido. O que mexemos, é a relevância dele no projeto. Em outras palavras, "no nosso projeto, a facilidade de utilizar o sistema é importante?". À essa resposta (e dos outros itens), damos pesos de 0 a 5. Por exemplo, para meus amigos R. e R. que desenvolvem jogos para celulares, com certeza, esse item tem relevância 5. Para mim, que programo coisas como o Magoo e o Merlin, eu posso colocar uma relvância 3 nesse item. Os trabalhos que mencionei acima tem as tabelas completas dos TCF (e dos ECF, abaixo).

Uma vez somadas as complexidades, a fórmula exige um ajuste do TCF, no formato:

TCF final = 0.6 + (0.01 * TCF)

Isso é importante, para estabilizar a função e termos um ponto de fuga. Os artigos explicam melhor o porquê das coisas. Na prática, o valor 0.6 é uma constante (que pode ser ajustada se a empresa tiver argumentos pra isso) entre 0.6 até 1.30.

Para a continuidade do post, vamos supor que depois de tudo isso, nosso TCF deu 19,5 pontos e, assim, o TCF final é igual a 0.6 + (0.01 * 19,5) = 0,795. Em percentuais, os fatores técnicos reduziram o esforço do projeto em 20,5%!

__
ECF significa Environmental (ou Experience) Complexity Factor, e tem as mesmas regras do TCF, embora, aqui, o objetivo é mensurar quão boa é a equipe, o cliente e o ambiente de trabalho em qu será desenvolvido o projeto. Itens como "experiência com UML", "motivação da equipe" e "requisitos estáveis" são valores ECF. Na literatura, 8 são os ECF padrões. Novamente, adições nesses items e variações em suas complexidades podem ocorrer depois que a empresa tiver expertise na área. Para os novatos (nós), vale a regra da relevância novamente.

Assim, um item como "motivação" para o projeto Merlin (no meu caso), eu colocaria 5 (os valores também são de 0 a 5 aqui). O item "dificuldade de programação" seria (novamente no Merlin) 5, visto que os algoritmos dele são bem malucos :)

Da mesma forma, o ECF precisa de um ajuste, com a fórmula:

ECF final = 1.4 + (-0.03 * ECF)

Se você for bom (e souber o que está fazendo), pode ajustar a constante 1.4 entre os valores 0.425 até 1.4 :)

Para o exemplo continuar, assumimos que o ECF dos 8 itens de ambiente deu 26, logo, o ECF final é 1.4 + (-0.03 * 26) = 0,62. Em outras palavras, os fatores ambientais resultaram na redução de 38% de esforço no projeto!

Observem duas coisas:
  1. Para equipes grandes e/ou dispersas e/ou multidisciplinares, é interessante calcular o valor ECF final para cada integrante da equipe, visto que, cada programador (ou analista, projetista, etc.) pode der uma motivação, um entendimento da linguagem de programação, experiência com o processo de desenvolvimento (...) diferentes. Nesse caso, calcular vários ECF e obter uma média acaba trazendo mais accuracy para método.
  2. Devido os valores das constantes (0.6 e 1.4, respectivamente), observa-se que o ECF (o fator equipe) tem uma taxa de importância maior no sucesso ou fracasso do projeto do que os fatores técnicos (TCF). Assim, muito mais vale ter uma equipe boa do que uma solução tecnológica maravilhosa :)

Após tudo isso (ufa), podemos calcular o UCP, sendo ele igual a 222 * 0.795 * 0.62 = 109 pontos, aproximadamente.

Traduzindo os pontos
De nada adianta um valor 109! Precisamos saber quantas horas de projeto isso dá!

Assim, entra o Fator de Produtividade (PF) da equipe. Para computá-lo, é importante um histórico, pelo menos parcial de projetos. Isso poderia ser feito olhando o último projeto feito pela equipe. Por exemplo, se no último desenvolvimento tivemos um projeto de 2200 horas para 120 UCPs, poderíamos ter, aproximadamente, um PF = 18 (ou seja, 2200/120).

Esse valor, 18, significa que, cada UCP demora 18 horas por pessoa para ser desenvolvida. E não adianta usar a regra do Dilbert (ah, se tem um projeto de 500 horas, vou mandar um mail pros meus amigos no Gmail e convocar 50 pessoas pra trabalhar das 12:00 às 22:00 do sábado e fazer o projeto em 10 horas corridas...).

Para quem não tem um histórico, duas alternativas:
  1. Mapeie cada tipo de Caso de Uso que você espera ter no sistema e fale com a equipe inteira. Pergunte sobre quanto tempo, usando as tecnologias e conhecimento da equipe seria gasto para programar esse caso de uso. Mas atente para o seguinte: o caso de uso envolve todo o ciclo de desenvolvimento, desde a análise, até a homologação (ou mesmo os planos da retirada). Assim, provavelmente você terá que fazer uma planilha para mensurar quanto cada etapa do ciclo consome do caso de uso (requisitos, reuniões, análise, projeto, modelagem, testes unitários, integrados, funcionais, homologação, docuementação, enfim; tudo).
  2. Use o valor FP = 20 (um chute no escuro, mas a literatura sugere isso mesmo para equipes iniciantes)
Juntando tudo, ou, Estimando as Horas do Projeto
Com os valores da UCP e FP, você pode calcular quantas horas deve (note, não é vai!) consumir o projeto:

Estimativa de horas = UCP * FP = 109 * 18 = 1962 horas


Realimentando o Sistema (eu adoro isso)
OK, você estimou. Mas para ter graça a coisa, você deve monitorar o projeto. Não faça ajustes nessa estimativa (ou, pelo menos, mantenha a versão original das coisas). Messa o tempo que o projeto levou e as discrepâncias nas complexidades dos casos de uso, atores e fatores técnicos e ambientais. Assim, você vai afinando a coisa.

Depois do projeto acabado, digamos, ele consumiu somente 990 horas (uhu, você entregou antes do prazo!), você pode calcular um novo FP, ou seja FP = 990 / 109 UCP = 9,08.

Utilize esse FP para os próximos projetos e faça a roda girar!


Para os Apressados (como eu)
Falei, falei e falei. E enfim, como colocar em prática isso? Usem o Enterprise Architect. Ele faz a mão de tudo isso automaticamente :)

terça-feira, dezembro 25, 2007

Nossos filhos, os Casos de Uso

Muitas pessoas falam em Casos de Uso. Alguns dizem que os conhecem e destes, poucos os criam da forma correta. Da parcela menor, certos indivíduos têm idéia de que é possível julgá-los; e o restante que já experimentou algumas abordagens. Entretanto, o fato é que não conheço ninguém que tenha obtido sucesso pleno nessa área.

Os Casos de Uso não são difíceis, embora não sejam simples. Não têm uma característica gritante, nem tão pouco estão amarrados a normas e padrões de estética ou convenções unilaterais. São criaturas puras como um texto plano. E nada mais.

Talvez dessa liberdade excessiva é que as coisas fiquem complicadas e, na melhor das hipóteses, os mais hábeis projetistas acabam subestimando-os e, nos mais valorados projetos, eles são criados, mas não manutenidos.

Casos de Uso são entidades vivas e, como tal, precisam de atenção. A concepção de um Caso de Uso é um momento indescritível. Eles não surgem por autogênese. Seus pais, os usuários e os analistas; seus padrinhos, os arquitetos e programadores; e também seus parteiros, os gerentes e gestores são peças fundamentais neste processo.

Antes de eles se mostrarem para o mundo, seus nomes já devem ser pensados; o ambiente em que viverão deve estar projetado; e seu futuro deve ter sido pormenorizado. Sua evolução, crescimento, dores, e os amigos que terá precisam ser escolhidos para evitar uma desgraça maior. E os professores que o preencherão de informação ao longo de toda a sua existência? Ah sim, estes também devem ser buscados nas melhores escolas. E não apenas no bairro ou cidade, mas no Estado, País ou mesmo muito além-mar.

E eles, um dia, vão ficar adultos, completos, realizados. E depois, poderão ter filhos, dependentes e, sim, também causarão dependências. Chegarão à plenitude e, em algum momento, terão que dar lugar a outros de sua espécie.

Não serão, entretanto, simplesmente esquecidos. Tudo aquilo que fizeram durante sua existência – efêmera ou longínqua – terá deixado rastros. Um rastro que deveria ser guardado na lembrança: imagens, vídeos, frases, relacionamentos (de sucesso ou nem tanto) e as vissitudes poderiam estar numa caixa, ou expostos em um local para todos verem.

Seus entes queridos, poderiam, então aprender com sua existência, até reusando seus pertences ou evitando suas falhas. O mundo seria melhorado.

E então, aos raros que os criam com decência, o sucesso abarcaria.

sexta-feira, dezembro 21, 2007

Abstracting Merlin


A
fter a lot of work, my dissertation about Merlin are done.

In the last 3 years, more than 120 articles in model-based generation area has been read. Seventeen frameworks and tools was studied, and a panaceia of information is overturning in my mind. But at this time, I finished. And, I am very happy.

I'm happy because I think that Merlin is a revolution in IU generation. Taking advantages of a many standards, and allowing abstract and concrete mixings of specification, plugglabe algorithms can be merged to produce IU in agnostic way. Both web and desktop applications can be generated with a single approach.

Using Java and a Domain-Driven Design (DDD) with an exclusive implementation of the Eiffel Agents, the historical system can reduce the configuration effort at each new generation.

Now, I'm will be return to 3Layer Tecnologia and ours projects: GED, DTOptmizer, Magoo, Merlin, Melvin, Mentor and Jestor.

Finally, in a few words, the following text summarising the research produced:


Merlin

This work describes a proposal for the automatic and aided generation of CRUD interfaces, that are commonly in used databases systems. Using a model-based approach, the main differences of this research in relation to the existing solutions are the use of an self-contained structure for its models and the use of the a runtime generation process, preventing a source-code production.
Although researchs demonstrates that automatic generation of user interfaces represents a promising cenario, at this moment, the available solutions are not good for professional teams. Proprietary languages and sintaxes, and a largest effort in tool configuration are the mainly problems in this area.
To resolve these difficulties, this work proposes an intensive use of heuristics and an exclusive mechanism based on historical values over a self-contained models. Using this premisse, the reuse are increased and the configuration amount are minimized. Moreover, using Java language and other standards, the solution can be used daily without big complications.

Finish him!

Desculpem, mas tenho que postar isso:

FINISH , FINISH , FINISH, FINISH, FINISH , FINISH, FINISH, FINISH, FINISH , FINISH, FINISH , FINISH, FINISH , FINISH, FINISH, FINISH , FINISH, FINISH, FINISH, FINISH, FINISH, FINISH , FINISH, FINISH, FINISH, FINISH, FINISH, FINISH, FINISH , FINISH, FINISH, FINISH , FINISH, FINISH, FINISH, FINISH , FINISH, FINISH , FINISH , FINISH, FINISH , FINISH, FINISH, FINISH, FINISH , FINISH, FINISH, FINISH, FINISH, FINISH, FINISH, FINISH, FINISH, FINISH, FINISH , FINISH, FINISH, FINISH, FINISH, FINISH, FINISH , FINISH, FINISH , FINISH, FINISH , FINISH, FINISH, FINISH, FINISH, FINISH, FINISH, FINISH , FINISH, FINISH , FINISH, FINISH, FINISH, FINISH, FINISH, FINISH , FINISH , FINISH, FINISH , FINISH , FINISH, FINISH, FINISH, FINISH, FINISH, FINISH, FINISH , FINISH, FINISH , FINISH, FINISH , FINISH, FINISH, FINISH, FINISH, FINISH, FINISH.

quinta-feira, dezembro 13, 2007

4 - O Projeto Merlin - parte 1

Então, para os que estavam esperando...o core do negócio.

4 O Projeto Merlin

Neste capítulo

· O histórico e os objetivos do projeto
· As características e a arquitetura da solução proposta
· O projeto de software da ferramenta

4.1 METAGEN, o início

No ano de 2001, alguns integrantes do Setor de Informática da Universidade de Santa Cruz do Sul (UNISC) estavam empolgados com as possibilidades que surgiam a partir de um projeto interno denominado METAGEN (MRACK e MOREIRA, 2003).

Utilizando uma abordagem bastante simplista, o pequeno protótipo desenvolvido em Visual Basic – que posteriormente fora portado para Delphi/Kylix – era um gerador baseado em modelos capaz de automatizar completamente a construção de IU para sistemas de banco de dados. A partir de um esquema de banco de dados qualquer enriquecido com informações textuais especificamente projetadas para a ferramenta, algoritmos especializados renderizavam em tempo de execução as IU do sistema.

Essa abordagem, embora rudimentar, era extremamente rápida e eficaz, possibilitando a produção de interfaces funcionais tão logo um esquema de banco de dados estivesse disponível. Conforme testes realizados na época, aproximadamente 70% das IU de cadastro de um sistema podiam ser integralmente automatizadas com o uso da solução. Em relação ao tempo de desenvolvimento, os ganhos oscilavam em 40%, uma boa margem para um projeto de segundo plano dentro de um setor lateral em uma Universidade privada (MRACK e MOREIRA).

Entretanto, mesmo com protótipos de sucesso desenvolvidos, a falta de afinidade das atividades do projeto em relação às demandas primárias da equipe e a escassez de subsídios para continuidade das pesquisas acabaram inibindo as forças necessárias para prosseguimento do projeto.

Convictos que as idéias surgidas nesse ínterim eram válidas, parte da equipe decidiu engendrar uma nova caminhada, levando os ensinamentos aprendidos para uma iniciativa pessoal, agora conhecida pelo codinome Merlin (MRACK, MOREIRA e PIMENTA, 2006).

4.1 O projeto MERLIN

O projeto MERLIN, em alusão ao lendário mágico da Idade Média, é um gerador baseado em modelos com ênfase em interfaces CRUD, também conhecidas no jargão dos programadores como telas de cadastro. Essa prerrogativa está em concordância com as bases oriundas do projeto METAGEN, as quais incluem: (i) a geração das telas em tempo de execução; (ii) a configuração norteada pela edição textual assistida dos modelos; (iii) uma base construída em padrões e linguagens de mercado; (iv) o reuso transparente e gerenciado de configurações e (v) a modelagem centrada no Modelo de Domínio da aplicação.

O posicionamento desses ideais é baseado em um histórico profissional ao longo de vários anos de construção de software para banco de dados, o qual evidenciou quatro pontos-chave:

a) que a grande maioria dos programadores não está preparado para utilizar ferramentas complexas ou baseadas em linguagens abstratas, como as propostas pelas MBUIDEs existentes;
b) que as empresas não estão dispostas a pagar os custos para a adoção de uma ferramenta desse tipo em seu ambiente e tão pouco interessadas em mudar seu processo de desenvolvimento em virtude dessa prática;
c) que qualquer tipo de geração de código-fonte, por mais parametrizada que seja, acaba produzindo um legado de difícil manutenção e taxas de roundtrip cada vez menores ao longo da evolução do sistema;
d) que independente do tipo de sistema desenvolvido, o Modelo de Domínio está sempre presente e, devido sua íntima relação com as interfaces CRUD do sistema (ALOIA, 2003) e (PIZANO, SHIROTA e IIZAWA, 1993), ele pode ser considerado o elemento-chave em qualquer processo de desenvolvimento, seja este automatizado ou não.

Este trabalho e, em específico esse capítulo, visa detalhar os princípios do projeto MERLIN e mostrar como ele pode ser utilizada para produzir interfaces de usuário funcionais e robustas, que podem ser utilizadas em sistemas reais sem maiores dificuldades.

As próximas seções descrevem as principais características da solução e mostram a sua arquitetura geral enquadrada dentro de um processo de desenvolvimento genérico.

quinta-feira, dezembro 06, 2007

Capítulo 3 - Geração de IU Baseada em Modelos - parte final

Descontando a tabela comparativa, de devo colocar em um segundo momento, essa é a seção que finaliza o Capítulo 3, sobre as MBUIDEs.

3.4
Visão geral sobre as soluções MBUIDEs

Considerando os trabalhos analisados e as soluções oferecidas, verifica-se que um grande avanço ocorreu desde as primeiras UIMSs. As soluções de geração baseada em modelos cresceram, e suas capacidades de geração e abrangência aumentaram significativamente. Através de seus variados modelos, as mais importantes facetas de um sistema podem ser documentadas, estruturadas e validadadas em níveis mais abstratos, o que é positivo para os desenvolvedores em geral. Utilizando algoritmos internos configuráveis em conjunto com diversas regras de transformação, as capacidades de geração das MBUIDEs se estendem muito além da geração de simples IUs, alcançando, muitas vezes, grandes porções de um sistema completo.

Entretanto, mesmo com esse progresso, observa-se que as soluções MBUIDEs parecem ter alcançado um ápice em meados da década de 1990, e que atualmente as equipes de desenvolvimento acabam optando por ferramentas mais simplistas, como editores WYSIWYG, utilitários de geração baseados em templates ou mesmo produtos caseiros (PUERTA e EISENSTEIN, 1999), (MRACK e MOREIRA, 2003). Causas desse distanciamento do cenário profissional são bem comentadas em vários trabalhos (PUERTA et al, 1999), (GRAY et al., 1998), (GRIFFITHS et al., 1997), (PINHEIRO, 2001) e tangem, principalmente, a fatores como a falta de reuso de padrões de mercado, a excessiva quantidade de configurações sobre muitos e diferentes modelos, a exigência de processos de desenvolvimento exclusivos e limitações frente ao roundrip de desenvolvimento. De fato, como exposto por alguns autores (SCHLUNGBAUM, 1997), (MYERS, 1994), as MBUIDEs existentes parecem servir mais como protótipos para testes de novas tecnologias, ou como experimentos de nível ainda acadêmico.

De forma geral, observa-se que as MBUIDEs podem apresentar soluções elegantes para o desenvolvimento de aplicações. Entretanto, para que se tornem opções de primeira linha, a minimização dos esforços para construção e configuração de seus modelos, o reuso de padrões de mercado e a integração com processos já existentes de análise, projeto e implementação são fatores cruciais.

Legal, tem gente que pensa como eu

Todos que me conhecem, sabem que não gosto de produtos Oracle. E, independente de serem bons ou ruins (sou partidário dessa opção), gosto é gosto, e não se discute.

De todos os produtos que já vi falar (e pessoas usando), o Oracle Designer é o mais afamado. E mal falado.

Sua interface é rudimentar, tem vários bugs e a ferramenta não tem inteligência nenhuma. Em outras palavras, para fazer qualquer coisa nela é preciso navegar em inúmeras telas feias, toscas nada funcionais. Pois bem, isso é o que penso.

Mas hoje fiquei contente ao ver no MSN que um colega meu também não pensa muito diferente.

Fica aqui o registro para a posteridade.



terça-feira, dezembro 04, 2007

Eu gostei: Colored Labels no Gmail

Quem acompanha o grupo do gmail já estava aguardando há tempos essa nova feature do brancão. Enfim, chegou.

A utilização de cores nos famigerados labels do Gmail é uma mão na roda. E isso sem contar que aplicação fica mais....hum...colorida :)


O affordance visual melhora e podemos fazer ligações entre mensagens de forma mais rápida, isso porque cores não precisam ser "lidas" pelo cérebro. Em outras palavras, fica mais fácil achar o que queremos, mesmo sem usar o (ótimo) find do programa.

Para os mais ranzinzas (como eu), o gmail está precisando uma refatoração visual sim, como a adição de sombras (uma tendência em aplicações) e mais opções de fontes e estilos. Obviamente, o branquelo está trabalhando nisso e, acho que ainda nesse ano que entra, teremos mais novidades.

Ah, para os menos "ligados", a dica do atalho de "remove label" (circulado em verde, abaixo) é uma boa pedida.


domingo, dezembro 02, 2007

Decepcionado? Na verdade, não.

Ontem estive na UFRGS mostrando o Merlin no evento do TcheLinux. O evento, que é voltado para a comunidade de amantes do Software Livre, foi mais uma oportunidade de divulgar o que a 3Layer anda fazendo em seus laboratórios.

O evento, ao todo, devia ter umas 150 pessoas. Pequeno, e voltado bem para os CDFs e malucos da área (todos que conhecem o pessoal do Software Livre sabem que essa é uma comunidade bem estilizada. Yes, também faço parte dela :) ).

Pois bem, o J. estava me acompanho até a palestra e, de antemão, eu já comentava que iriámos encontrar umas 5 pessoas como ouvintes para o nosso framework.

E porquê? Por vários motivos: pelo horário (sábado à tarde, verão, lugar distante, etc.); pelo ambiente (os que conhecem as salas da UFRGS sabem que elas não são nada aconchegantes); pelo público-alvo (pessoas ligadas ao software livre em geral, e não desenvolvedores de ferramentas e players da área em geral) e pela existência de outra palestra bem legal no mesmo horário (sobre Ruby On Rails).

Mas o quórum não era maior, não por esses motivos, mas sim pelo que eu tenho em mente há muito tempo: ninguém se interessa em coisas no início ainda.

A comunidade em geral espera que o boom ocorra, que revistas publiquem, que as empresas usem, que (...), enfim, uma pedrada acerte a testa até que a "ficha caia".

Em outras palavras, é mais ou menos o que eu falo em meus "blogs negros". Não que as pessoas estejam erradas, mas a cultura aqui é que niguém se esforça para empreender coisas em estágio embrionário.

Para dar um exemplo, meu colega D. P. é um commiter do Hibernate. Nem eu sabia disso. Mas quando fiquei sabendo, dei sinceros parabéns para o cara. Perguntei para ele quantos desenvolvedores mais tinham aqui no Sul ajudando na coisa... Ele riu e respondeu que era o único brazuca na parada.

Ilário, né? Empresas dão cursos na área, cobram caríssimo e ganham muito dinheiro sobre produtos abertos, que muita gente ajuda sem ganhar dinheiro algum em troca (pelo menos não diretamente) e tudo isso, ao mesmo tempo que ninguém se interessa em prestigiar esforços tão pertinho.

A palestra do Ruby não tava cheia.; os caras que estavam na minha eram programadores iniciantes e o J. fora o único que prestara real interesse no assunto (e vejam bem, ele vivencia diariamente a experiência sobre o assunto).

Mas eu estou decepcionado? Não, sinceramente, não estou.

Na verdade, me pego rindo com isso. E fico muito feliz, até. E por quê? Porque lembro do Gosling infurnado (minha mãe usava muito essa palavra - nem sei se ela existe) num cantinho da Sun mexendo com linguagens formais e novas estratégicas para compiladores...um assunto que, idem, não interessava ninguém além dele mesmo e seus amigos do "projetinho" Green, hoje Java.

Não almejo comparações (quem dera), mas o fato é que, se tudo (ou pelo menos boa parte dos planos derem) certo, quero olhar esse post e usá-lo como conteúdo para uma nova palestra que, bem, espero não contar os participantes nos dedos de uma mão.

Ah, sim, fora o J., três estavam presentes.

sábado, dezembro 01, 2007

Capitulo 3 - Geracao de IU Baseada em Modelos - parte 2

Não está bom como eu queria, mas como o tempo urge, lá vai a segunda parte do Capítulo 3, que trata dos modelos existentes em uma MBIDE (ou MBUIDE, como diria (PINHEIRO, 2oo1)).

Os Tipos de Modelos

Como elementos centrais nas ferramentas MBIDEs estão seus modelos de armazenamento e configuração, os quais variam em conteúdo e objetivos. Análises diversas (PINHEIRO, 2001), (SZEKELY, 1996) e (SCHULUNGBAUM, 1996) afirmam que as MBIDEs podem ser classificadas cronológica e arquiteturalmente conforme o conjunto de modelos suportados.

De fato, é a partir dos modelos que as ferramentas definem suas formas de trabalho e, consequentemente, o processo de software a ser aplicado quando da sua utilização (BODART, LEHEUREUX e VANDERDONCKT, 1994). Partindo dessa afirmativa, uma análise sobre esses artefatos é de grande importância para esse trabalho. Assim, as próximas seções descrevem, em alto nível, os nove tipos de modelos consensualmente aceitos na área das ferramentas de geração baseada em modelos.

A) Modelo de Dados

Modelos de Dados é a base para geração de interfaces CRUD, pois tem um mapeamento quase direto entre um elemento de dado (um atributo em uma tabela, por exemplo) e um controle de tela (uma caixa de texto, por exemplo) e são bastante utilizados pelas ferramentas MBIDEs de primeira geração (SZEKELY, 1996).

Sob uma ótica simples, esse modelo pode ser interpretado como um subconjuto do Modelo de Domínio, e pode ser comparado a um típico modelo Entidade-Relacionamento, pois dentro dele estão contidas todas informações sobre os dados que podem ser manipulados pelo sistema.

Obrigatoriedade, valores-padrão, intervalos mínimos e máximos, tipo de dado e outras informações tipicamente presentes nesse modelo são utilizadas pela grande maioria das MBIDEs para produzir, com a ajuda de algumas heurísticas e algoritmos simplistas, as interfaces responsáveis pela visualização e edição da estrutura de dados relacionada (PUERTA et al., 1996).

FIGURA DE UM DIAGRAMA UML COM 3 CLASSES RELACIONADAS E UMA IU CRUD RUDIMENTAR GERADA EM FUNCAO DELE

Observa-se na Figura 3.1 que os descritivos dos controles foram produzidos a partir do próprio nome do atributo da classe, e que os tipos dos controles foram definidos em função do tipo de dado do atributo.

Como regra geral, as MBIDEs mapeiam uma tabela ou classe para uma ou várias interfaces CRUD, sendo que cada atributo (da classe ou tabela) é mapeado para um controle de tela (PINHEIRO, 2001) (MRACK e MOREIRA, 2003).

B) Modelo de Domínio

O Modelo de Domínio é o elemento central das ferramentas MBIDEs, servindo como base para geração da IU. A partir dele são extraídas várias informações que, através de heurísticas e algoritmos diversos, podem ser derivadas nos elementos que compõem os formulários da aplicação.

Este modelo excede o Modelo de Dados por conter também as informações comportamentais do sistema. De certa forma, ele pode ser interpretado como um Diagrama de Classes da UML, suportando diversos tipos de relacionamentos entre as estruturas (como herança, agregação, composição), bem como tipos de dados definidos pelo usuário e também conceitos de mais alto nível, como classes abstratas, finais, interfaces e enumerações (OMG).

Porém, o que mais distingue esse modelo do Modelo de Dados é a presença de operações, ou métodos de classes. Dessa forma, um Modelo de Domínio pode representar não somente a estrutura de uma IU, mas também o seu comportamento. Projetos como o MECANO (PUERTA et al., 1996), MERLIN (MRACK, 2005) são apenas alguns exemplos de soluções que centralizam todo o desenvolvimento do sistema sobre esse modelo.

Conforme a análise de (PINHEIRO, 2001) e (SZEKELY, 1996), os Modelos de Domínio vieram para substituir os Modelos de Dados e são vistos como elementos essenciais nas MBIDEs mais atuais.

C) Modelo de Tarefa

Este modelo pode ser interpretado como uma grande árvore composta de tarefas e sub-tarefas, onde cada uma representa uma atividade que o usuário pode executar no sistema. Como não existe um padrão para descrever esses modelos, cada ferramenta que adota-o, o faz com base em um estilo próprio .

Entre as informações contidas nesse modelo, estão a ordem de execução das tarefas, as pré e pós-condições, questões sobre paralelismo, dependências, obrigatoriedade e outras (GRAY et al., 1998). No tocante à vinculação dessas tarefas aos elementos de tela, algumas soluções fazem-o diretamente nesse modelo, outras optam por fazer isso no Modelo de Diálogo.

Muitas dúvidas pairam sobre esse modelo, uma vez que, dependendo da ferramenta, as tarefas podem ser interpretadas de forma abstrata, concreta (métodos em uma classe, por exemplo) ou mesmo com o uso de formalismos (BARON e GIRARD, 2002). Uma das MBIDEs que mais coloca ênfase sobre esse modelo é a TRIDENT (BODART, LEHEUREUX e VANDERDONCKT, 1994), tomando-o como ponto de referência não só para a definição dos outros modelos do sistema, mas também para a modelagem de toda a aplicação.

A Figura 3.2 mostra a representação gráfica de um modelo de tarefas derivado do projeto TRIDENT, no qual as tarefas são descritas através de um modelo formal (SOUCHON, LIMBOURG e VANDERDONCK, 2002)

FIGURA COM UMA ARVORE DE TAREFAS, NA QUAL CADA VÉRTICE É UMA TAREFA ESPECIFICADA EM ALTO NIVEL, E CADA ARESTA É UMA DEPENDENCIA, AS QUAIS POSSUEM ORDENAMENTO, CONDICOES DE NAVEGACAO, OPERACAO PARALELA, EXCECOES, ETC.

Figura 3.2: Visualização gráfica de um modelo de tarefas derivado do projeto TRIDENT (SOUCHON, LIMBOURG e VANDERDONCK, 2002).

D) Modelo de Usuário

Este modelo não tem uma descrição ou comportamento exatos. De fato, muitas ferramentas simplesmente o ignoram, e a abordagem utilizada por elas para satisfazer esse componente é dispersar suas características em outros modelos.

Na prática, o objetivo desse componente é armazenar informações características de um usuário ou perfil específico da aplicação em relação às configurações gerais da ferramenta. Em outras palavras, é nesse modelo que devem ficar armazenados comportamentos e especializações de tela, como teclas de atalho personalizadas, valores-padrão para controles de tela baseados em perfil do usuário, informações referentes à controle de acesso e outras (SCHLUNGBAUM, 1997).

A maioria das ferramentas existentes não explicita em detalhes o funcionamento desse elemento, mas, de modo geral, são capazes de satisfazê-lo em determinado nível à sua maneira (PINHEIRO, 2001).

E) Modelo de Diálogo

Também conhecido como Modelo de Conversação (RRR), define como os objetos da IU devem interagir com o usuário. Ele representa as ações que o usuário pode invocar através dos elementos da camada de apresentação e as respostas que a aplicação deve produzir através desses mesmos elementos.

De forma geral, ele está muito ligado ao Modelo de Apresentação e ao Modelo de Tarefas, sendo que, muitas vezes, confunde-se com esses. Essa afirmativa pode ser tanto apreciada em (PINHEIRO, 2001), que simplesmente une-os em seu ensaio comparativo de ferramentas da área, como em (SCHULUNGBAUM, 1996), que descreve o aparecimento desse modelo como sendo uma evolução arquitetural das modernas MBIDEs.

F) Modelo de Apresentação

Após o Modelo de Domínio, o Modelo de Apresentação pode ser considerado o segundo modelo mais importante em uma ferramenta MBIDE. É nele que ficam armazenadas as informações referentes à aparência da tela (PUERTA e EISENSTEIN, 1999). Características dos elementos de tela como layout de controles, posicionamento, tamanho, regras para redimensionamento, esquema de cores, ordem de tabulação e outras são centralizadas nesse componente.

Devido à sua acentuada dependência em relação ao toolkit gráfico utilizado pelo sistema, as ferramentas MBIDE encontram nesse item um separador de águas em relação à sua arquitetura interna. Isso ocorre porque elas precisam considerar duas abordagens diferentes para estruturar esse modelo:

· Abstract Interface Objects (AIO): Ferramentas que utilizam informações abstratas para descrever o modelo de apresentação simplesmente ignoram o toolkit gráfico para configuração desse componente. Assim, é eleito um conjunto de configurações que podem estar presentes nos toolktis gráficos suportados pelo gerador de forma que, em um segundo instante, na geração da IU, as informações abstratas são mapeadas pelo gerador para o toolkit gráfico escolhido. Na eventualidade de uma informação existente no AIO não estar presente no toolkit gráfico escolhido, uma perda de qualidade no resultado é esperada (BODART, LEHEUREUX e VANDERDONCKT, 1994).

· Concrete Interface Objects (CIO): Soluções que usam essa abordagem definem o modelo de apresentação utilizando as primitivas do próprio toolkit gráfico a ser utilizado na geração da IU.

É interessante notar que alguns trabalhos advogam que é possível operar ambos os modelos ao mesmo tempo, de forma que, em um processo evolutivo, AIOs são paulatinamente transformados em CIOs. A justificativa para issso é que somente através dos CIOs é possível especificar os detalhes necessários para a geração de uma IU mais elaborada. Na Figura 3.3 pode ser vista uma comparação entre AIOs e CIOs em duas ferramentas MBIDEs:

FIGURA COMPARATIVA, MOSTRANDO AIOS NA FERRAMENTA TRIDENT E AIOS E CIOS NO MERLIN (PRA TER UMA IDEIA, IMAGINE UM CODIGO JAVA COM ANOTACOES - EH EXATAMENTE ISSO QUE O MERLIN USA PARA DEFINIR SEUS AIOS E CIOS)

Figura 3.3 : Fragmentos de modelos de apresentação nas ferramentas TRIDENT (BODART, LEHEUREUX e VANDERDONCKT, 1994) e MERLIN (MRACK, 2007).

Nessa figura, observa-se que um AIO não especifica nenhum detalhe relevante para o toolkit gráfico – é tarefa do gerador interpretar essas informações e traduzí-las no CIO correspondente. Na parte direita da figura, AIOs e CIOs estão misturados entre si sobre o próprio Modelo de Domínio.

De importante interesse, porém, pode ser a abordagem oferecida pela ferramenta MOBI-D (PUERTA e EISENSTEIN, 1999), a qual explicita um mecanismo configurável e relativamente avançado para mapeamento entre AIOs e CIOs. Tal ênfase é tão grande, que os autores sugerem um novo tipo de modelo, o chamado Modelo de Projeto. Entretanto, uma vez que somente este trabalho referencia tal componente, ele não é considerado um elemento ao mesmo nível dos outros modelos existentes.

G) Modelo de Aplicação

Este modelo pode ser interpretado como o superconjunto do Modelo de Domínio, pois contém informações que vão além daquelas existentes naquele componente. De forma geral, um Modelo de Aplicação descreve as características mais gerais do sistema, e não simplesmente aquelas referentes ao problema a ser tratado.

São exemplos de informações contidas nesse modelo as classes auxiliares de suporte à aplicação, dados de configuração do sistema e parâmetros como conexões à banco de dados, serviços remotos e outros.

Quanto à formação, detalhamento e fronteiras desse componente, os trabalhos não explícitos, sendo que muitos simplesmente ignoram-o (PINHEIRO, 2001).

H) Modelo de Plataforma

Da mesma forma que o Modelo de Aplicação, não existe um consenso sobre esse modelo. Algumas ferramentas simplesmente descartam-no (PUERTA et al., 1996) e outras fundem-no com o Modelo de Aplicação (LUYTEN, 2004) sem maiores preciosismos.

O objetivo desse modelo é descrever os detalhamentos necessários da aplicação perante o ambiente em que ela está sendo executada. Informações como o toolkit gráfico e o banco de dados a ser utilizado pelo sistema são descritos nesse componente. Embora ele seja de suma importância para a completude de uma MBIDE, a existência explícita desse componente não é justificável, uma vez que cada ferramenta pode escolher a melhor forma de implementá-lo sem demasiados prejuízos para o cenário de desenvolvimento.

I) Modelo de Contexto

De forma geral, esse artefato não é considerado um modelo no sentido exato da palavra pois, com exceção à (LUYTEN, 2004), nenhum dos trabalhos estudados faz menção explícita a esse tipo de componente.

Um Modelo de Contexto descreve os aspectos de uma aplicação que não podem ser conhecidos durante sua construção, pois dependem da interação do usuário para sua formação. Entre as informações que podem ser residir nesse modelo estão dados comportamentais do usuário, como preferências na execução de comandos (se por teclas de atalho ou chamadas de menus, por exemplo), ordem de preenchimento de campos na tela, utilização ou não de valores-padrão existentes nos controles da IU e outros.

Grosso modo, esse é um modelo que somente pode ser obtido ao longo do uso do sistema, não sendo possível sua concepção durante a fase de projeto da aplicação. Em certos aspectos pode se confundir com o Modelo de Usuário, embora se diferencie desse por ser algo mais dinâmico.