[Cascavel-pm] Re: UML+Design Paterns+Modelagem

[Graciliano M. P.]

> > Quanto ao UML, só tem sentido se vc quiser utiliza-lo para geração
> > automática de código, mas isto funciona mais com Java e olhe lá! Eu
gosto de
> > usar UML na parte de modelagem conceitual, mais para organizar td e ter
uma
> > visão melhor do problema. Na parte de projeto (programação) também é bom
> > utilizar UML para organizar cada ciclo, mas será útil mesmo se vc tiver
uma
> > equipe trabalhando no mesmo problema, e não uma única pessoa.
>
> Oras, por que esse preconceito? Tenho certeza de que documentação
> bem-feita e com ajuda do UML pode aumentar e muito o rendimento da
> construção de projetos de sistemas de computador...

Não estou dizendo que não aumenta o rendimento, mas UML apenas pela UML é um
erro, como qualquer outro recurso. É q é muito comum ver isto!

> > Agora quanto a Web, não sei se tem muita coisa boa, pois UP é algo bem
> > extenso e que exitem várias abordagens e focos sobre o mesmo. Agora
quanto
> > aplicar tais recursos na Web é complicado, principalmente falando-se em
OO,
> > pois OO para Web é algo que não funciona muito bem, pois grande parde
dos
> > sistemas para Web ainda usam muita coisa estruturada, e a única coisa de
OO
> > que eles usam são aguns módulos para algumas tarefas específicas, ou
seja,
> > não se utiliza OO para desenvolver o sistema em si.
>
> Desculpe, mas sou obrigado a discordar. Eu não tenho nenhuma linha de
> código estruturado em meus websites, apenas código OO. E funciona muito
> bem, obrigado. (:

Tem certeza que não é estruturado? Vc pode fazer um sistema a la estruturado
até em Java, e na verdade já cansei de ver isto em JSP.

> Para começar, eu criei uma hierarquia de objetos para representar
> coisas interessantes para o meu projeto: Conexões com banco de dados,
> objetos de configuração e de conservação de estado. Em seguida, agreguei
> todos estes objetos em um Framework de duas camadas, capaz de lidar
> praticamente sozinho com as requisições HTTP e chamar os métodos
> corretos para cada situação. Deste ponto em diante, implementar novas
> funcionalidades passa a ser apenas questão de extender o Framework,
> implementar métodos para manipular cada evento desejado, agregar
> Templates (eu uso o Template Toolkit, do Andy Wardley) e publicar o CGI
> na web, que acaba simples como
>
> #!/usr/bin/perl
> use warnings;
> use strict;
> use Framework::Module;
> ( new Framework::Module )->run();
> __END__
>
> > Na verdade o problema da Web com OO para sistemas, é que cada execução
de
> > página/tela está em um processo diferente, e pode estar em máquinas
> > diferentes tb, mas o objeto responsável por tal parte do sistema, e que
> > interage com o usuário, tem que funcionar como se estivece em um
programa
> > normal, desktop. Ou seja, muita coisa está escrita para desenvolver
> > softwares desktop, e não para Web.
>
> Isso não é importante. Aliás, quanto menos sua aplicação souber sober
> o ambiente em que ela está rodando, mais simples se torna o
> desenvolvimento.

Estas completamente certo, o sistema nunca deve saber sobre o ambiente, mas
como os conceitos básico de estado de objetos na Web não podem ser mantidos,
muita coisa escrita para Softwares Desktop não pode ser utilizada,
simplesmente pq o Desgin Pattern não deve saber sobre o ambiente externo. Na
verdade explicaste para vc mesmo o pq.

>
> Eu implementei gerenciamento de sessões utilizando os módulos
> CGI::Session (puro OO) e CGI (suporte a OO se você quiser). Depois,
> implementei acesso a banco de dados usando DBI/DBD, e acesso a
> configuração via Config::Simple. Mas posso facilmente trocar
> Config::Simple por XML::Config, e isso me abre a possibilidade de
> distribuir a configuração do sistema (e todo o resto) usando banco dados
> (para os dados da aplicação) e HTTP (para os XML's de configuração).
>
> Desta forma, o mesmo framework que eu concebi inicialmente pode ser
> extendido para um ambiente distribuído, statefull, seguro, paralelo,
> multiprocessado e com suporte a processos concorrentes, sem mudar sequer
> uma linha de programação da aplicação.
>
> Com isso, quero mostrar que as dificuldades de programar sistemas
> para a Web está muito mais relacionada com a abortagem adotada do que
> com a tecnologia ou as limitações existentes.

Como eu falei, utiliza-se muito OO para Web nos recursos que o sistema
utiliza (seções, persistência, DB, XML, etc...), mas não no sistema em si.
Por exemplo, em uma locadora de vídeo, o ideal é ter um objeto que
represente cada fita de vídeo, formando uma coleção de fitas. Para cada fita
podemos ter uma classe de especialização, com preço, tipo, etc... Ou seja, o
sistema é a representação do problema, e não da tecnologia, e a idéia básica
do UP é exatamente esta! Quanto a tecnologia utilizada para DB,
persistência, etc... não é nem discutida, pois isto td faz parte do
FrameWork, e muita coisa já está pronta e em uma camada que o desenvolvedor
nem toca.

> > Digo isto sobre a Web pois a área de pesquisa que atuo é extamente esta,
> > aplicar de forma mais eficiente os Design Patterns e a modelagem OO em
> > sistemas Web. Onde também estou desenvolvendo um FrameWork para WebGUI,
ou
> > seja, a idéia é fazer um sistema de um portal sem escrever nada de HTML,
e
> > apenas componentes, como os componentes gráficos utilizados em um Delphi
da
> > vida.
>
> Puxa!!! A parte de desenvolver componentes é muito interessante...
> mas isso vai deixar toda a web mais ou menos com a mesma 'cara', não?
> Como você pretende se livrar das "amarras" de look'n'feel impostas pela
> componentização? Ou você não está preocupado com isso, e é um detalhe
> sem importância a esta altura do campeonato?

Os componentes têm a camada de domínio (responsável pelas informações que o
componente irá tratar) e a camada de interface, separada em camada de
apresentação (estilos, design, etc...) e de aplicação (controle do
comportamento). Vc está falando da camanda de apresentação, e a idéia é
tornar cada componente o mais personalizável possível, só que a idéia tb é
facilitar a criação de componentes, pois o FrameWork é exatamente para
facilitar a criação, já que a idéia é o desenvolvedor fazer td em
componentes, que ele mesmo pode criar, e nos sistemas futuros reaproveitar
100% dos componentes anteriores. Ou seja, vc terá os componetes básicos
(table, button, etc..), e os componentes complexos (pool, menu, banner,
etc...), e os componentes do desenvolvedor.

Por traz disto tb estava pensando, no futuro, criar um CPAN de
componentes... ;-P

>
> > Por exemplo, uma enquete (Pool en inglês) seria declarada desta maneira:
> >
> > <webgui::pool title="Qual a sua cor?" bgcolor="#CCCCCC"
> > button_color="#000000" style="pool-style.xml">
> > <option value="0">Red</option>
> > <option value="1">Blue</option>
> > </webgui::pool>
>
> Parece muito com XML, de um tipo (com atributos) que eu não gosto
> muito... (: Mas é promissor...

É XML, e tem q ser XML, pois não vou criar mais um padrão por ai para ser
aprendido! ;-P
Mas na verdade é um Wild XML, ou seja, vc não é obrigado a colocar aspas,
etc... pois este é um XML para ser declarado a mão.

Na verdade esta declaração é uma substituição da chamada por código (também
permitida):

  my $pool = webgui::pool->new(
  title => '...' ,
  bgcolor => '...' ,
  options => [
  0 , 'red' ,
  1 , 'blue' ,
  ] ,
  );

  print $pool->print ;

> > E o FrameWork detecta automaticamente os tags de webgui e converter para
> > código. Bom, isso ai é só para dar um gostinho do que vem por ai! ;-P
>
> Obaaaa!! Será que você precisa de um "beta-tester"?

Provavelmente o projeto vai estar na Web na faze de testes, aí eu faço um
anunciamento para tds.

> Obrigado pela "Aula"!
> (:
> Boa sorte com seu projeto!!

Boa sorte tb,
Graciliano M. P.