Enrealidad nosotros estámos más que familiarizados con el concepto de especificación, pero no con leguajes formales. Generalmente trabajamos con especificaciones técnicas escritas o diagramas funcionales, y pegamos el salto directamente al código. Como mucho trabajamos con pseudocódigo, pero no se hace mucho incapié demostrar que un algoritmo esté implementado correctamente según cierta especificación en lenguaje formal.

La única vez que me pidieron especificación en un lenguaje formal fué en "Sintaxis y Semántica de Lenguajes". Irónicamente no pedían que el lenguaje formal que usara siguiera una sintaxis en particular :p (se podría decir que era "semi-formal")

choquin escribió:Especificar te sirve para empezar a pensar el problema sin necesidad de ver como resolverlo...

O sea, se basa en el "Que?" y no en el "Como?"

Que es lo que debería cumplir un programa para que sea correcto.

Y se basa principalmente en las Precondiciones de un problema y las Postcondiciones.

voy a poner un ejemplo clásico de algoritmos 1, de cálculo de factorial. (voy a poner el código lo más simple posible para que todo el mundo entienda, capaz es un poco ingenuo el problema y la manera en que lo escribo, pero la idea es que nadie se quede afuera )

******
Especificación

 problema factorial (x: Int) = res : Int {

     requiere: x >= 0

     asegura res == prod[1..x]

}

Bueno, lo que dice es que tenes un problema que se llama factorial, una variable de entrada x y una de salida res que pertenecen a Z, requeris que el usuario ingrese valores mayores o iguales a cero, y aseguras que el resultado va a ser la productoria de la secuencia de los números entre 1 y la variable de entrada.

Pero obviamente, esto no te dice cómo es el algoritmo que vas a usar, ni que código tenes que escribir, sino, que es lo que ese algoritmo debería cumplir.

si te fijás bien en tu "especificación" sí estás diciendo el "cómo". cada vez que hacemos un diagramita, un dibujito, o lo que sea que no sea programar, estamos usando alguna especie de lenguaje formal. y estamos diciendo el cómo.

LeaTex escribió:si te fijás bien en tu "especificación" sí estás diciendo el "cómo". cada vez que hacemos un diagramita, un dibujito, o lo que sea que no sea programar, estamos usando alguna especie de lenguaje formal. y estamos diciendo el cómo.

Disculpame que no esté de acuerdo pero esa especificación (para mí) no te dice cómo resolver el problema... sino simplemente la precondición y la postcondición, o sea lo que necesita y lo que asegura... que es lo que debe cumplir el problema... pero igualmente pueden haber distintas especificaciones para un mismo problema que pueden ser más o menos declarativas.

De hecho, los dos programitas son bien distintos entre ellos, cumplen con la especificación y la idea del "como" resolverlos no se extrae de la especificación, sino más bien lo que podes extraer es el "que" debe cumplir.

Es una leve diferencia que confunde a mucha gente.

Y la productoria de una secuencia, es un concepto matemático.

de hecho una de las definiciones clásicas del factorial en matemática es con la productoria

n! |(n = 0) == 1
|(n /= 0) == productoria de i desde 1 hasta n con n perteneciente a N

(el simbolito que iría en lugar de productoria sería como un PI grandote)

o sea se puede definir a n! por inducción.

http://mate.dm.uba.ar/~spuddu/inducc.pdf fijate la página 8

a lo que quiero llegar es a que solo delimité lo que requería el programa x>=0 y lo que asegura como resultado o sea... la misma definición (matemática) del factorial incluye a la productoria y solo está definida para valores mayores o iguales a 0. (de ahí viene la precondición, el "requiere") y la postcondición también viene de la definición del factorial matemático.

La verdad que no se me ocurre como hacer la especificación más declarativa aún jejeje

Solo use la misma definición (matemática) de factorial.

gente, espero que todos hayan terminado con sus finales y q los hayan rendido re bien

un abrazo grande y q terminen bien el año!

HAVE A NICE 2009!

Cita:si te fijás bien en tu "especificación" sí estás diciendo el "cómo". cada vez que hacemos un diagramita, un dibujito, o lo que sea que no sea programar, estamos usando alguna especie de lenguaje formal. y estamos diciendo el cómo.

DIfiero en eso....

No te dice como obtener el factorial, sino que valores de entrada y salida hay, esta especificando su interfase. El programa puede obtenerlo mediante una llamada recursiva, un calculo loco, un wev service o preguntandole al usuario inclusive :S

Además, diagramar para especificar el COMO a un nivel tan bajo solamente cumple con objetivos "comunicacionales".
Es para que la gente no técnica, y que no tiene intenciones de volverse técnica, pueda entender tu idea.

Personalmente pienso que diagramar a ese nivel es una práctica contraproducente, ineficiente, y debería ser considerada dañina "a la GOTO". Un simple pseudocódigo se explica, y te entrena verdaderamente a leer software, 10000 veces mejor que cualquiera de los diagramitas pedorros de algoritmos.

Teseracto escribió:

Cita:si te fijás bien en tu "especificación" sí estás diciendo el "cómo". cada vez que hacemos un diagramita, un dibujito, o lo que sea que no sea programar, estamos usando alguna especie de lenguaje formal. y estamos diciendo el cómo.

DIfiero en eso....

No te dice como obtener el factorial, sino que valores de entrada y salida hay, esta especificando su interfase. El programa puede obtenerlo mediante una llamada recursiva, un calculo loco, un wev service o preguntandole al usuario inclusive

Creo que estamos hablando de distintos "cómo". Yo me refería a cómo calcular el factorial de N, o sea, a la única forma que existe: multiplicar todos los números desde 1 hasta N.
Vos te estás refiriendo, según veo, a cómo programarlo. Pero es como decir que 3! puede ser
1 * 2 * 3
o también
3 * 2 * 1

En la "especificación" de choquin puso claramente prod[1..n]. O sea el cómo.
Después el programador decidirá cómo programarlo. Es otro "cómo".

Mmmmmmmmm... a mi me parece que tu "como" leatex está mas cerca de un que jajajaja


Osea, la especificacion es un qué mas que un como... cuando vos pones que va a sacar un factorial, te preguntas QUE ES UN FACTORIAL.. y efectivamente ese que te lleva a "la multiplicacion de todos los numeros de 1 hasta ese numero"... es un que.. el "como" es cuando lo implementás.

Chaito escribió:Mmmmmmmmm... a mi me parece que tu "como" leatex está mas cerca de un que jajajaja


Osea, la especificacion es un qué mas que un como... cuando vos pones que va a sacar un factorial, te preguntas QUE ES UN FACTORIAL.. y efectivamente ese que te lleva a "la multiplicacion de todos los numeros de 1 hasta ese numero"... es un que.. el "como" es cuando lo implementás.

No, el "qué" tiene que ver con "qué querés hacer". Y el "cómo" con "cómo se hace".
Choquin puso "Que es lo que debería cumplir un programa para que sea correcto."
O sea "qué" debe hacer un programa.

Resumiendo:
requerimiento -> qué
especificación -> cómo
implementación -> cómo 2

Tu pregunta de "qué es el factorial" me está diciendo cómo se calcula. O sea que si yo te pregunto "qué es un bizcochuelo" vos me dirías "es una mezcla de polvo para tortas que se mezcla con leche y huevos, se bate, se mete en el horno, bla, bla, bla".
Yo te diría "un bizcochuelo es un comestible" o "un bizcochuelo es una torta". Y te diría "un factorial es un número".

Hay mucha gente que confunde el qué y el cómo en muchos aspectos de la vida.
Ejemplo: Un nene rompe un plato, llega la mamá y le dice "qué hiciste?". El nene puede responder "rompí un plato" (cosa obvia) o "estaba buscando el control remoto, y de repente me caí de la silla, entonces en un intento de sostenerme agarré el mantel y se vino todo abajo". Entonces, si la mamá le pregunta "y cómo pasó?" para el primer caso el pibe tiene repertorio, para el segundo caso no, porque ya lo dijo.
Y así podría estar todo el día poniendo ejemplos:

Qué quiero? Un bebé.
Cómo hago un bebé? ...

Estoy de acuerdo con lo que dice Chaito de que a veces el qué y el cómo se mezclan un poco... pero bueno, uno más o menos entiende que la idea pasa por saber que el Cómo profundiza el Qué y se trata de implementarlo. En sistemas, el "cómo" es la máquina, el software, la ejecución, el programador... el "qué" es el "sistema", el usuario, el negocio, la empresa... muchas veces son dos enfoques de lo mismo, sólo que uno ve las cosas como una caja blanca (el cómo) y otro como una caja negra.

Me gustó el ejemplo del factorial. Los matemáticos suelen definir una cosa como la otra, así que son conceptualmente equivalentes "factorial" a "la multiplicación de todos los números de 1 hasta N".

Mirá si yo te digo "che, necesito un programa que multiplique todos los números de 1 hasta N"... y yo no sé que eso se llama factorial. Ese es mi Qué. Yo no sé resolverlo, no sé como lo vas a resolver, pero necesito que haga eso. No sé cómo. El cómo, lo definís vos, cuando decis "lo voy a hacer con un for en vez de hacerlo recursivamente para que no me tire un <<out of stack>> para números muy grandes".
Entonces, acá el "calcular el factorial", qué sería? un "super-qué"? y decir "lo voy a hacer con un valor Long para el número porque así me aseguro que puedo guardar valores muy grandes", qué es? Un "super-cómo"?

Ya sé, la estoy re limando, pero esto es algo que siempre observé cuando se habla del "qué" y el "cómo", y me parece que no es relevante, si no que lo importante está en saber que el "qué" está más de un lado y el "cómo" más de otro.

Y para no hacer off-topic... se podría decir que el Lic en CS de C está más cerca del cómo (o sabe más del cómo, o conoce mejores formas del cómo, etc.) y que un Ing. en Sistemas sabe mejor cómo manejarse con los "qué".
De todas formas, en sistemas en gral, la tendencia común es empezar laburando más dentro en el cómo y apartarse de eso con el tiempo hacia el qué, más en contacto con el usuario.

Finalmente, para molestar un poco, remarco algo:

Cita:Yo me refería a cómo calcular el factorial de N, o sea, a la única forma que existe: multiplicar todos los números desde 1 hasta N.

No es tan así, porque de hecho existen relaciones con otras funciones y uno podría, por ejemplo, calcularlo de despejar de estas funciones, sin necesariamente hacer la multiplicación. Capaz el pibe de sistemas se queda sólo con esta última, pero un Lic en CS de C tiene que conocer también las otras, ya que en su laburo (cuando se dedica realmente a la parte que le toca) podría significar una diferencia en performance importante (en el ejemplo, convengamos que multiplicar N números con N muy grande no es muy simpático para la máquina, capaz una aproximación vendría mejor...).

Cita: Capaz el pibe de sistemas se queda sólo con esta última, pero un Lic en CS de C tiene que conocer también las otras, ya que en su laburo (cuando se dedica realmente a la parte que le toca) podría significar una diferencia en performance importante (en el ejemplo, convengamos que multiplicar N números con N muy grande no es muy simpático para la máquina, capaz una aproximación vendría mejor...).

O talvez realiza un sistema distribuido en el que cada maquina multiplica cierta cantidad de numeros, reduciendo asi el tiempo que tarda la tarea.

Lo que el pibe mas arriba da es un ejemplo de como hacerlo en el "asgura res == prod[1..x]", por lo que creo que puede llegar a discutirse eso, pero exceptuandolo, lo demas es el "que quiero".

Que quiero?
Un bebe, cuyos progenitores seamos yo y mi pareja, y de raza humana,.
==
El factorial de N, con N perteneciente a los naturales, y cuya respuesta sea la productoria de 1 a x.

Precondiciones: Yo y mi pareja seamos los padres.
Postcondiciones: Que sea de raza humana. (que es medio obvio)

Precondiciones: N pertenece a los naturales.
Postcondiciones: Respuesta equivalente a la prod. de 1 a X.

La forma de tener un hijo (sexo tradicional, posicion perrito, inseminacion artificial, etc) no importa, si cumplen las pre y postcondiciones, al igual que el Factorial, no importa como lo obtengas, la respuesta debe ser equivalente a prod[1..x].

Holas... tanto tiempo!

Escribo... porque tengo algo q les puede interesar a los recibidos o en vías de hacerlo y también le puede resultar interesante al chico que le interesaba la Seguridad Informática.

http://www.lanacion.com.ar/nota.asp?nota_id=1103651

bueno, les mando un abrazo

choquin escribió:Holas... tanto tiempo!

Escribo... porque tengo algo q les puede interesar a los recibidos o en vías de hacerlo y también le puede resultar interesante al chico que le interesaba la Seguridad Informática.

http://www.lanacion.com.ar/nota.asp?nota_id=1103651

bueno, les mando un abrazo

Estuvieron piolas ahí.

Para los interesados en Seguridad Informática:

V Congreso Iberoamericano de Seguridad Informática CIBSI ?09 16 al 18 de Noviembre, 2009, Montevideo, Uruguay

http://www.fing.edu.uy/cibsi09

CHe,bueno aprovechando que hay estudiantes de la UBA aca.Tengo una duda sobre la carrera y la comparacion con lo que vemos en nuestra querida facultad.

A) ¿Que se ve en algoritmos 1,2 y3? Algoritmos 1 ...¿Equivale a algoritmos y estructuras de datos?
B) Sistemas Operativos...por lo que veo,ven muchos preconceptos,ahora cual es la orientacion de cada matería.¿Se ve lo mismo (sacando los conceptos previos)? ¿Se ve más? ¿Se ve menos?
C)Idem B pero con Metodos Numericos (¿Es lo mismo que modelos numéricos?)
D)¿Porque analisis II es "analisis II para computación"? (O seas porque el ultimo agregado ¿Acotan la materia sacando conceptos que no tienenque ver con las computadoras?
Desde ya,gracias.