Programação EXPRESS – Lógica e Fluxograma

Programação EXPRESS – Lógica e Fluxograma

Olá amigos, vou inaugurar uma nova área do site hoje chamada Programação EXPRESS. O Objetivo dessa sessão é ensinar um pouco de Lógica de Programação aos novos programadores (que muitas vezes aprendem pela Internet e pulam essa etapa importante do conhecimento).

Conhecer Lógica de Programação e seguir seus princípios evitam que muitos incidentes e bugs surjam. Então vamos deixar de lenga-lenga e vamos por mão a obra.

Lógica (do grego λογική logos ) tem dois significados principais: discute o uso de raciocínio em alguma atividade e é o estudo normativo, filosófico do raciocínio válido.  (fonte: Wikipedia)

Assim sendo, a Lógica de Programação tem, por principalmente objetivo, o foco em usar o raciocínio lógico no desenvolvimento de programas. Para isso lança mão de algumas técnicas no desenvolvimento desses programas, ais quais:

  • Fluxograma
  • Pseudocódigo (Algoritmo)
  • Linguagem de Programação escolhida

Vamos então falar um pouco desses caras. Pra começo de conversa o Fluxograma é abolido por quase todos os programadores, ficando a cargo do Analista de Sistemas ou Gestor de Projeto de Desenvolvimento fazer toda a documentação necessária. Ocorre que toda a parte relativa a Lógica do Programa deve ser muito bem documentada a fim de facilitar a manutenção do Sistema por qualquer pessoa com um grau médio de conhecimento em programação.

O Fluxograma é um diagrama (desenho) do fluxo dos dados no Sistema. É através dele que indicamos – visualmente – o que deve ser feito na programação. A velha máxima “entendeu ou quer que eu desenhe?!” é totalmente funcional aqui. O Fluxograma tem desenhos específicos para simbolizar cada processo. Assim existe um desenho para indicar o inicio do programa, um outro para indicar a leitura (armazenamento) de dados, outro para indicar a exibição (impressão) desses dados, estrutura de decisão e finalização do programa. Um desenho para cada coisa. Conforme abaixo:

fluxograma1

Esse lindo desenho que eu achei na Web (Google, Obrigado!) indica o inicio do programa, uma ação de processamento (aquela que não tem interação do usuário) que no caso é abrir o forno. A seguir testa uma condição, quer seja, o forno esta aceso. Sim, porque não faz o menor sentido querer por mais lenha na fogueira se nem fogueira tem (daí seguir o raciocínio lógico, não dá pra queimar etapas, tem que seguir passo-a-passo a ordem lógica das coisas). Caso o forno NÃO esteja aceso, precisamos acendê-lo, esta é a ação a ser tomada caso a condição não retorne uma resposta positiva a pergunta. Na condição sempre estamos fazendo uma pergunta! SEMPRE!!!!!!!!!!

Caso o forno esteja aceso, a resposta a pergunta da condição, portanto, foi verdadeira, então podemos por mais lenha na fogueira (literalmente). Uma vez que façamos isso, podemos enfim assar o pão. Pão assando, encerra o programa.

No Fluxograma o Quadrado representa um processamento de alguma informação, ou algo que não tem a mão do usuário no processo. Existem casos em que precisamos pedir ao usuário que nos informe algo. Ou testar uma condição (simbolo do losangolo). Ou exibir uma informação na tela. Alguns dos símbolos você encontra na lista abaixo, mas sempre é possível encontrar todos os símbolos no Google em tutoriais de Lógica de Programação.

fluxograma-ferramenta-da-qualidade

Todo o sistema deve ser documentado. Cada etapa, cada processamento modular ou linear deve estar documentado, tanto com o Fluxograma quanto com o Algoritmo. Isso porque nem sempre seremos nós a trabalhar com um sistema, nem sempre nossos estagiários ou colegas de trabalho tem o mesmo nível de conhecimento de programação que nós (as vezes estamos em um nível fora da realidade humana … conheço um cara assim). Portanto, para que os outros colegas de trabalho ou programadores do mundo a fora possam entender o que pretendíamos fazer, devemos documentar nosso sistema.

Eu sei, eu sei, você vai dizer que dá muito trabalho, que perde muito tempo …. mas reserve algumas horas do seu tempo de programação para isso. Você mesmo irá se agradecer por isso no futuro, quando for dar manutenção no código alguns anos após tê-lo feito. Acredite, é impossível saber exatamente porque fez algo no código anos após tê-lo feito. Primeiro porque seu conhecimento de programação irá aumentar (pelo menos é o que se espera) ao longo dos anos. Você irá se aprimorar, adquirir novos conhecimentos, se atualizar. O código que você fez no passado irá parecer ridículo, até mesmo incompreensível.  Teremos uma área para falar de boas práticas de programação. O mais importante é você saber que – SIM, você TEM que fazer o diagrama!

Bom, obviamente não existem só 1 tipo de diagrama. Assim como nós temos o Fluxograma, para aqueles que seguem a escola do MVC (um tipo de forma de desenvolver o Programa) existe o próprio diagrama. Para aqueles que seguem a UML (outra forma de desenvolver o Programa) existe outros incontáveis tipos de diagramas – no caso da UML existem diagramas para o banco de dados, diagramas para a interação com o usuário, etc. Não querem complicar sua vida com tantos diagramas, deixe isso para os professor dessas disciplinas na Faculdade. Por hora, o Fluxograma vai bastar.

Muitos não dão a devida importância ao Fluxograma, alguns livros de programação de escritores renomados, inclusive, não dedicam mais do que uma página a falar deles. Erro terrível, lembre-se sempre da máxima “quer que eu desenhe?!” Isso porque desenhando fica mais fácil pra entender. Pense nos homens das cavernas, eles deixaram desenhos … e por quê ?! Porque assim você entenderia o que ele viu ou quis mostrar a todos, independente de falar o mesmo idioma que ele, ou sequer falar. Basta olhar e você entende. É assim que serve o Fluxograma.

Aproposito, os desenhos do Fluxograma são universais, então mesmo que um Japonês que nunca aprendeu português olhar seu diagrama, ele vai entender.

Com isso terminamos o Programação EXPRESS de hoje. No próximo post vamos falar do Algoritmo (isso morde?!).