Criterio De Evaluación Lenguaje De Programación
mevioz10 de Julio de 2014
12.864 Palabras (52 Páginas)1.157 Visitas
UNIVERSIDAD AUTÓNOMA DE SINALOA
Facultad de Informática Mazatlán
Taller de Programación Avanzada
Criterios de Evaluacion de los Lenguajes de Programación
Recopilo:
Humberto Rodríguez López
Academia de Informática
Cuerpo Académico “Tecnología e Informática Educativa”
Mazatlán, Sinaloa 15 Enero de 2009.
Criterios de evaluación de los lenguajes de programación 5
Criterios de lenguaje Según Doris Appleby y Julius Vandekopple 5
Definiciones bien definidas. 5
Sintaxis BNF y EBNF: 5
Semántica: 5
Comprobabilidad. 5
Confiabilidad. 6
Traducción rápida. 7
Código objeto eficiente. 8
Ortogonalidad. 9
Generalidad. 10
Consistencia en notaciones comunes. 10
Uniformidad. 10
Subconjuntos. 10
Extensibilidad. 11
Transportabilidad: 11
Propiedades de un buen lenguaje según Jorge Castro y otros 12
Aspectos de diseño 12
Claridad, simplicidad y unidad de conceptos. 12
Sintaxis y semántica bien definidas. 12
Consistencia con las notaciones usuales. 12
Soporte para la abstracción. 12
Independencia de la máquina. 12
Verificabilidad. 12
Redundancia. 12
Ortogonalidad. 13
Aspectos de Implementación. 13
Portabilidad. 13
Soporte Externo. 13
Calidad del compilador o intérprete. 13
Bajo costo de mantenimiento. 13
Documentación. 13
Criterios de evaluación según Terrence Pratt 14
Claridad, sencillez y unidad de los conceptos del Lenguaje. 14
Claridad en la sintaxis del programa. 14
Ortogonalidad. 15
Naturalidad para la aplicación. 15
Apoyo para la abstracción. 15
Facilidad para verificar programas. 16
Entorno de programación. 16
Portabilidad de Programas. 17
Costo de uso. 17
Costo de ejecución de los programas. 17
Costo de traducción de programas. 17
Costo de creación, prueba y uso de programas. 17
Costo de mantenimiento de programas. 18
Fundamentos de los lenguajes según Roger S. Pressman. 19
Tipos de datos y tipificación. 19
Nivel 0: sin tipos. 19
Nivel 1: coerción automática de tipos 19
Nivel 2: modo mixto conversión de tipos 19
Nivel 3: comprobación de tipos pseudorrígida 19
Nivel 4: fuerte comprobación de tipos 20
Subprogramas. 20
Estructuras de Control. 20
Soporte para el enfoque orientado a objetos 21
Características de un Buen Lenguaje según Allen B. Tucker 23
Expresividad. 23
Bien definido. 23
Tipos y Estructuras de Datos 23
Modularidad. 23
Facilidades de Entrada – Salida. 23
Transportabilidad. 23
Eficiencia. 23
Pedagogía. 23
Generalidad. 24
Criterios de Evaluación de los lenguajes según Robert Sebesta 25
Legibilidad. 25
Sencillez. 25
Ortogonalidad. 26
Sentencias de Control. 28
Estructura de Datos. 28
Diseño de sintaxis. 29
Forma de los identificadores. 29
Las palabras especiales. 29
Forma y significado. 30
Fácil Escritura. 30
Sencillez y Ortogonalidad. 30
Soporte para la abstracción. 31
Expresividad. 31
Confiabilidad. 32
Legibilidad y Fácil Escritura. 32
Verificación de Tipos. 32
Manejo de Excepciones. 33
Restricción de Alias 33
Costo. 33
Entrenamiento del programador. 33
Escritura del programa. 34
Compilación. 34
Ejecución. 34
Mantenimiento. 34
Criterios de evaluación de los lenguajes de programación
Es importante determinar cuando un lenguaje es eficiente, para esto existen determinados criterios o características que nos ayudan, cabe mencionar que no existen lenguajes buenos o malos sino apropiados e inapropiados para una determinada situación o problema. Para esto cada autor refleja según su criterio que características importantes debe cubrir un lenguaje para un buen desempeño del mismo, cabe mencionar, que los lenguajes son diseñados e implementados, por esta razón es necesario conocer todos los puntos de vista.
Criterios de lenguaje Según Doris Appleby y Julius Vandekopple
DEFINICIONES BIEN DEFINIDAS. Los programadores de Fortran o Pl/1 trabajan a menudo como un grupo. Si uno no sabía o había olvidado cómo escribir el código para efectuar una tarea particular, la cosa más fácil por hacer era bajar al vestíbulo y preguntarle a un amigo. Los manuales eran volúmenes inmensos pobremente organizados que enseñaban mediante ejemplos con más frecuencia que por cualquier otro medio.
Sintaxis BNF y EBNF: Los diseñadores de Algol 60 rectificaron esto al proporcionar una sencilla descripción del lenguaje en 18 páginas. La sintaxis del lenguaje está descrita en la forma Backus Naur (BNF), seguida de ejemplos de programación. BNF es un ejemplo de un metalenguaje, un lenguaje utilizado para describir otro lenguaje, en este caso uno de programación. BNF tiene símbolos llamados metasímbolos, y reglas propias, las cuales son empleadas para definir la sintaxis del lenguaje particular de programación en cuestión. Por sintaxis entendemos una colección de instrucciones formada al seguir un conjunto de reglas que diferencian los programas válidos de los no válidos. La sintaxis por sí misma no da significado a un lenguaje; meramente define la colección de frases y sentencias que son combinaciones válidas de los caracteres del lenguaje.
Semántica: Un lenguaje también debe de estar definido semánticamente al describir la manera precisa lo que significa una construcción particular. Por ejemplo, la expresión (X < 3) significa en pseudocódigo que X debe tener un valor; ese valor es comparable al entero 3, y la expresión es verdadera si el valor es menor que 3, y es falsa en otros casos. El lenguaje natural es notoriamente ambiguo, de manera que hace esfuerzos para describir formalmente la semántica del lenguaje así como también la sintaxis.
COMPROBABILIDAD. Probar con certeza matemática que un programa es correcto es un proceso lento. Sin embargo, C.A.R. Hoare cree que “las ventajas prácticas de la comprobación de programas eventualmente se sobrepondrán a las dificultades, en vista de los costos creciente de los errores de programación”. La prueba de que un programa es correcto involucra tres pasos: primero la comprobación de que el programa cumple con la intención del programador; segundo la prueba de que el compilador traduce de manera correcta a código máquina la sintaxis y la semántica del lenguaje empleado; y tercero, que se compruebe que la máquina misma funciona correctamente.
Una meta para cualquier lenguaje de programación es probar que un compilador para el lenguaje lo interpreta de manera precisa. Esto es a menudo difícil de hacer si la definición del lenguaje incluye descripciones en lenguaje natural de lo que se desea mediante un trozo particular de sintaxis, si la sintaxis puede describirse en un lenguaje formal, y la semántica puede escribirse axiomáticamente, un compilador puede ser probado formalmente para satisfacer por completo tanto la definición sintáctica como la semántica del lenguaje.
La sintaxis de Pascal fue definida en BNF, y su semántica definida axiomáticamente por su diseñador Nicklaus Wirth, en colaboración con C.A.R. Hoare. El PL/1 fue diseñado utilizando la definición Viena (VDL, Vienna Definition Language) y Algol 68 fue definida en una gramática vW de dos niveles (llamada así por el nombre de su inventor, A. van Wijngaarden) que era demasiado enigmática para la mayoría de los usuarios. Estos últimos dos metalenguajes forman bases para comprobación de compiladores. Si un lenguaje está definido en VDL, incluye una descripción de lo que pasa cuando cada declaración del lenguaje se ejecuta teóricamente en una computadora teórica. Si un compilador implementa fielmente la computadora teórica, puede probarse que la ejecución del programa es correcta. La gramática vW no describe una computadora teórica, pero permite que parte de la semántica que trata con declaraciones sea definida en la gramática. Por lo tanto no pueden generarse programas correctos gramaticalmente que vuelvan a declarar variables o que las definan de una manera inconsistente.
CONFIABILIDAD. El software se considera confiable si se comporta como es anunciado y produce los resultados que el usuario espera. Cuando se presenta un error, debería ser fácilmente detectado y corregido. Un lenguaje de programación fomenta la escritura de programas confiables de maneras a menudo sutiles. La declaración goto es quizá la característica más notoria de lenguaje pensada para dar como resultado programas no confiables. El problema que subyace aquí es que los programas con muchos gotos, hacia atrás y hacia adelante son difíciles de leer para cualquiera que no sea su creador, y por lo tanto difíciles de modificar y de depurar.
Las
...