NOMBRE:
PIO LARA ABIGAIL ALEJANDRA
NUMERO
DE CONTROL: 02230518
GRUPO:
MATERIA:
LENGUAJES Y AUTOMATAS
TEMA:
SEGUNDA TAREA
PROFESOR:
M. C. JOSE ANGEL TOLEDO A.
INTRODUCCION
La
resolución de problemas basados en computadoras involucra la implementación de
una serie de fases como son el análisis del problema, diseño de la solución,
implementación, prueba y depuración.
Un
trabajo comparativo entre el paradigma lógico de resolución de problemas y el
procedimiento en cada una de estas fases realizado por van Someren, demuestra
que la naturaleza del proceso de diseño es diferente para cada uno de estos
enfoques.
Desde el
punto de vista el procedimiento de diseñar la solución a un problema consiste
construir un algoritmo y elegir la estructura de datos adecuada que den
solución al problema planteado.
El
diseño puede verse entonces, dentro de este paradigma, como una tarea de
planeamiento. El programador construye un plan detallado que, al ser ejecutado
paso a paso por la computadora, conduce desde los datos de entrada hacia los
datos de salida.
El
objetivo de la construcción de este plan es descomponer el problema en
subproblemas de menor complejidad que puedan ser abordados individualmente. De
manera que, obtener la solución al problema global, no es más que combinar las
soluciones obtenidas para problemas relativamente simples y bien definidos. En
este proceso se encuentra implícita la selección de una estrategia que organice
el plan y conduzca la construcción del mismo hacia el objetivo planteado.
Como
resalta van Someren en el trabajo antes mencionado, la idea de plan no es tan
útil con lenguajes de programación lógica. Lenguajes de este tipo, como Prolog,
no disponen de primitivas que se correspondan con los bloques de construcción
de un plan. A diferencia de los lenguajes imperativos en donde todo puede
traducirse a una combinación de estructuras de secuencia, selección y
repetición.
La fase
de diseño dentro del paradigma lógico, a diferencia del anterior, consiste en
la descripción del conocimiento involucrado en el problema con el fin de
obtener una representación simbólica del mismo a través de un conjunto ordenado
de relaciones (aserciones y reglas de inferencias).
El
obtener los resultados de salida esperados consiste entonces en una o más
consultas a la base de datos en donde se encuentra traducida la representación
en cláusulas lógicas, de manera de encontrar instancias individuales de las
relaciones allí descriptas.
Los
métodos de diseño e implementación de los lenguajes de programación han
evolucionado rápidamente desde los primeros lenguajes de alto nivel que
aparecieron a principios de los años 30.
Antes de
que un computador pueda ejecutar una tarea, debe programársele para que lo haga
colocando en la memoria principal un algoritmo apropiado, expresado en lenguaje
máquina, que no es más que una secuencia de números mediante los que se
representan las operaciones a realizar y los operandos con los que operar.
Originariamente,
este proceso de programación se realizaba por el laborioso método de expresar
todos los algoritmos en el lenguaje de máquina, enfoque que hacía más penosa la
ya de por sí difícil tarea de diseñar un programa, y en la mayoría de los casos
daba pie a errores que era necesario localizar y corregir.
El
primer paso para eliminar estas complejidades del proceso de programación fue
la asignación de nombres mnemónicos a los diversos códigos de operación, y
usarlos en vez de la representación hexadecimal, aumentando considerablemente
la comprensibilidad de las secuencias de instrucciones de la máquina. Luego un
programa especial llamado ensamblador se encargaba la traducción de los códigos
mnemónicos a instrucciones en lenguaje máquina. A estos programas se les llamó
ensambladores, pues su tarea era ensamblar instrucciones en lenguaje máquina a
partir de códigos de operación y operandos. Por extensión, a los lenguajes que
utilizaban los mnemónicos se les llamó lenguajes ensamblador.
En la
época en que aparecieron los primeros lenguajes ensambladores, parecía que se
había dado un gigantesco salto hacia adelante en la búsqueda de mejores
entornos de programación, y es por ello que se les comenzó a llamar lenguajes
de segunda generación, siendo la primera generación la compuesta por los
lenguajes máquina. Estamos en los primeros años 50 y ejemplos de estos
lenguajes podrían ser AUTOCODER, SPS, BAL o EASYCODER.
Una
consecuencia importante de la íntima asociación entre los lenguajes ensamblador
y de máquina es que cualquier programa escrito en lenguaje ensamblador depende
inherentemente de la máquina; esto es, las instrucciones del programa se
expresan en términos de los atributos de una máquina específica. Por tanto, un
programa escrito en lenguaje ensamblador no se puede transportar fácilmente a
otra máquina porque se tiene que rescribir de modo que se ajuste a la
configuración de registros y al conjunto de instrucciones de la nueva máquina.
Otra
desventaja de los lenguajes ensambladores es que el programador, aunque no
tiene que codificar las instrucciones en forma de patrones de bits, sí está
obligado a pensar en términos de los pequeños pasos incrementales del lenguaje
de la máquina, y no puede concentrarse en la solución global de la tarea que
está realizando. En pocas palabras, las instrucciones elementales en que se
debe expresar finalmente un programa no son necesariamente las instrucciones
que deben usarse al diseñarlo.
De
acuerdo con esta idea, a mediados de los 50 se comenzaron a crear lenguajes de
programación que eran más propicios para la elaboración de software que los
lenguajes ensamblador de bajo nivel. El resultado fue la aparición de una
tercera generación de lenguajes de programación que difería de las anteriores
en que sus instrucciones eran de alto nivel y además independientes de las
máquinas. Una vez escrito el programa con instrucciones de alto nivel, se
utilizaba un programa llamado traductor que traducía a lenguaje máquina los
programas escritos en lenguajes de alto nivel. Estos programas son parecidos a
los ensambladores de la segunda generación, solo que a menudo tienen que compilar,
reunir varias instrucciones de máquina para formar secuencias cortas que
simularan la actividad solicitada por la instrucción de alto nivel, y por esta
razón se comenzó a llamar compiladores a este tipo de programa.
Unos de
los primeros lenguajes de la tercera generación son FORTRAN y COBOL, por lo que
algunas clasificaciones les colocan en la segunda generación. También está
ALGOL60. Después de estos aparecen otros como BASIC (1965), SNOBOL, APL, PL/1 y
SIMULA, entre otros. En los 70 aparecen lenguajes de alto nivel como PASCAL, C,
MODULA y PROLOG. Más recientes son Eiffel, Smalltalk, ADA, ML, C++ y Java.
Con la
aparición de los lenguajes de tercera generación se alcanzó, en gran medida la
meta de la independencia respecto a las máquinas. Como las instrucciones de
estos lenguajes no hacían referencia a los atributos de ninguna máquina en
particular, se podían compilar con la misma facilidad en una u otras máquinas.
Así, en teoría, un programa escrito en un lenguaje de tercera generación se
podía utilizar en cualquier máquina con sólo aplicar el compilador apropiado.
Sin embargo, la realidad no ha resultado ser tan simple.
Las tres
primeras generaciones de lenguajes siguen una sucesión en el tiempo, mientras
que a partir de ahí, las dos últimas generaciones han evolucionado
paralelamente y en campos bastantes distintos.
Los
lenguajes de cuarta generación pretenden superar los problemas surgidos de los
lenguajes de tercera generación:
Estos
lenguajes permiten generar aplicaciones de cierta complejidad con un número de
líneas menor que el que tendríamos si usáramos un lenguaje de tercera
generación. Para construir aplicaciones el programador contará, aparte de un
conjunto de instrucciones secuénciales, con una gran diversidad de mecanismos
como son: el rellenado de formularios, la interacción con la pantalla, etc. Un
ejemplo de este tipo de lenguajes es SQL.
La
quinta generación de lenguajes se ha relacionado con los lenguajes que se
utilizan en el campo de la inteligencia artificial: sistemas basados en el
conocimiento, sistemas expertos, mecanismos de inferencia o procesamiento del
lenguaje natural. Lenguajes como LISP o PROLOG han sido la base de este tipo de
lenguajes.
Vamos a
centrar nuestro estudio en un lenguaje orientado a objetos, y antes de ver las
características de este tipo de lenguajes es bueno dar un repaso de los
diferentes tipos de lenguajes de programación que han existido.
Aunque
existan cientos de lenguajes diferentes, estos se pueden agrupar según las
distintas filosofías que han seguido y la forma de trabajar que implican.
El
paradigma por procedimientos, también conocido como paradigma imperativo,
representa el enfoque tradicional del proceso de programación. Se define el
proceso de programación como el desarrollo de procedimientos que, al seguirse,
manipulan los datos para producir el resultado deseado. Así, el paradigma por
procedimientos nos dice que abordemos un problema tratando de hallar un método
para resolverlo.
En
contraste, consideremos el paradigma declarativo que hace hincapié en la pregunta
¿Cuál es el problema? en vez de ¿Qué procedimiento necesitamos para resolver el
problema? Lo importante aquí es descubrir e implantar un algoritmo general para
la resolución de problemas, después de lo cual se podrán resolver éstos con
sólo expresarlos en una forma compatible con dicho algoritmo y aplicarlo. En
este contexto, la tarea del programador se reduce a crear un enunciado preciso
del problema, más que a descubrir un algoritmo para resolverlo.
Desde
luego, el principal obstáculo para crear un lenguaje de programación basado en
el paradigma declarativo es el descubrimiento del algoritmo básico para
resolver problemas. Por esta razón, los lenguajes declarativos tienden a ser de
propósito específico, diseñados para usarse en aplicaciones particulares.
El
paradigma funcional contempla el proceso de creación de programas como la
construcción de cajas negras, cada una de las cuales acepta entradas y produce
salidas. Los matemáticos llaman funciones a tales cajas, y es por ello que este
enfoque se denomina paradigma funcional. Las primitivas de un lenguaje de
programación funcional consisten en funciones elementales a partir de las
cuales el programador debe construir las funciones más elaboradas necesarias
para resolver el problema en cuestión.
Otro
enfoque para la creación de programas es el paradigma orientado a objetos, OO.
El término programación orientada a objetos se refiere a un estilo de
programación por lo que un lenguaje orientado a objetos puede ser tanto
imperativo como declarativo; lo que los caracteriza es la forma de manejar la
información: clase, objeto y herencia. En este enfoque, las unidades de datos
se consideran objetos activos, en vez de las unidades pasivas contempladas por
el paradigma por procedimientos tradicional. Para aclarar esto, consideremos
una lista de nombres. En el paradigma por procedimientos, esta lista no es más
que una colección de datos, y cualquier programa que quiera trabajar con ella
deberá incluir los algoritmos para realizar las manipulaciones requeridas. Así,
la lista es pasiva en el sentido de que la mantiene un programa controlador, en
vez de tener la responsabilidad de mantenerse ella misma. En cambio, en el
enfoque orientado a objetos la lista se considera como un objeto formado por la
lista misma y por una serie de rutinas para manipularla. Por ejemplo, pueden
ser rutinas para insertar una nueva entrada en la lista, para detectar si la
lista está vacía o para ordenar la lista. De este modo, un programa que obtiene
acceso a esta lista no necesita contener algoritmos para efectuar esas tareas;
simplemente aprovecha las rutinas suministradas en el objeto. En cierto
sentido, en vez de ordenar la lista como en el paradigma por procedimientos, el
programa pide a la lista que se ordene a sí misma.
Muchas
ventajas del paradigma orientado a objetos son consecuencias de la estructura
modular que surge como subproducto natural de la filosofía orientada a objetos,
pues cada objeto se implanta como un módulo individual, bien definido, cuyas
características son en gran medida independientes del resto del sistema. Así,
una vez desarrollado un objeto que representa a una determinada entidad, es
posible reutilizar ese objeto cada vez que se requiera dicha entidad. De hecho,
un rasgo primordial de los lenguajes de programación orientados a objetos es la
capacidad de representar definiciones de objetos a modo de esqueletos, clases,
que pueden usarse una y otra vez para construir múltiples objetos con las
mismas propiedades, herencia, o modificarse para construir nuevos objetos con
propiedades similares.
La
programación OO está adquiriendo popularidad a grandes pasos, y muchos creen
que dominará el campo de la programación en el futuro.
El
lenguaje orientado a objetos más conocido es Smalltalk, que apareció en 1976.
Es un lenguaje de tipo imperativo donde se utilizó por primera vez el
vocabulario que se ha hecho característico de este tipo de lenguajes. Un
lenguaje que se ha añadido a los llamados orientados a objetos es la extensión
de C aparecida en 1986, C++. Aunque es muy diferente a Smalltalk, ha sido muy
popular por ser una extensión del lenguaje C. Uno de los últimos lenguajes OO
aparecidos es Java, al que dedicamos el siguiente apartado.
OBJETIVO Y FILOSOFIA DEL DISEÑO
DE LOS LENGUAJES DE PROGRAMACION
OBJETIVOS
Y FILOSOFIAS DEL DISEÑO
v
Comunicación
humana
v
Prevención
y detección de errores
v
Usabilidad
v
Efectividad
v
Compilabilidad
v
Eficiencia
v
Independencia
de la máquina
v
Simplicidad
v
Uniformidad
v
Ortogonalidad
v
Generalización
y especialización
v
Otras
filosofías de diseño
COMUNICACIÓN
HUMANA
Desarrollar
tecnología para la comunicación humana, significa fijar la atención en cómo la
tecnología puede apoyar la comunicación y coordinación de acciones entre las
personas. En este sentido la antigua lógica de "Sistemas de
Información" evoluciona hacia un "Sistema de Comunicación" en
que lo esencial es que el sistema es efectivo en tanto permite apoyar la
coordinación de determinadas acciones.
Esta aproximación
implica develar y entender cómo es que nos comunicamos, que rol juega el
lenguaje y como formalizamos y volvemos cotidiana la práctica de coordinarnos.
En este sentido la filosofía de Newtenberg se centra en entender como es la dinámica
de conversaciones en una determinada comunidad y cuales son los haceres que
están en juego para luego sustentar con diversas tecnologías una manera de
hacer lo que se quiere hacer que sea más adecuada y propicie mayor bienestar a
la comunidad.
Se
busca una comunicación eficiente entre el programador y el ordenador. Un
buen nivel de comunicación se da cuando los programas son leíbles. No ha
de ser necesaria una documentación externa al programa (minimizar). Es más
importante que un programa sea leíble que escribible.
•
Un programa se
escribe una vez, pero se lee muchas durante su depuración, documentación y
mantenimiento.
•
Tendencia
actual a separar la interfaz de la implementación de un módulo.
La
sintaxis ha de reflejar la semántica es:
Reducir
las manipulaciones implícitas
Coerciones
(coerciones de PL/I o C)
ON
de BASIC para eventos o excepciones
Constructores y
destructores de C++ (necesarios, pero complican el seguimiento del flujo de
ejecución).
PREVENCION
Y DETECCION DE ERRORES
El programador comete errores
Hay que prevenir los errores
El programador es su fuente
El programador no sabe lo que hace y el compilador ha de limitar sus
acciones (EUCLID, PASCAL)
Hacer imposible cierto tipo de errores
Ejecutar datos -> control de flujo limitado
Errores en el uso de datos -> Tipado fuerte
Apuntadores erróneos -> Gestión de memoria implícita (LISP, PROLOG,
ML, etc.).
Hay que facilitar su detección, identificación y corrección
Redundancia
Tener que declarar antes de utilizar.
Evitar coerciones inductoras de errores
float a int por su pérdida de precisión
Comprobaciones en tiempo de ejecución
Índice de array fuera de límites
Control sobre los apuntadores a NULL
LENGUAJE
UTLIZABLE Y EFECTIVO
Un lenguaje ha de ser fácil de utilizar
Un lenguaje ha de ser fácil de aprender y recordar
•
Evitar la necesidad de consultar el manual (C++ no
cumple)
•
Lenguaje simple (C++ no cumple)
•
Aprendizaje incremental (PROLOG no cumple, LISP si
cumple)
El comportamiento del lenguaje ha de ser predecible
·
el uso de void* de C++ es incomprensible
·
Efectividad
Los detalles de implementación no han de oscurecer las intenciones del
programador
•
Soportar abstracción
•
Modularidad: Separar especificación de implementación
Los Efectos de un cambio han de quedar localizados
Evitar los trucos (programas ilegible)
OTRAS FILOSOFIAS
DEL DISEÑO
v
Compilabilidad
o
Se ha de poder compilar programa en un tiempo reducido
o
Se ha de poder depurar o aplicar otras herramientas
de análisis
v
Eficiencia: La ejecución ha de ser rápida
v
Independencia de la máquina
v
Simplicidad
v
Uniformidad: lenguaje predecible
v
Ortogonalidad
o
Todas las características del lenguaje se han de
poder combinar
v
Generalización y especialización
o
La generalización dice que algo similar también es
correcto, pero es difícil de implementar
o
Hay que especializar para facilitar la
implementación sin perder la utilidad del lenguaje
v
Diseño Detallado
v
Microestructura
v
Estructura de las expresiones
v
Estructuras de datos
v
Estructuras de control
v
Estructura de compilación
v
Estructura de la entrada/salida
v
Ejemplos:
Lenguajes de Programación y su Diseño
v
El lenguaje C
o
Aplicación: programación de sistemas
o
Programador: experto
o
Sacar el mayor rendimiento posible del ordenador
v
PASCAL
o
Aplicación: docencia
o
Programador: inexperto
v
LISP
o
Aplicación: procesamiento simbólico
o
Desarrollo rápido
v
PROLOG
o
Aplicación: procesamiento simbólico
o
Programación lógica
o
Desarrollo rápido
FILOSOFIA DE PRUEBAS
Su objetivo es descubrir errores. Un buen caso de
prueba es aquel que tiene una gran probabilidad de encontrar errores no
hallados antes. El éxito de una prueba es descubrir, al menos, un error no
detectado con anterioridad.
“Las pruebas no pueden asegurar la ausencia de
errores; sólo pueden demostrar que existen errores en el software” .Se pueden
aplicar criterios para garantizar la calidad
Un mito: Buen trabajo = ningún error
“Si fuéramos buenos de verdad en nuestro trabajo no habría
errores”
Error: culpabilidad por trabajo defectuoso
Según lo anterior: si hay errores es
que somos malos trabajando
Descubrir el error = fracaso
Una prueba que descubre un defecto
significa poner de relieve la culpabilidad de la negligencia mítica antes
citada. Por tanto, dicha prueba se asimila a un fracaso actitudes adecuadas
Técnicas de diseño de
casos de prueba
Enfoque estructural o de caja blanca (White
box testing): tratan de recorrer toda la estructura del programa y las posibles
secuencias de sentencias. En algunos casos es impracticable (un programa de 50
sentencias con 25 IFs generaría 33,5 millones de
Secuencias potenciales) Enfoque funcional o
de caja negra (Black box testing):
Se trata de generar pruebas y compararlas con los
Resultados esperados. Enfoque aleatorio (realiza
modelos, a veces estadísticos): es una combinación de ambas hasta un cierto
límite de posibilidades.
CICLO COMPLETO DE PRUEBAS
Planificación de pruebas
Diseño de pruebas
Ejecución de pruebas
Plan de pruebas
Configuración de las pruebas
Casos
Procedimientos
Resultados
Evaluación
Depuración Errores
Análisis de errores
Estadística de errores
Notificación de defectos del software
Correcciones
Configuración del software
Desarrollo
Actividades preventivas
Información del software
Predicción de fiabilidad
Información del proyecto
CONDICIONES GENERALES
Cada caso de prueba debe definir el resultado
esperado de la misma. El programador evitará probar sus programas
Inspeccionar con detalle el resultado de cada
prueba Inclusión de entradas inválidas o inesperadas. Examinar el programa para
comprobar si hace lo que debe hacer y si no hace lo que no debe hacer Evitar
utilizar casos desechables
No plantear pruebas suponiendo que no habrá errores
La probabilidad de encontrar nuevos errores es proporcional al
Número de errores descubiertos
Pruebas = tarea creativa + desafío intelectual
Una declaración general de objetivos es suficiente
para empezar a hacer programas. Los requerimientos del proyecto cambian
continuamente pero los cambios pueden acomodarse fácilmente ya que el software
es flexible.
CONCLUSION
No hay ningún método de análisis, diseño y programación
que funcione bien; yo me voy a mi terminal y empiezo a escribir código. Cuando
hacemos el programa y funciona ya ha terminado mi trabajo Hasta que no tengo un programa
funcionando no se puede saber su
calidad....
DISEÑO DETALLADO
INTRODUCCION
El diseño detallado tiene que ver con la especificación de detalles
algorítmicos, representaciones concretas de datos, interconexiones entre
funciones y estructuras de datos, y empaque del producto de programación. El
diseño detallado está fuertemente influenciado por el lenguaje de
instrumentación, pero no es lo mismo que la instrumentación; el diseño
detallado tiene que ver más con aspectos semánticos y menos con detalles
sintácticos que es la instrumentación.
El punto de inicio para el diseño detallado es una estructura arquitectónica a
la que se le van a proporcionar los detalles algorítmicos y las
representaciones concretas de datos. Mientras que hay una fuerte tentación para
proceder directamente de la estructura arquitectónica a la instrumentación, hay
varias ventajas que pueden lograrse en el nivel intermedio de detalle
proporcionado por el diseño detallado.
La instrumentación comunica los
aspectos de la sintaxis del lenguaje de programación, el estilo de codificación
la documentación interna, y la inserción de pruebas y depuraciones al código.
Las dificultades que se encuentran durante la instrumentación casi siempre se
deben al hecho de que el instrumentador simultáneamente está realizando
análisis, diseño y actividades de codificación mientras intenta expresar el
resultado final en un lenguaje de instrumentación.
El diseño detallado permite el
diseño de algoritmos y representaciones de datos en un nivel más alto de
abstracción y notación que el que proporciona el lenguaje de instrumentación.
El diseño detallado separa la actividad de diseño a
bajo nivel de la instrumentación, igual que las actividades de análisis y
diseño aíslan las consideraciones de lo que se desea de la estructura que
logrará los resultados deseados.
Una especificación adecuada de diseño detallado minimiza el número de
sorpresas durante la instrumentación del producto. Las actividades
de diseño detallado inevitablemente exponen los defectos en la estructura
arquitectónica y las modificaciones resultantes se verán facilitadas por tener
menos detalles por manipular que los que estarían presentes en el lenguaje de
instrumentación.
El diseño detallado también proporciona un vehículo para inspecciones de
diseño, recorridos estructurados y la revisión crítica del diseño. Las
notaciones para el diseño detallado incluyen a los diagramas HIPO, el
seudocódigo, el inglés estructurado, los diagramas de flujo estructurados, los
diagramas de estructuras de datos, y las distribuciones físicas para las
representaciones de datos.
La representación del diseño detallado puede utilizar palabras clave del
lenguaje de instrumentación para especificar el flujo de control, y proposiciones
de declaración del lenguaje para especificar la representación de datos. El
empaque tiene que ver con la manera en que los datos elementales globales son
compartidos selectivamente entre las unidades del programa, la especificación
de áreas de datos estáticos, el agrupamiento de unidades del programa como
funciones y subrutinas, la especificación de los mecanismos para el paso de
parámetros, las estructuras de archivos y las técnicas para su acceso, y la
estructura de las unidades de compilación y módulos de carga. El diseño
detallado debe llevarse hasta un nivel donde cada proposición en la notación
del diseño resulte en unas cuantas (menos de 10) proposiciones en el lenguaje
de instrumentación. Dadas las especificaciones arquitectónicas y de diseño
detallado, cualquier programador familiar con el lenguaje de instrumentación
debe ser capaz de implantar el producto de la programación.
ESTRUCTURAS
DE DATOS
Las estructuras de datos son conjuntos
de variables, quizás de tipos distintos, relacionadas (conectadas) entre sí
de diversas formas y las operaciones definidas sobre esa agrupación. Ejemplos
de estructuras de datos las podemos encontrar en muchos ámbitos, desde las
matemáticas (estructuras algebraicas: grupo, anillo o cuerpo) hasta el mundo de
los negocios (estructura de una empresa). Los elementos de una estructura de
datos dependen del lenguaje de programación a través de los tipos de datos que
los definen. Sin embargo, la estructura en sí, que está definida por el tipo de
relación entre los elementos, no depende del lenguaje de programación empleado.
ESTRUCTURAS
DE EXPRESION
Son las
estructuras en las cuales se van a encontrar las expresiones de el lenguaje,
las expresiones se le puede llamar a cada operación o instrucción que se
coloque por el programador en el momento en que este se encuentre haciendo un
programa y es importante checar las expresiones para saber que resultado dará.
Documentación
del diseño
La buena
documentación proporciona una explicación de la forma en que opera el sistema y
qué características tienen los modelos y algoritmos utilizados en él. Muchos
paquetes de hoja de cálculo y de ayuda para la toma de decisiones guardan todos
estos detalles en forma automática a medida que se van especificando. Aunque
esta información es transparente para el usuario, se puede recuperar cuando sea
necesario ya sea en forma impresa o a través de una pantalla.
Muchos lenguajes de cuarta generación son auto-documentados, lo que significa
que los propios programas son tan fáciles de entender que ellos se convierten
en su propia documentación.
Revision de especificaciones del diseño
Una
política que admita la revisión, por parte del departamento de sistemas, de
todas las aplicaciones diseñadas por los usuarios será de gran ayuda para el desarrollo
de sistemas que cumplan con su finalidad y que sean confiables. Desde el punto
de vista de la organización, esta estrategia también permite hacer cumplir de
manera estricta los estándares de diseño y la validación de las suposiciones
hechas durante la formulación de las especificaciones.
El método de desarrollo por parte de los usuarios se está utilizando cada vez
más en muchas organizaciones. Los procedimientos eficaces para su manejo serán
de gran ayuda para asegurar que los resultados beneficien a los individuos y a
la organización.
Planes de pruebas
piloto
Los planes de prueba son un importante, pero a menudo
pasado por alto, producto del diseño de la programación. Un plan de prueba
describe varias clases de actividades que se efectuarán para demostrar que el
producto de programación cumple con sus requisitos.
El plan de prueba especifica los objetivos de las pruebas
(lograr una operación libre de errores bajo condiciones establecidas y periodos
determinados), los criterios de realización de pruebas (lograr una tasa
especificada de exposición a errores, lograr un porcentaje especificado de
cubrimiento de un camino lógico), el plan de integración del sistema
(estrategia, planeación, individuos responsables), métodos a utilizarse en
módulos particulares (recorridos, inspecciones, análisis estático, pruebas
dinámicas, verificación formal), y los casos particulares de prueba a
utilizarse.
Hay cuatro tipos de pruebas que un producto de programación debe satisfacer:
Es el proceso de aplicar distintas técnicas
y principios con el propósito de definir un dispositivo, proceso o sistema con
los suficientes detalles como para permitir su realización física.
NIVELES DE
DISEÑO
El diseño de
sistemas tiene cinco puntos principales: salida, entrada, procesamiento,
especificación de datos y especificación de procedimientos.
1. Diseño de
salida. El diseño de un
sistema de información basado en computadora es diseñar la salida o resultado
que producirá el sistema. Se evoca a la selección de contenido forma y medio
para los informes y el resultado que generará el sistema.
*informes
*contenido
*forma
*medio
*formato
*realce
2. Diseño
de entrada. Se seleccionan los registros de entrada y los métodos de tal
manera que conozcamos cuales son los datos que se van a proporcionar cada vez
que corra una aplicación en la computadora.
*registros
*medio
*modo
*volumen
3. Diseño
de procesamiento. Se especifica él cómputo, manejo de datos y la lógica
necesarios para producir el resultado.
*cálculos
*lógica
*frecuencia
*volumen
4. Especificación
de datos. Se especifican los datos algunos se marcarán para que se
almacenen en los archivos maestros, y otros datos que serán de entrada cada vez
que se corra una aplicación.
*contenido del
registro.
*diseño del
registro
*especificación de
los archivos.
*organización de
los archivos.
*volumen
5.
Especificación de procedimientos.
Se desarrollan los programas y el software de computadora así como los archivos
y la elaboración de bases de datos. 3
*corridas de
computadora
*documentar el
proceso
*métodos de
control
*procesos manuales
*procedimientos
operativos. 3
Tiene 5 etapas fundamentales.
Especificación de procedimientos es donde vamos a recopilar toda
nuestra información, identificar el o los problemas es necesario tomar en
cuenta la factibilidad de nuestro diseño.
Especificación de datos. Aquí es donde tenemos que tomar en cuenta los
datos que vamos a utilizar de que tipo son, se diseñara el registro, los
archivos.
Diseño de procesamiento. Una vez que ya sabemos los datos que habrán
que utilizarse se tendrá que saber la frecuencia de estos datos y en donde se
utilizarán, que cálculos habrá de hacerse para que funcione nuestro sistema
para poder elegir un lenguaje de programación adecuado para que de el resultado
requerido.
Diseño de entrad. Una vez que se sabe que lenguaje se utilizara
entonces empezamos a programar cuidando que los datos e intrusiones den como
resultado en la pantalla del usuario la información que este desea.
Diseño de salida. Es el resultado final, se realizan las pruebas para
corroborar que nuestro sistema funcione adecuadamente para poderlo implantar.
TECNICAS PARA EL DISEÑO
ANALISIS DE TRANSFORMACION
Es un conjunto de
pasos de diseño que permiten a un DFD, con características de flujo de
transformación, convertirse a un templeta predefinida para la estructura del
programa.
Pasos del diseño
del análisis de transformación.
Revisión del
modelo fundamental del sistema.
Comienza con una evaluación de la especificación del sistema y de la
especificación de los requerimientos del software. Describen el flujo y
estructura de la información de la interfase del software y describen el nivel
máximo del flujo de datos.
Revisión y refinamiento
de los diagramas de flujo de datos para el software. Usando la información obtenida de una
especificación de requerimientos del software, se deriva de un diagrama de
flujos de datos.
Determinar si
el DFD tiene características de transformación o transacción. El diseñador selecciona una característica
global del flujo basándose en la naturaleza prevalente del DFD. Además, se
aíslan las regiones locales del flujo de transformación o transacción.
Aislar el
centro de transformación especificando los límites del flujo de llegada y
salida. En la sección
precedente se describió en flujo de llegada como un camino en el que la
información de transforma interno a externo. Los límites de flujo de llegada y
salida están abiertos a interpretación: esto es, diferentes diseñadores pueden
seleccionar puntos algo diferentes en el flujo como posiciones límites. De
hecho, pueden derivarse soluciones de diseño alternativas variando la
colocación de los límites de flujo.
Realización del
“primer nivel de factorización”.
La estructura del programa representa una distribución descendente del control.
La factorización de cómo resultado una estructura de programa en la que los
módulos de nivel superior toman las decisiones de ejecución y los módulos de
nivel inferior ejecutan la mayoría de trabajo de entrada, computacional y de
salida. Los módulos de nivel intermedio ejecutan algún control y realizan
moderadas cantidades de trabajo.
Cuando se
encuentra el flujo de transformación, un DFD se organiza en una estructura específica
que da el control para la llegada, transformación y salida del procedimiento de
la información.
6. Ejecución
del “segundo nivel de factorización”.
El segundo nivel de factorización se realiza mediante la conversión de las
transformaciones individuales (burbujas) de un DFD, en los módulos
correspondientes de la estructura del programa. Comenzando en límite del centro
de transformación y yendo hacia fuera a lo largo de los caminos de llegada y
luego de salida, las transformaciones se convierten en niveles subordinados de
la estructura de software.
7. Refinar la
estructura del programa de “primer corte” usando medidas y heurísticas de
diseño. Una estructura de
programa de primer corte puede siempre refinarse aplicando los conceptos de
independencia de módulos. Se pueden aumentar o reducir el número de módulos
para producir una factorización.
ESTRUCTURAS
I/O
Es
la forma en que se van a introducir datos, y la salida de los mismos. Tenemos
que ver de qué manera se van a introducir datos a nuestro lenguaje ya que sin
los datos, pues no se hará absolutamente nada.
Estructuras
del compilador
Descripción general de un compilador
Se describen las
distintas organizaciones que puede presentar un compilador, desde la elección
del lenguaje anfitrión hasta las etapas y fases de su implementación.
COMPILADORES:
Es un programa que traduce un lenguaje de alto nivel al lenguaje
máquina. Un programa compilado indica que ha sido traducido y está listo para
ser ejecutado. La ejecución de los programas compilados es más rápida que la de
los interpretados, ya que el interprete debe traducir mientras está en la fase
de ejecución (saca todos los errores).
Un compilador es un programa que
traduce el programa fuente (conjunto de instrucciones de un lenguaje de alto
nivel, por ejemplo BASIC o Pascal) a programa objeto (instrucciones en lenguaje
máquina que la computadora puede interpretar y ejecutar). Se requiere un
compilador para cada lenguaje de programación.
Un compilador efectúa la
traducción, no ejecuta el programa. Una vez compilado el programa, el resultado
en forma de programa objeto será directamente ejecutable. Presentan la ventaja
considerable frente a los intérpretes de la velocidad de ejecución, por lo que
su uso será mejor en aquellos programas probados en los que no se esperan
cambios y que deban ejecutarse muchas veces.
.