Bueno, simplemente eso, que tán útil les resulta la utilización de diagramas de flujo o si lo consideran fundamental para estructurar vuestros programas.
 Gracias.

===================
Migrando desde visual basic, el Gambas de Ms
Mi blog gambero

Bueno, aqui es donde siempre ando liado, los diagramas.

Por un lado creo que un programa no puede ser programado sino se tiene clara la idea y/o cosas que debe de hacer la aplicación.

Yo siempre realizo los siguientes pasos:

1.- Papel y un boligrafo.

Aqui anoto el objetivo de la aplicación e incluso si es necesario me la dibujo esquemáticamente.

2.- Tambien me hago un poco la estructura de la base de datos si la precisa

3.- Si se ha de presentar a un cliente se realizan los diagramas.

Aplicaciones sobre diagramas hay unas cuantas, tienes freemind (que esta bien), también dispones del programa DIA. Para mi uno que suelo utilizar a vceces y sino con el propio Impress de openOffice puedes hacer autenticos organigramas.

Como bien te he comentado anteriormente, todo empieza por un papel y un boligrafo, anotando los objetivos a alcanzar por la aplicación, a partir de ahi se suele pasar a "limpio", en este caso a un organigrama. Esto siempre es muy util si debes de presentar el proyecto a un cliente.

Poro otro lado y para aplicaciones complejas, lo que hago es que la estructura de la base de datos la coloco de esta forma:

Asi siempre puedo ver visualmente que tablas van relacionadas. También es importante hacer esto si se va a trabajar en grupo en una misma aplicación.

Espero que esto te sirva

Saludos

Pedro Aguilar

===================
Saludos / Best Regards

Pedro Aguilar

http://edrossuse.blogspot.com
Desarrollador de LNXGEST

En mi caso, depende de la complejidad del programa. Hay cosas muy sencillas que no lo requieren y otras que sí por su envergadura.

Aunque yo no trabajo ni vivo de la programación, es decir, no hago aplicaciones para clientes sino para mi propio aprendizaje, es muy conveniente estructurar lo que vaya a ser nuestra aplicación, tanto a nivel gráfico como a nivel de lógica.

Unos cuantos bocetos y diagramas nos ayudarán a definir mejor los formularios, módulos y clases a emplear y a ordenar nuestras ideas. Eso redundará en un código más natural y legible a la vez que un correcto y más rápido desarrollo.

En cuanto al software a utilizar, como ya comentó estrella_de_galicia, hay múltiples alternativas y es a criterio personal la utilización de una u otra.

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Claro, el planteamiento con lápiz o bolígrafo y papel es fundamental.
 Yo los diagramas los hago con openoficce y me resulta bastante sencillo, y como lo mío es por puro placer de aprender, no me importa si el diagrama no  se ve profesional.
  Cuando aprendía visual basic no le daba mucha bolilla a los diagramas, y lo que es peor, no comentaba los códigos.
Lo bueno de los errores es que nos enseñan, y ahora comentar el código es una regla de oro.
Saludos

===================
Migrando desde visual basic, el Gambas de Ms
Mi blog gambero

Citar:

Bueno, simplemente eso, que tán útil les resulta la utilización de diagramas de flujo o si lo consideran fundamental para estructurar vuestros programas.

A mí no me resultaron muy útiles. Además he visto como generalmente los diagramas de flujo eran dibujados después de tener el programa terminado sólo para cumplir con una exigencia. Creo que lo mismo pasa a veces con algunos diagramas de UML, por ejemplo, los diagramas de casos de uso que sólo son útiles para bosquejar inicialmente los principales casos de uso del sistema y luego tener una vista general de los casos de uso y sus relaciones.

Cuando comencé a aprender programación me fue un poco más útil el pseudocódigo y los diagramas de flujo sólo en ocasiones muy puntuales. De los diagramas de flujo de datos (DFD) pasé de largo tanto como puede (de entrada me parecieron una pérdida de tiempo).

La cuestión es que los diagramas son sólo una herramienta. Si te ayuda a pensar, a analizar el problema y diseñar una solución, perfecto. Pero muchas personas razonan mejor de una forma más analítica y sus bosquejos los expresan con código (que no es lo mismo que tirarse a programar sin detenerse a pensar siquiera un instante).

===================
Cómo programar con Gambas

Speed Books: informática libre.

Estoy de acuerdo cuando dicen que depende de la complejidad del programa, y los diagramas de flujo solo funcionan cuando la complejidad es muy baja, yo prefiero usar pseudocodigo en papel para poder entender el problema y resolverlo.

Igual, a mi me parece más fácil el uso de pseudo-código.
Pero otra técnica que también empleo es, por decirlo de una forma, el cumplimiento de objetivos particulares dentro del código. Lo que digo es que programo unas líneas para que mi programa realice un primer objetivo, terminado éste sigo con el siguiente y así hasta que el programa esté completo.......... no sé, creo sería parecido a programación modular.

Saludos!

Citar:

Pero otra técnica que también empleo es, por decirlo de una forma, el cumplimiento de objetivos particulares dentro del código. Lo que digo es que programo unas líneas para que mi programa realice un primer objetivo, terminado éste sigo con el siguiente y así hasta que el programa esté completo.......... no sé, creo sería parecido a programación modular.

Está muy bien que lo hagas. Eso se llama desarrollo evolutivo. La programación modular es ubicua en el desarrollo de software, pero lo que describes se asemeja bastante a un proceso de desarrollo iterativo y evolutivo.

===================
Cómo programar con Gambas

Speed Books: informática libre.

@ fabianfv:

Gracias por la definición, igual y luego me busque artículos sobre ello pa' mejorar mi estilo de escritura de código.

El problema de ese tipo de desarrollo es que a veces los árboles no te dejan ver el bosque..., uno se centra en la pequeña parcela y después vienen los problemas globales.

Yo no utilizo diagramas, hace muchos años sí lo hacía, pero siempre me pareció demasiado lento. Como Hackernícola que soy (Hacker encerrado en su cueva, o sea, programador solitario), nunca he tenido que compartir mis diseños con nadie. Empezaba a hacer el diagrama y a mitad ya lo tenía claro y el terminar de escribirlo me parecía una pérdida de tiempo. Ahora, después de veintitantos años de programador, utilizo todas esas técnicas que a los principiantes se les dice que no usen nunca: No escribo nada, empiezo a teclear de inmediato sin meditármelo mucho, etc. etc... A veces me arrepiento, claro, pero ¿qué sería de la vida sin riesgo?

===================
No podemos regresar