[quote=luistiagos]
UML não é linguagem de programação… é linguagem de modelagem… [/quote]
Você esta falando de linguagem de programação, ok UML não é necessáriamente um linguagem de programação, mas nada impede que eu invente um compilador que leia UML ou qualquer outra linguagem visual e gere um .exe ou um bytecode (ou interprete o mesmo).
[quote=victorwss]
Ou seja, não há geração de código-fonte em lugar algum. Apenas o “bytecode executável” é gerado direto dos fluxogramas.[/quote]
http://www.softwell.com.br/PaginaAction?pagina=recursos
Ver ABSTRAÇÃO DE LINGUAGENS.
e
http://www.softwell.com.br/PaginaAction?pagina=duvidas
Ver item 5.
dai vc estara fazendo um software… existe diversos software que geram codigo atravez do UML…
[quote=luistiagos]
dai vc estara fazendo um software… existe diversos software que geram codigo atravez do UML… [/quote]
Mas um compilador é um software ué. Normalmente transforma texto (código) em binário. Nada me impede de fazer um compilador que pegue o modelo e transforme em binário. Só muda a forma de representar.
[quote=Rubem Azenha][quote=victorwss]
Ou seja, não há geração de código-fonte em lugar algum. Apenas o “bytecode executável” é gerado direto dos fluxogramas.[/quote]
http://www.softwell.com.br/PaginaAction?pagina=recursos
Ver ABSTRAÇÃO DE LINGUAGENS.
e
http://www.softwell.com.br/PaginaAction?pagina=duvidas
Ver item 5.[/quote]
Isso daí é o que ele faz ao EXPORTAR o código. O que acontece é que o maker nativo está na linguagem nativa do maker. Se você quiser pode deixá-lo na linguagem nativa para sempre e ele rodará lá.
Mas, implementaram o recurso de EXPORTAR para outra linguagem (inicialmente java, agora outras também). Basicamente, alguma ferramenta (daí sim, aqui é um gerador de código) TRADUZ os fluxogramas para uma outra linguagem de programação. Mas, você não é obrigado a usar esse recurso em lugar algum, só usa se quiser. O maker só roda por si quando o webrun lê o fluxograma nativo. Depois que o maker exporta o código, ele simplesmente o esquece.
Enfim, isso ocorre porque TRADUZIR fluxograma para alguma linguagem de programação qualquer é relativamente simples. Já o inverso é quase impossível.
Isso é jogada de marketing. Como NÃO HÁ CÓDIGO não tem porque eles falarem de qualidade de código aqui. E esse negócio de que pode-se documentar porque sobra tempo, nem é preciso dizer que é conversa para boi dormir.
mas um modelo grafico tem uma abstração muito grande… pode-se ter sim algo que pegue desenhos e transforme em binario porem não é o que o maker faz pelo que esta escrito no item 5 que vc disse… e no meu ver é algo muito mais trabalhoso de se fazer… expremente pegar uma lingua como a propria lingua portuguesa e transforma-la totalmente em linguagem grafica… a mais de 10000 anos antes da invensão da escrita o homem se utilizava propriamente de desenhos para se comunicar… a escrita as linguagens surjiram para ter mais facilidade na comunicação… para expor certas coisas é mais facil com desenho porem ele é sempre uma abstração de algo… vc não vai escrever um “a” em desenho vc vai desenhar um conteudo para melhor entendimento… o mesmo se da a uma linguagem de programação… se vc for desenhar fluxogramas para cada variavel, ifs, operandos, e toda a estrutura toda sem tocar em um pingo de codigo vai ter muito mais trabalho do que escrever propriamente o codigo… agora se vc vai mostrar o modelo como um todo… os objetos, os fluxos de dados, as interações dos atores com os modulos do sistema, entre os proprios modulos do sistema etc… dai é outra historia…
Uma duvida no item 1 ali dos requisitos do sistema diz:
Sistema Operacional Microsoft Windows 2000 SP4, XP, Vista.
e nosso amigo diz que ele é multiplataforma… multiplataforma em sentido a que? a execução do software???
Isto é pra dar risada???
[quote=luistiagos]mas um modelo grafico tem uma abstração muito grande… pode-se ter sim algo que pegue desenhos e transforme em binario porem não é o que o maker faz pelo que esta escrito no item 5 que vc disse… e no meu ver é algo muito mais trabalhoso de se fazer… expremente pegar uma lingua como a propria lingua portuguesa e transforma-la totalmente em linguagem grafica… a mais de 10000 anos antes da invensão da escrita o homem se utilizava propriamente de desenhos para se comunicar… a escrita as linguagens surjiram para ter mais facilidade na comunicação… para expor certas coisas é mais facil com desenho porem ele é sempre uma abstração de algo… vc não vai escrever um “a” em desenho vc vai desenhar um conteudo para melhor entendimento… o mesmo se da a uma linguagem de programação… se vc for desenhar fluxogramas para cada variavel, ifs, operandos, e toda a estrutura toda sem tocar em um pingo de codigo vai ter muito mais trabalho do que escrever propriamente o codigo… agora se vc vai mostrar o modelo como um todo… os objetos, os fluxos de dados, as interações dos atores com os modulos do sistema, entre os proprios modulos do sistema etc… dai é outra historia…
[/quote]
Nada impede que uma linguagem textual tenha uma abstração muito grande também!
E eu nunca disse que o maker compila os fluxogramas 
Sem uma versão demo, não tem como afirmar nada…
Pelo jeito sim :roll:
É… um código documentado não necessariamente é um código de qualidade :twisted:
[quote=luistiagos]mas um modelo grafico tem uma abstração muito grande… pode-se ter sim algo que pegue desenhos e transforme em binario porem não é o que o maker faz pelo que esta escrito no item 5 que vc disse… e no meu ver é algo muito mais trabalhoso de se fazer… expremente pegar uma lingua como a propria lingua portuguesa e transforma-la totalmente em linguagem grafica… a mais de 10000 anos antes da invensão da escrita o homem se utilizava propriamente de desenhos para se comunicar… a escrita as linguagens surjiram para ter mais facilidade na comunicação… para expor certas coisas é mais facil com desenho porem ele é sempre uma abstração de algo… vc não vai escrever um “a” em desenho vc vai desenhar um conteudo para melhor entendimento… o mesmo se da a uma linguagem de programação… se vc for desenhar fluxogramas para cada variavel, ifs, operandos, e toda a estrutura toda sem tocar em um pingo de codigo vai ter muito mais trabalho do que escrever propriamente o codigo… agora se vc vai mostrar o modelo como um todo… os objetos, os fluxos de dados, as interações dos atores com os modulos do sistema, entre os proprios modulos do sistema etc… dai é outra historia…
Uma duvida no item 1 ali dos requisitos do sistema diz:
Sistema Operacional Microsoft Windows 2000 SP4, XP, Vista.
e nosso amigo diz que ele é multiplataforma… multiplataforma em sentido a que? a execução do software???
Isto é pra dar risada???
[/quote]
Na verdade é o seguinte: Um fluxograma é igual a uma função.
Cada fluxograma é composto de várias caixinhas, que correspondem a instruções. Caixinhas retangulares são chamadas a outras funções. Caixinhas losangulares são IFs. Setinhas de fluxo são GOTOs (normalmente após uma instrução você vai para a instrução seguinte, o que deixa o fluxo estruturado, mas não há nada que te impede de abusar disso e produzir um fluxo macarrônico).
Para cada caixinha e para cada losango estão associados uma árvore de expressões, que correspondem aos parâmetros. Cada fluxo recebe uma quantidade de parâmetros como entrada e fornece um valor na saída.
Quando você constrói um fluxo usando como parte fluxos menores, você usa o construtor de expressões que cria a árvore de expressões semelhantemente ao que o compilador faz por debaixo dos panos, mas de forma visual (é muito estranho, vou tentar explicar depois).
Enfim, funções maiores são compostas de funções menores, assim como fluxos maiores são compostos de fluxos menores. Lá na raiz, no nível mais baixo, nas profundezas existirão as funções built-in do maker ou funções criadas em java, javascript ou outra linguagem (que o maker trataria como sendo uma linguagem de baixo-nível).
ah, não da para chegar a conclusão alguma. Pelo que o pessoal disse, no site fala uma coisa, o cara que apresentou a ferramenta pro kicolobo fala outra…
Sendo chato mais uma vez: sem uma versão demo, não tem como avaliar.
[quote=victorwss]
Isso é jogada de marketing. (…) E esse negócio de que pode-se documentar porque sobra tempo, nem é preciso dizer que é conversa para boi dormir.[/quote]
Com certeza…
Bem, minha opinião final sobre o Maker…
Já tive acesso completo e estudei algumas coisas sobre Genexus (voce tem mesmo 40% de ganho de produtividade na maior parte dos casos) por um projeto do governo, e tambem tive acesso ao Maker umas duas vezes vendo um pouco e mexendo bem pouco. Li todo o Help dele na Maxwell, videos de Help, opiniões da galera e de gente que usa mesmo…
Pra uma consultoria de 3 letrinhas que quer fazer a coisa a torto e a direito onde a regra POG “O importante é funcionar” vale , o negócio realmente vale a pena. O código funciona, mas é sem qualidade, lento, e é aquilo que muitos falaram: personalizar erros e icones é impossivel pelo que vi. E sem contar os proprios problemas com arquitetura, e isso de voltar a ser procedural, cara, é retardamento puro. Pra projetos pequenos o negócio presta, ja que voce nao vai ter que dar qualidade alguma quase em uma porrada de coisas. Assim como para sistemas que você, só você e mais ninguém vai dar manutenção e o sistema e pequeno e tem um prazo muito curto, tambem presta. Mas pra programadores inteligentes que gostam de criar tudo e deixar a coisa mais otimizada e pronta para crescer de forma saudável, não vale nem um centavo.
Um amigo meu está desenvolvendo uma solução completa pra adm publica usando Genexus, não tem nada tão complicado - só CRUD e relatórios, complicado mesmo são as regras e algumas raras impressões. E só ele vai dar manutenção mesmo. O trabalho dele está ficando até interessante. Se forem usar alguma ferramenta do tipo e queiram ganhar algum tempo, Genexus é a menos pior opção. O código é bem ruim também no final, mas voce conta com um suporte maior e a idéia é bem mais madura que do Maker. O preço é mais salgado sim, mas não confio mesmo na Softwell, imagina se ela fecha em 2 anos a galera que vai ter que migrar e falar “Que burrice que eu fiz”, esse é só um dos pontos. Se voces forem ver historicamente a quantidade de ferramentas no estilo que sumiram do mapa…
Resumindo:
Quer algo que tem o prazo bem curto e voce tem que entregar funcionando URGENTE, só funcionar é que importa: Genexus.
Quer algo bem inteligente, bem OO, bem fácil de dar manutenção, e algo realmente bom: Mão bruta.
Quer ser morto pelo proximo cara que pegar a aplicação: Maker.
Se o problema for ter que fazer uma porrada de crudzinho em tempo recorde e com baixa qualidade, mas que funciona (na maioria dos casos), use o Maker.
Sobre ferramentas CASE, etc, eu acho uma abordagem até interessante, mas quero ver quando alguma dessas ferramentas vai funcionar direito, talvez se tivesse alguma OpenSource fosse melhor. (Embora duvido que vai existir um dia).
Mas mesmo assim, quem precisar muito acho que vale a pena dar um olhada em: www.andromda.org .
[]'s
PS: Isso de não ter demo avaliável é realmente um absurdo. Uma demo, não um trial.
[quote=Sergio Figueras]Bem, minha opinião final sobre o Maker…
Já tive acesso completo e estudei algumas coisas sobre Genexus (voce tem mesmo 40% de ganho de produtividade na maior parte dos casos) por um projeto do governo, e tambem tive acesso ao Maker umas duas vezes vendo um pouco e mexendo bem pouco. Li todo o Help dele na Maxwell, videos de Help, opiniões da galera e de gente que usa mesmo…
Pra uma consultoria de 3 letrinhas que quer fazer a coisa a torto e a direito onde a regra POG “O importante é funcionar” vale , o negócio realmente vale a pena. O código funciona, mas é sem qualidade, lento, e é aquilo que muitos falaram: personalizar erros e icones é impossivel pelo que vi. E sem contar os proprios problemas com arquitetura, e isso de voltar a ser procedural, cara, é retardamento puro. Pra projetos pequenos o negócio presta, ja que voce nao vai ter que dar qualidade alguma quase em uma porrada de coisas. Assim como para sistemas que você, só você e mais ninguém vai dar manutenção e o sistema e pequeno e tem um prazo muito curto, tambem presta. Mas pra programadores inteligentes que gostam de criar tudo e deixar a coisa mais otimizada e pronta para crescer de forma saudável, não vale nem um centavo.
Um amigo meu está desenvolvendo uma solução completa pra adm publica usando Genexus, não tem nada tão complicado - só CRUD e relatórios, complicado mesmo são as regras e algumas raras impressões. E só ele vai dar manutenção mesmo. O trabalho dele está ficando até interessante. Se forem usar alguma ferramenta do tipo e queiram ganhar algum tempo, Genexus é a menos pior opção. O código é bem ruim também no final, mas voce conta com um suporte maior e a idéia é bem mais madura que do Maker. O preço é mais salgado sim, mas não confio mesmo na Softwell, imagina se ela fecha em 2 anos a galera que vai ter que migrar e falar “Que burrice que eu fiz”, esse é só um dos pontos. Se voces forem ver historicamente a quantidade de ferramentas no estilo que sumiram do mapa…
Resumindo:
Quer algo que tem o prazo bem curto e voce tem que entregar funcionando URGENTE, só funcionar é que importa: Genexus.
Quer algo bem inteligente, bem OO, bem fácil de dar manutenção, e algo realmente bom: Mão bruta.
Quer ser morto pelo proximo cara que pegar a aplicação: Maker.
Se o problema for ter que fazer uma porrada de crudzinho em tempo recorde e com baixa qualidade, mas que funciona (na maioria dos casos), use o Maker.
Sobre ferramentas CASE, etc, eu acho uma abordagem até interessante, mas quero ver quando alguma dessas ferramentas vai funcionar direito, talvez se tivesse alguma OpenSource fosse melhor. (Embora duvido que vai existir um dia).
Mas mesmo assim, quem precisar muito acho que vale a pena dar um olhada em: www.andromda.org .
[]'s
PS: Isso de não ter demo avaliável é realmente um absurdo. Uma demo, não um trial.[/quote]
Essa é a sua opinião.
Nada do que você falou do Maker foi provado.
Não precisa ser provado, é a impressão dele que estudou a plataforma
Investigativo Will,
poderia ser mais específico com relação ao que não foi provado? 
Senhores.
Recentemente a empresa em que eu trabalho se interessou pelo Maker. Então tive a oportunidade de fazer um curso sobre a ferramenta, de 40 horas. Também pude brincar bastante e forçar a barra, pra ver afinal do que ela é capaz… Vou resumir então o que eu vi.
1 - O Maker NÃO É OO, é estruturado.
Você precisa der uma base de dados bem modelada para começar a produzir. O que a farramenta faz é ler a base e criar formulários, os formulários são criados em minutos e com toda funcionalidade básica CRUD e pesquisa avançada criados.
Internamente ele divide em controle e view. A vantagem é que o tempo para criar esse tipo de tela é muito rápido.
Você pode também criar uma tela de funcionalidade mais complexa, desenhando-a, mas aqui pode precisar usar alguns ‘truques’ ou gambis mesmo para fazer do jeito que vc quer. Porém, mesmo assim terá um ganho em produtividade.
Para codificar as regras ou comportamentos especiais, vc usa os fluxogramas, que nada mais são que algoritmos ou um diagrama de atividades, porém 100% procedural.
Com os fluxos vocÊ consegue fazer coisas interessantes como abrir e gravar arquivos, trabalhar com result sets, e até consumir web-services. É claro, não da pra fazer tudo que vocÊ pode fazer um linguagem OO, mas quebra o galho quando o objetivo é criar sistemas corporativos
Mas que tipo de sistemas?
Bom, o Maker serve para vc fazer sistemas que vão rodar em intranets, QUE NÃO USAM OBJETOS DISTRIBUÍDOS, QUE NÃO REQUEREM UMA ARQUITETURA COMPLEXA (Muitos EJB´s, interface com mobile, RPC, etc), mas é possível uma integração em nível de web-services.
2 - O Maker não é CODER-KILLER.
Esse papo de que o Maker é para leigos é mentira, se o cara não saber SQL e nem lógica de programação, não saber o que é uma variável, não vai sair do lugar.
Ele não vai tirar emprego de programadores.
Agora o que realmente mata é o preço e o fato de não possuir uma versão DEMO.
3 - O Foco não é na arquitetura e sim nas regras de negócio
Focar nas regras de negócio é muito louvavel, mas também gerar uma arquitetura mínima, que faça o produto final ficar pesado e lento, é lastimável.
4 - Esqueça o código gerado
Se o seu cliente fizer questão do código-fonte, e ele não adquirir o Maker, ele ta literalmente perdido! Como ja falaram é impossível dar manutenção no código do maker, e nem é o objetivo do fabricante. O teu cliente vai ter que comprar o Maker e usa-lo para manutenção.
CONCLUSÃO.
No final das contas, o produto pode resolver sim alguns problemas no desenvolvimento, principalmente em relação ao custo e a prazos, mas não se pode pagar um alto preço por isso (em código ineficiente).
Ele é adequado para sistemas corporativos mais triviais, algo realmente muito complexo, esqueça.
Estarei começando um projeto pra valer, barra-pesada com o bicho, daí pretendo postar o dia-a-dia do desenvolvimento em blog. É isso.
Tchau!
Legal o seu depoimento Raven.
o maker tem sim mercado… quem disse que sistemas de padarias não vendem?
tive ate uma ideia para os marketeiros do maker olhem so:
Oi Raven,
Bacana seu depoimento, valeu mesmo.
O problema é que este tipo de software na verdade "tira o emprego" NÃO de quem não trabalha com ele mas SIM de QUEM trabalha com ele. Depois de um ano ou dois trabalhando com esse software o profissional terá restringido bastante seu campo de atuação no mercado, ou seja, irá trabalhar apenas onde houver o software implantado e o período para encontrar outra oportunidade pode se elevar no caso de uma demissão.
Tem gente que gosta e acho que até tem o perfil, os caras que trabalham com as ferramentas da SAP por exemplo são muito bem pagos (segundo dizem por ai) mas não fazem outra coisa, talvez nem quiram rsrsrsr.
Fica ai pra pensar, isso pode ser uma decisão importante na carreira do profissional.
[]'s
se eu tivesse a oportunidade de trabahar com sap…
consultor sap senior ganha uma merreca… so uns 220 a hra…
quem dera ter um emprego destes… dai sim fico feliz…
Concordo fantomas.
Na verdade o profissional de TI não pode parar JAMAIS! E por exemplo, um cara que acaba de sair de faculdade, se pegar um Maker pela frente já era, se tiver um dia que botar a mão na massa ta perdido!