pautas para programar

que gusto poder intercambiar "opiniones" y no solo "codigo fuente"

gracias :))


"Alfredo Novoa" wrote in message
news:

On Tue, 8 Jun 2004 17:04:14 +0100, "Cecilia Loureiro"
wrote:

>¿cuales creen que sean las reglas basicas para crear programas que:
>1. sean eficientes
>2. sean entendibles
>3. puedan ser mantenidos sin mucho problemas.?

La mia es eliminar en todo lo posible la codificación y poder ejecutar
directamente las especificaciones.

La mejor manera de no tener problemas con el código es no tener código
:-)

Saludos
Alfredo

Disculpen que me cuelgue de la conversacion sin previo aviso, pero queria
darles una humilde opinion al respecto, creo que la solucion a sus problemas
estan en los Metodos Formales, tanto como para analisis de requerimientos,
especificacion de modulos, como para la validacion de los mismos.

Saludos
Sebastian.
P.D.: con metodos formales no me refiero a UML, me refiero a Larch, TLA,
StateCharts, CSP, etc.


"Alfredo Novoa" wrote in message
news:

On Wed, 9 Jun 2004 09:34:12 +0100, "Cecilia Loureiro"
wrote:

>y que hay con respecto a la especificacion de requerimientos
>Dios bendiga al que invento las herramientas de modelaje...
>pienso que con ellas todos los desarrolladores de una misma empresa
>se ven forzados a usar un mismo lenguaje...

El problema es que normalmente es un lenguaje con el que no se puede
decir casi nada.

>aunque me he topado con situaciones en las cuales se arman todos los

modelos

>de especificacion de acuerdo a las necesitades de los usuarios
>pero luego el codigo fuente no tiene nada que ver con este... ¡que dolor

de

>cabeza!
>veo un par de razones para que esto ocurra:
>1. que los procesos de negocio de los clientes o usuarios cambian
>constantemente

Eso pasa siempre. Yo creo que se debe a que los clientes o usuarios
raramente saben bien lo que quieren y cuando les enseñas lo que han
pedido se dan cuenta de que no es lo que ellos querían.

>2. que las personas que participan en la cadena de suministro de una
>aplicacion no hablan el mismo lenguaje entre ellas, es decir
>el usuario habla en chino, el analista habla en griego, el diseñador

habla

>en urdu y el programador habla en c++

Otra cosa muy normal es la falta de precisión de las especificaciones.
El analista pinta 4 rayas y el programador tiene que adivinar lo que
quiso decir.

Unas especificaciones verdaderamente precisas deberían poder ser
ejecutadas por un ordenador, y así nos ahorraríamos el tener que
codificar.

>lo primero es inevitable... es mas nosotros existimos para "alinear" los
>sistemas de informacion a estos cambios
>lo segundo... esta en nuestras manos.

Lo malo es que las herramientas que tenemos son muy pobres.


Saludos
Alfredo

Hola Sebastian,

Estoy de acuerdoUML no es un metodo formal, es un lenguage para modelar
sistemas.
Trate de buscar informacion sobre Larch, TLA, StateCharts, CSP pero no pude
encontrar mucho.
Veo que Larch posee dos lenguajes para hacer especificaciones, uno que es
especifico para cada lenguaje de programacion y otro que es generico.
Pero en ambos casos se refieren a especificaciones tipo algoritmos
matematicos...(quizas me equivoque, pero eso es lo que entendi). No estoy
segura de si esto se ajuste a problemas de negocio por ejemplo. A menos que
se puedan definir "todas" las necesidades de un usuario en terminos
matematicos.

Sobre StateCharts, ¿no es parte de UML?

¿Que significan las siglas TLA y CSP busque en google y me salieron un
monton de cosas?


¿Podrias darnos mas luz al respecto? Quizas poniendo un ejemplo con alguna
herramienta de MicroSoft ?

Gracias por tu interes en esta conversacion.

Cecilia




"Sebastián Flores" wrote in message
news:OND1Y4%

Disculpen que me cuelgue de la conversacion sin previo aviso, pero queria
darles una humilde opinion al respecto, creo que la solucion a sus

problemas

estan en los Metodos Formales, tanto como para analisis de requerimientos,
especificacion de modulos, como para la validacion de los mismos.

Saludos
Sebastian.
P.D.: con metodos formales no me refiero a UML, me refiero a Larch, TLA,
StateCharts, CSP, etc.


"Alfredo Novoa" wrote in message
news:
> On Wed, 9 Jun 2004 09:34:12 +0100, "Cecilia Loureiro"
> wrote:
>
> >y que hay con respecto a la especificacion de requerimientos
> >Dios bendiga al que invento las herramientas de modelaje...
> >pienso que con ellas todos los desarrolladores de una misma empresa
> >se ven forzados a usar un mismo lenguaje...
>
> El problema es que normalmente es un lenguaje con el que no se puede
> decir casi nada.
>
> >aunque me he topado con situaciones en las cuales se arman todos los
modelos
> >de especificacion de acuerdo a las necesitades de los usuarios
> >pero luego el codigo fuente no tiene nada que ver con este... ¡que

dolor

de
> >cabeza!
> >veo un par de razones para que esto ocurra:
> >1. que los procesos de negocio de los clientes o usuarios cambian
> >constantemente
>
> Eso pasa siempre. Yo creo que se debe a que los clientes o usuarios
> raramente saben bien lo que quieren y cuando les enseñas lo que han
> pedido se dan cuenta de que no es lo que ellos querían.
>
> >2. que las personas que participan en la cadena de suministro de una
> >aplicacion no hablan el mismo lenguaje entre ellas, es decir
> >el usuario habla en chino, el analista habla en griego, el diseñador
habla
> >en urdu y el programador habla en c++
>
> Otra cosa muy normal es la falta de precisión de las especificaciones.
> El analista pinta 4 rayas y el programador tiene que adivinar lo que
> quiso decir.
>
> Unas especificaciones verdaderamente precisas deberían poder ser
> ejecutadas por un ordenador, y así nos ahorraríamos el tener que
> codificar.
>
> >lo primero es inevitable... es mas nosotros existimos para "alinear"

los

> >sistemas de informacion a estos cambios
> >lo segundo... esta en nuestras manos.
>
> Lo malo es que las herramientas que tenemos son muy pobres.
>
>
> Saludos
> Alfredo

On Thu, 17 Jun 2004 14:54:02 +0100, "Cecilia Loureiro"
wrote:

Estoy de acuerdoUML no es un metodo formal, es un lenguage para modelar
sistemas.

Más bien son unas convenciones para dibujar diagramas.

Ahora a cualquier cosa se le llama lenguaje.


Saludos
Alfredo