Sistema por Módulos

[Pablo César]

Decidí colocar aqui as razões que eu considerei importantes para a criação do meu sistema em forma de módulos:

1. Posso dispor de qualquer externo seja aplicativos em Clipper ou aplicativos for WINDOWS (GUI), até mesmo acessorios do proprio WINDOWS como CALC.EXE, NOTEPAD.EXE, se eu quiser e sem ter me preocupar com falta de memória. Desta forma eu consigo disponibilizar um sistema HÍBRIDO para o cliente, aproveitando-me dos recursos gráficos que um aplicativo GUI oferece.

2. O meu sistema tem mais de 120 opções de menú. Não preciso me preocupar com o gerenciamento de memória e posso habilitar certos módulos de forma diferênciada para cada cliente. Isto é, no meu sistema de locação (para video ocadoras), tenho um módulo de Vendas, um módulo de Mala-Direta, um módulo para intereação com INTERNET (quando cliente tem um site), um módulo para o sistema de Inadimplentes, etc... e cada módulo cobro por separado, conforme a necessidade do cliente. Sei que irá me dizer, que poderia trabalhar com OVERLAYS, mas naquela época eu não dominava esse tipo de COMPILAÇÃO.

3. Facilita a identificação de problemas no sistema, ficando mais fácil e mais objetiva a manutenção. Sei que vai me dizer que por motivo de ser MUITOS arquivos executáveis, não facilita para mim a manutenção. Mas depois de tudo, é só copiar TODOS os executáveis e pronto.

4. Se tomasse em conta a quantidade de arquivos que eu deveria abrir de uma só vez no caso que fosse um executável apenas. Seria pouco viável e a margem de fragmentações de arquivos poderiam ser maior. Sei que vai me dizer que não haveria necessidade de abrir de uma só vez TODOS os arquivos. Mas é isso o mais indicado.

5. Ao trabalhar com vários executáveis e um arquivo BAT para gerenciar isso, me permite por sua vez acrescentar comandos do DOS e executá-los diretamente no arquivo de lote, sem dificuldades e com maior flexibilidade. Sabemos que as diferentes versões do WINDOWS variam nas opções de COMANDOS do SO.

Eu tenho a impressão que o meu sistema ao rodar deste modo (modular) é mais rápido que se fosse apenas um executável. Nem sei se daria compilar todas essas mais de 120 opções. Agregue a tudos isso, um pouco de teimosia (típico de todo programador) e a falta de maior conhecimentos.

Mas na minha avaliação, o sistema pode me levar mais tempo para ser atualizado com o cliente, mas posso lhe dizer que não tenho arrependimento algum. Pois graças a isso, flexibilizo mais o sistema, consigo enriquecé-lo com outros recursos e outros aplicativos, consigo fazer manutenção de forma mais organizada, e me permite (a vezes) fazer alteração do sistema sem precisar (quase) que usuários saiam do sistema. Isto quando é apenas um executável a ser modificado.

Acho, agora Leornado que esclarecí bem as minhas razões. E deixo ao colegas que façam a sua avaliação e comentar o sua opinião a respeito. Sinta-se livre de fazé-lo.

Um clip-abraço :)Pos

[Maligno]

Sei que vai me dizer que não haveria necessidade de abrir de uma só vez TODOS os arquivos. Mas é isso o mais indicado.

O que você quis dizer com abrir todos os arquivo de uma vez só? É sobre DBF? Se for, não é a forma mais indicada. É justamente o contrário: abrir apenas o DBF que for utilizado e fechá-lo assim que possível.

[]'s
Maligno
http://www.buzinello.com/prg

[sygecom]

Acho, agora Leornado que esclarecí bem as minhas razões. E deixo ao colegas que façam a sua avaliação e comentar o sua opinião a respeito. Sinta-se livre de fazé-lo.

Tche......primeiro quero deixar claro que não fiz critica e sim fiquei curioso para saber o pq de ter um sistema MODULAR.
Como eu não tenho grandes conhecimento estou sempre a procura de melhorias para meu sistema.

Beleza Pablo....agora vc deixou muito bem esclarecido, desculpas alguma coisa e uma otima semana...

Abraços

[Pablo César]

Leonardo, você não precisa pedir desculpas alguma. Primeiro que o colega MALIGNO fala uma coisa certa (ao meu ver):

abrir apenas o DBF que for utilizado e fechá-lo assim que possível

Outra você como mesmo disse, não disse nada a respeito. E mesmo que o fizesse TODOS teriam o direito de faze-lo, pois senão eu não teria a coragem de abrir um tópico e não ser criticado. Eu também vejo com muito bons olhos o debate, as criticas quando são construtivas e tudo isso que engloba o uso do FORUM. Também não tenho nada que ocultar, me arrepender ou disvirtuar-me com o que exponho aqui no FORUM. Outra que eu não sou obrigado e acho que aqui ninguém é obrigado fazer nada que não queira. Sim manter um nível de respeito e de camaradagem com os colegas (e olha que eu não sou comunista... hehehe)



Bem respondendo ao colega MALIGNO, como disse você tem razão, por isso que os meus módulos só abrem os BDs (BDF, MEM, CFG, TXT, etc...) apenas o que eu preciso para cada módulo. No entanto tenho para esclarecer melhor o que entendí da sua exposição, vamos por parte como disse JACK "O estripador", hehehe

O que você quis dizer com abrir todos os arquivo de uma vez só? É sobre DBF?

Por supuesto !. Maiormente os DBFs ou qualque BD que utilize-se de ponteiros para o posicionamento do BD.

É justamente o contrário: abrir apenas o DBF que for utilizado e fechá-lo assim que possível.

Sim, concordo. porém o procedimento contrário (de abrir todos os BD) é o que comumente é feito por uma grande maioria. Isto é é abertos os DBFs na primeira etapa de execução da aplicação passa por um menu (inclusão, edição, consulta, relatorios, etc...) e logo é executado a tarefa específica de acordo a opção do menu. Neste decorrer do usuário que OPTAR por um item de menú, os arquivos ficam desde então: abertos. Isso é o que comumente é feito. Digamos que quando o usuário entra num relatorio que lista os clientes (está usando o DBF_Clientes) e nesse momento não haveria necessidade de abrir os outros DBFs que não são utilizados nesse relatorio. Embora sempre devemos avaliar a necessidade de abertura dos BDs que irão ser utilizados. Porque o abrir e fechar os BD constantemente, também dão uma carga a mais no tráfego da rede. Tal é assim que este é o 2º item aconselhado no: http://www.caclipperwebsite.com/dicas.htm no item "Como agilizar o tráfego da rede no Clipper" de todas as formas é necessário avaliar com prudência as aberturas dos BD.

Na minha opinião, tudo isto é aplicável na seguinte situação:

Após a opção do usuário entrar en determinado iem do menu, vamos dizer (inclusão de clientes):

1.) Bem, deveria abrir o DBF_Clientes e seus (indices e DBF_Filhos, como DBF_Autorizados por exemplo).
2.) Entrar no DO WHILE, onde permitirá continuar a inclusão de mais de um cliente até que o usuário deseja-se.
3.) Nessa inclusão, que o recomendado é ser feito através de replace with "variáveis" ou "vetores". Não deve ser fechado o DBF_Clientes, apoós cada inclusão. E nem deve ser aberto o DBF_Autorizados a toda hora que é indicado que tem autorizado. Pois não é vantagem abrir o DBF_Autorizados somente quando o cliente tem autorizado. Eu acho que é aí onde parece haver uma certa divergência. Você não acha MALIGNO ?.

Mas por favor sintam-se livre de fazer qualquer comentário que considerar relevante.

Um clip-abraço :)Pos

[sygecom]

Achei que era so eu que tinha problema com nomes !!!

Leandro, você não precisa pedir desculpas alguma. Primeiro que o colega MALIGNO fala uma coisa certa (ao meu ver)

Tche, referente ao abrir os BD ou não no inicio..eu sempre fiz da seguinte maneira.....abro somente o que vou usar na quele momento e fecho tudo em seguida e não tenho problemas de trafego na rede !!!

Abraços

[Pablo César]

hihihihi, agora fui eu que errei nomes... Mas acabei editando e agora está certo, viu. Desculpe. :-$

eu sempre fiz da seguinte maneira.....abro somente o que vou usar na quele momento e fecho tudo em seguida e não tenho problemas de trafego na rede !!!

Mas que bom !. É assim que deve ser.

Um clip-abraço

[Pablo César]

Esquecí de mencionar mais uma razão que me induziu a optar pelo sistema modular:

Posibilita-me para poder personalizar um determinado módulo. Por exemplo a impressão de ficha cadastral. Normalmente existe um modelo default (vamos dizer) e o dono da locadora manda fazer um formulário personalizado com o nome da locadora e de LAYOUT diferenciado. Então posso disponibiliz-a-lo exclusivamente para tal cliente e possibilita fazer atualização sem modificar os outros clientes com o modelo DEFAULT.

O claro que para cada personalização é cobrado do cliente a mão de obra, por isso existe a impressão da ficha DEFAULT. Também... ninguem trabalha de graça, até relógio precisa de algo.

Um clip-abraço :)Pos

[Pablo César]

eu vou adiconando as minhas razões por ser sistema modular. E aqui vai mais uma:

Tive recentemente, um probleminha de nada com um arquivo que como mencionei lá no tópico do WAPI Clique aqui pra ver era por causa de estar comrrompido (fragmentado), muitas vezes ocorre por interrupção de execução do aplicativo sendo por travamentos do equipamento ou interrupções de energia. Por se tratar de arquivo corrupto (não me refiro aqueles que há em Brasilia... hihihi) eu entendia que era uma questão de RE-INDEXAÇÃO. Nada a ver. Isto me causou dor de cabeza, até que eu olhei o arquivo de LOG, onde grava TODOS os erros e ví que o problema estava num .DBF. Bem, decidí tratar este problema por separado, ja que eu ja possuía uma rotina de RE-INDEXAÇÃO cada vez que houvesse "corruption detected". Pois, agora, se tratando de aquele tipo de arquivo (.DBF) e ser também "corruption detected", acrescentei uma rotina de deleção do arquivo (ja que esse arquivo não representa grande perda para o usuário e dou uma mensagem pro usuário dizendo que tal arquivo foi deletado pelo sistema por haver estado corrompido e aconselho rever a ficha Nº tal. tudo isto, eu consigo colocar no LOOPING desse arquivo BATCH que gerencia todo o sistema modular. Trantando através de ERRORLEVEL e a criação de SUB arquivos em lotes que me permitam executar fora do programa.

Decidí fazer fora do meu aplicativo, porque não havia jeito de deletar tal arquivo.

espero que tenham entendido a minha salada de palavras. terei prazer de explicar melhor se me forem questionado.

Um clip-abraço :)Pos

[Pablo César]

Depois de ontem a noite quando os meus colegas me bombardearam.... hehe perguntando sobre se daria para colocar todos esses executáveis num só... decidí re-viver este tópico que eu ja tinha pensado que este assunto ja esta claro para todos. Ví que este assunto não ajudaria em nada lá no outro tópico que estava sendo questionado este outro assunto. O questionamento começou quando eu admití que a idéia que o colega Eolo apresentou sobre manter o (ou os) executáveis na respectiva estações para evitar tráfego na rede durante execução dos EXE.

Eu diria que ter muitos executáveis não é o problema, fica mais difícil ainda fazer a atualização do sistema quando se tem um dúzia de terminais ou mais. Eu disse que poderia ser feito uma rotina de verificação de atualização automática para cada estação, comparando o tamanho e data de cada executáveis. Claro, no meu caso daria um processamento considerável e até demorado para poder atualizar cada estação antes de entrar por 1ª vez no sistema.

Agora quanto as minhas razões... bem é só ler o tópico desde o começo que explica minhas razões. Mas quero que se sintam a vontade em questionar e/ou fazer alguma sugestão.

[Eolo]

Um ponto interessante a discutir é o seguinte: "antigamente", os EXEs tinham que se virar nos 640k de memória, certo? Mas, mesmo nessa época, é de se imaginar facilmente que programas 500 e não 120 opções [no menu] rodavam normalmente (overlays? Eu acho que sim.).

Bem, o que mudou então do PkLInk86 pro Blinker7? Como hoje eu consigo rodar um EXE com 1.500k, em modo real, usando os 640k? O Blinker "se ajeita" dinamicamente, por conta própria, pra dar conta do que for preciso?... Como afinal o SO lida com um EXE?

Eu, até hoje uso overlays [internos], em só um EXE. O menu fica no módulo principal e o resto (cada um dos módulos) é carregado numa única área de overlay.

E meus sistemas também são modulares. Se preciso bloquear um módulo, é só botar um "*" no menu... Na manutenção, se aparece um erro no Contas a Pagar, vou direto na função MP() - e suas sub-rotinas.

[Maligno]

A única real vantagem que vejo na criação de tantos EXEs é quanto à atualização via internet. Facilita um pouco mais, mas apenas um pouco. Não mudaria meu esquema atual. Quanto à necessidade de atualização, não seria difícil. E você nem precisaria comparar EXEs. Bastaria ter na internet um TXT com a lista dos EXEs atualizadas e seus MD5s. Comparar MD5s é bem mais rápido e seguro. E na máquina do cliente, bastaria uma rotina simples de verificação que permitisse o bloqueio temporário dos EXEs em vias de atualização. Sendo eles únicos ou um só, como é o meu caso.

No seu caso específico, Pablo, há o agravante de você ainda usar o RTLink. Para ter apenas um EXE. Talvez você precisasse migrar para o BLinker. Mas a configuração dos módulos não seria difícil. Na (des)contratação de um módulo, você apenas reconfiguraria seus menus. Não sei como se poderia fazer no Clipper puro, pois meu sistema de menus é customizado e já prevê não apenas a indisponilização de partes não contratadas, como também a indisponibilização das partes as quais os usuários não foram autorizados a utilizar.

Aliás, com relação a isso, você poderia até mesmo fazer (des)contratação de módulos sem sair do conforto de seu lar, apenas montando um arquivo texto devidamente criptografado e enviando para a internet. Seu programa, através de uma opção especial, faria o relicenciamento e a reconfiguração automática dos menus ao abrir esse arquivo especial.

Enfim, as possibilidades são muitas. E todas seguindo uma linha de pensamento bem moderna, trazendo praticidade e conforto para você próprio, sem permitir que o cliente tenha qualquer perda de qualidade. É só "ousar" um pouquinho mais e não se prender a conceitos antigos.

[Pablo César]

É caro Eolo, eu não sabia como compilar com OVERLAYs e muito menos conhecia o BLINKER 7. Só há alguns poucos anos atrás que fiquei sabendo. Só posso dizer, que não existe nenhuma situação em que eu a considere dramatica ao ponto de haver tanto tráfego na rede. E a sensação de liberdade para incrementar módulos sejam aplicativos Clipper ou GUI, deixa o meu sistema de uma forma bem comlexa e completa (completa bagunça, isso sim... hihi). Não falando sério, é uma enormidade de arquivos mas por incrível que pareça,´está tudo bem controladinho. Não tenho reclamação disso. Para ter um idéia, nesse sistema tenho no seu menú principal controlando mais de 136 itens (na verdade não são dezenas chega quase a serem centenas... hihihi). Com este recurso de ter um arquivo .BAT que através de errorlevels gerencia a opção escolhida no menú, dá gosto de poder chamar qualquer programa mesmo sendo GUI. O que me dá a propriedade de poder chamar meu sistema como "sistema modular híbrido".

Não sei se faria outros sistema dessa forma, muito menos em GUI, acho que aí seria um crime (talvez).

Estou expondo tudo isto, porque realmente posso dizer que "em time que está ganhando não se mexe" (eu não sou a favor desse conceito), apenas gostei do seu concetio de EXEcutáveis em cada terminal ora porque sempre estou procurando aperfeiçoar o sistema.

Até estou pensando em incorporar um módulo de controle para LAN HOUSE dentro do meu SISTEMÃO. Sei que existem diversos softwares que controlam muito bem o acesso de terminais (p/Lan house) mas os meus clientes me pedem a mim se não teria. E seria muito bom apresentar o CAIXA (seja em relatório ou consulta) TUDO que foi arrecadado (seja no meu sistema de locação como da LAN HOUSE). Irei avaliar ainda estra decisão, senão o faço em Clipper farei com outro GUI (feeware) que ainda possa acessar os dados do caixa (através de futura função do WAPI, acesso DDE) mas sempre estarei incorporando utilitários ao meu sistema a medida que não comprometa num TODO.

Ora seja

[Pablo César]

A única real vantagem que vejo na criação de tantos EXEs é quanto à atualização via internet.

Não vai creer Maligno, mas esta foi a minha primeira intenção. Na questão atualização. Só que cresceu, ficou muito grande.

na máquina do cliente, bastaria uma rotina simples de verificação que permitisse o bloqueio temporário dos EXEs em vias de atualização.

Aliás ja tenho isto, e funciona perfeitamente.


No seu caso específico, Pablo, há o agravante de você ainda usar o RTLink. Para ter apenas um EXE.

Talvez você precisasse migrar para o BLinker.

Se isso admito que seria melhor. Aliás tenho alguns módulos que estão compilado com BLINKER 5.10 (sei que você tem o 7, mas achei meio problemático a sua instalação e acabei desistindo temporáriamente). Mas outros módulo uso o RTLINK, pois eu havia encontradoalgumas incompatibilidades com a minha CT.LIB (despois me toquei, quase que recentemente) que existe um PATCH que corrige isso.

fazer (des)contratação de módulos sem sair do conforto de seu lar, apenas montando um arquivo texto devidamente criptografado e enviando para a internet.

Ja tenho isso. Bem simples (e seguro), parabéns Maligno, você também tem muita imagination.

Seu programa, através de uma opção especial, faria o relicenciamento e a reconfiguração automática dos menus ao abrir esse arquivo especial.

Bem ja neste caso, eu SEMPRE apresento no MENU todas as opções de forma completa, só que dá uma mensagem ao usuário que aquele módulo não está disponível para essa locadora. Utilizei este conceito para que demostre ao usuário o que ele tem e o quê poderia ele ter. Isso representa money na aquisição de módulo complementares como (teclado PINPAD, Mala direta, Sist.Inadimplentes, alimentar site próprio da locadora, etc...)

sem permitir que o cliente tenha qualquer perda de qualidade. É só "ousar" um pouquinho mais e não se prender a conceitos antigos.

Sim, eu considero muito essa questão do cliente não estar atrelado a nada. Disponibilizo o básico (há vezes alguns módulos são de graça quando o pagamento é a vista), mas outras opções tenho que cobrar, pois eu vivo disso. E na minha apresentação eu esclareço bem utdo isso. Levo horas e dias explicando meu sistema (essa é a parte cansativa, estar repeido...) porque não é possível mostrar num dia só todas as opções do sistema.

Quanto aos antigos conceitos... bem eu pre-sinto que o Clipper irá ficar no tempo. Por enquanto meu sistema faz sucesso e esse trem não posso parar nem re-estruturar pois seria uma perda de tempo. Mas se Deus me dá vida o suficiente, irei estudar, fazer a minha faculdade de informática, e irei me atualizar e pegar uma verdadeira linguagem de programação. Mas por enquanto, nas minhas possibilidades, estou ainda "limitado". Limitado entre aspas, pois ja viu algum clippeiro dar o braço a torcer e dizer que não dá pra fazer... hihihi

[Eolo]

em time que está ganhando não se mexe

Pois é, acontece o mesmo comigo. Acho que isso faz parte da natureza humana: a gente se "acostuma" com aquele caminho das pedras que a gente conhece bem e reluta em se aventurar.

Mas tem hora que não pode escolher, TEM que peitar a mudança. Foi o que aconteceu comigo e o XHarbour. Ou eu aprendia o danado ou perdia o cliente. Aprendi! Mas quando rodei o Hmake pela primeira vez, me benzi, dei ENTER e saí de perto... ah ah ah

Também, filosofando um pouco, acho que nós somos de uma geração onde a evolução era mais "lenta", dava pra assimilar mais as mudanças. Agora, po!, na manhã seguinte aquele software espetacular, de ontem, já era... Então, é mais difícil pra gente digerir tudo o que aparece.

Mas, enfim, como diz a sabedoria popular, "cada um sabe onde o sapato aperta". Então, não adianta o Pablo copiar o Eolo, ou vice-versa, se o resultado vai ser pior. Tem que olhar o custo benefício.

[Maligno]

Mas tem hora que não pode escolher, TEM que peitar a mudança.

Isso mesmo, Eolo. O programador, a certo altura da vida, tem que se rebelar. Até porque, se ele se acomodar, provavelmente há um concorrente "rebelde" à espreita.