Está en la página 1de 16

PREGUNTAS GENERADORAS UNIDAD 1

AUTOR: JUAN SEBASTIAN CORDOBA GONZALEZ

CORPORACIN UNIVERSITARIA MINUTO DE DIOS CERES APULO INGENIERA DE SISTEMAS IV SEMESTRE 2013
1

PREGUNTAS GENERADORAS UNIDAD 1

AUTOR: JUAN SEBASTIAN CORDOBA GONZALEZ

TUTOR: ING. SERGIO ALEJANDRO CAMACHO

CORPORACIN UNIVERSITARIA MINUTO DE DIOS CERES APULO INGENIERA DE SISTEMAS IV SEMESTRE 2013

Tabla de contenido
1. 2. 3. 4. 5. 7. 8. 9. INTRODUCCION ...................................................................................................................................... 4 OBJETIVOS............................................................................................................................................... 5 PREGUNTA 1 ............................................................................................................................................ 6 PREGUNTA 2 ............................................................................................................................................ 7 PREGUNTA 3 ............................................................................................................................................ 7 PREGUNTA 5. 6. ..................................................................................................................................... 12 CONCLUCIONES. .................................................................................................................................. 15 BIBLIOGRAFIA. ..................................................................................................................................... 16

1. INTRODUCCION
Este trabajo se realiza con el fin echo, de abarcar todo lo relacionado, con la programacion estrcutura y programacion orientada hacia los objetos, resaltando la previa participacion, de la evolucion, con el fin proposito, de conocer todo sobre la maravillosa area de la programacion.

2. OBJETIVOS
Resaltar la evolucion de la programacion estructurada. Sintetizar los avances logrados. Observar las metodologias que usa esta programacion Detallar el previo funcionamiento.

3. PREGUNTA 1

La Programacin Orientacin a Objetos (P.O.O.) surge en Noruega en 1967 con un lenguaje llamado Simula 67, desarrollado por Krinsten Nygaard y Ole-Johan Dahl, en el centro de clculo noruego. Simula 67 introdujo por primera vez los conceptos de clases, corrutinas y subclases (conceptos muy similares a los lenguajes Orientados a Objetos de hoy en da). Uno de los problemas de inicio de los aos setentas era que pocos sistemas lograban terminarse, pocos se terminaban con los requisitos iniciales y no todos los que se terminaban cumpliendo con los requerimientos se usaban segn lo planificado. El problema consista en cmo adaptar el software a nuevos requerimientos imposibles de haber sido planificados inicialmente. En los 70s cientficos del centro de investigacin en Palo Alto Xerox (Xerox park) inventaron el lenguaje Small talk que dio respuesta al problema anterior (investigar no planificar). En los aos 80s Bjarne Stroustrup de AT&T Labs., a mpli el lenguaje C para crear C++ que soporta la programacin Orientada a Objetos. En esta misma dcada se desarrollaron otros lenguajes Orientados a Objetos como Objective C, Common Lisp Object System (CIOS), object Pascal, Ada y otros. En el inicio de los 90s se consolida la Orientacin a Objetos como una de las mejores maneras para resolver problemas. Aumenta la necesidad de generar prototipos ms rpidamente (concepto RAD Rapid Aplication Developments). Sin esperar a que los requerimientos iniciales estn totalmente precisos. En 1997-98 se desarrollan herramientas CASE orientadas a objetos (como el diseo asistido por computadora). Del 98 a la fecha se desarrolla la arquitectura de objetos distribuidos RMI, Corba, COM, DCOM.

4. PREGUNTA 2
A finales de los aos 1970 surgi una nueva forma de programar que no solamente daba lugar a programas fiables y eficientes, sino que adems estaban escritos de manera que facilitaba su mejor comprensin, no slo proveyendo ventajas durante la fase de desarrollo, sino tambin posibilitando una ms sencilla modificacin posterior. El teorema del programa estructurado, propuesto por Bhm-Jacopini, demuestra que todo programa puede escribirse utilizando nicamente las tres instrucciones de control siguientes:

Secuencia Instruccin condicional. Iteracin (bucle de instrucciones) con condicin al principio.

Solamente con estas tres estructuras se pueden escribir todos los programas y aplicaciones posibles. Si bien los lenguajes de programacin tienen un mayor repertorio de estructuras de control, stas pueden ser construidas mediante las tres bsicas citadas. A finales del siglo XX casi todos los cientficos estn convencidos de que es til aprender y aplicar los conceptos de programacin estructurada. Los lenguajes de programacin de alto nivel que originalmente carecan de estructuras de programacin, como FORTRAN, COBOL y BASIC, ahora las tienen.

5. PREGUNTA 3
Las tcnicas de desarrollo y diseo de programas que se utilizan en la programacin convencional tienen inconvenientes, sobre todo la hora de verificar y modificar algn programa. En la actualidad estn adquiriendo gran importancia las tcnicas de programacin, cuyo objetivo principal es el de facilitar la comprensin del programa, y adems permiten, de forma rpida, las ampliaciones y modificaciones que surjan en la fase de explotacin del ciclo de vida de un programa o una ampliacin informtica. DEFINICIN DE LAS 3 ESTRUCTURAS BSICAS 1. Estructura Secuencial: Indica que las instrucciones de un programa se ejecutan una despus de la otra, en el mismo orden en el cual aparecen en el programa. Se representa grficamente como una caja despus de otra, ambas con una sola entrada y una nica salida.

Las cajas A y B pueden ser definidas para ejecutar desde una simple instruccin hasta un mdulo o programa completo, siempre y cuando stos tambin sean programas apropiados. 2. Estructura Selectiva: Tambin conocida como la estructura si verdadero - falso, plantea la seleccin entre dos alternativas con base en el resultado de la evaluacin de una condicin; equivale a la instruccin IF de todos los lenguajes de programacin y se representa grficamente de la siguiente manera:

En el diagrama de flujo anterior, C es una condicin que se evala; A es la accin que se ejecuta cuando la evaluacin de esta condicin resulta verdadera y B es la accin ejecutada cuando el resultado de la evaluacin indica falso. La estructura tambin tiene una sola entrada y una sola salida; y las funciones A y B tambin pueden ser cualquier estructura bsica o conjunto de estructuras. 3. Estructura Repetitiva (Iterativa): Tambin llamada la estructura hacer mientras - que, corresponde a la ejecucin repetida de una instruccin mientras que se cumple una determinada condicin. El diagrama de flujo para esta estructura es el

siguiente:

Aqu el bloque A se ejecuta repetidamente mientras que la condicin C se cumpla o sea cierta. Tambin tiene una sola entrada y una sola salida; igualmente A puede ser cualquier estructura bsica o conjunto de estructuras.

- Estructura para (FOR) - Estructura mientras (WHILE) - Estructura hasta (UNTIL) - Estructura iterar (LOOP) Estructura PARA (FOR) En esta estructura se repite una accin un nmero fijo de veces representado normalmente por N. Es necesario para el control de la repeticin utilizar una variable de control Vc y los valores que asignaremos a la misma inicialmente Vi y su correspondiente valor final Vf. El incremento de la variable de control Vc es normalmente 1, pero puede tomar otros valores positivos y negativos, en cuyos casos es necesario indicarlo por medio de In. El nmero de repeticiones N esta dado por la formula N=parte entera Vf Vi + 1 In Si N = O se obtiene un valor negativo, se dice que el bucle es inactivo y no se repite ninguna vez. En este tipo de estructuras existen una serie de normas de obligado cumplimiento, como son:

- El In no puede ser 0 (bucle infinito). - Vc no puede modificarse en el rango del bucle (accin A). Estructura MIENTRAS (WHILE) En esta estructura se repite una accin mientras se cumpla la condicin que controla el bucle. La caracterstica principal de esta estructura es la de que la condicin es evaluada siempre antes de cada repeticin. El nmero de repeticiones oscila entre 0 e infinito, dependiendo de la evaluacin de la condicin, cuyos argumentos en los casos de repeticin, al menos una vez, deberan modificarse dentro del bucle, pues de no ser as el nmero de repeticiones seria infinito y nos encontraremos en un bucle sin salida. Estructura HASTA (UNTIL) En esta estructura se repite una accin hasta que se cumpla la condicin que controla el bucle, la cual se evala despus de cada ejecucin del mismo. El nmero de repeticiones oscila entre 1 e infinito, dependiendo de la evaluacin de la condicin, cuyos argumentos en los casos de repeticin, al menos dos veces, debern modificarse dentro del bucle, pues de no ser as el nmero de repeticiones ser infinito y nos encontraremos en un bucle sin salida. Estructura ITERAR (LOOP) En esta estructura se repiten alternativamente dos acciones, evaluando la condicin de salida entre ambas. El nmero de repeticiones oscila, por la accin A, entre 1 e infinito, y para la accin B, entre 0 e infinito, cumplindose que siempre se repite A una vez ms que B. Los bucles anteriores son casos particulares de ste. 6. PREGUNTA 4

10

Ventajas de la programacin estructurada

Los programas son ms fciles de entender, pueden ser ledos de forma secuencial y no hay necesidad de hacer engorrosos seguimientos en saltos de lneas (GOTO) dentro de los bloques de cdigo para intentar entender la lgica. La estructura de los programas es clara, puesto que las instrucciones estn ms ligadas o relacionadas entre s. Reduccin del esfuerzo en las pruebas y depuracin. El seguimiento de los fallos o errores del programa ("debugging") se facilita debido a su estructura ms sencilla y comprensible, por lo que los errores se pueden detectar y corregir ms fcilmente. Reduccin de los costos de mantenimiento. Anlogamente a la depuracin, durante la fase de mantenimiento, modificar o extender los programas resulta ms fcil. Los programas son ms sencillos y ms rpidos de confeccionar. Se incrementa el rendimiento de los programadores, comparado con la forma anterior que utiliza GOTO.

11

7. PREGUNTA 5. 6.
Actualmente se estn produciendo cambios de gran alcance en la forma en que se desarrolla el "software" para los equipos informticos. Entre las causas de estos cambios se incluyen las siguientes:

El coste creciente de los desarrollos La insatisfaccin de los usuarios con la adecuacin y calidad La complejidad y tamao creciente de los programas La creciente dependencia de muchas organizaciones de sus sistemas informticos, sin posibilidad de abandonarlos El avance hacia los ordenadores de quinta generacin con caractersticas "software" muy diferentes de los actuales.

Estas y otras presiones estn provocando una reorganizacin de los mtodos empleados en el desarrollo de los programas para los ordenadores. Lo que se necesita son tcnicas para la elaboracin de productos software muy largos y complejos, que satisfagan estndares muy estrictos de calidad y prestaciones, de acuerdo con una planificacin, control y presupuestos adecuados. Los mtodos de trabajo que se han desarrollado para responder a estas necesidades constituyen lo que se ha dado en llamar "Ingeniera del Software". La Ingeniera del Software es una tarea de equipo, al comenzar un proyecto de desarrollo, se constituyen una serie de equipos con una estructura paralela a la del programa en s. Se establece un calendario para el proyecto y se asignan costes a cada una de las partes y etapas del proyecto. Cada equipo tiene un responsable, cuya tarea es la de comprobar que la programacin desarrollada por el equipo sea correcta, est estructurado con propiedad, dispone de las interfaces para conectar con los programas desarrolladas por otros equipos y se desarrolla de acuerdo a las previsiones de tiempo y coste.

La Ingeniera del Software se ocupa del ciclo de vida completo de un producto software, diseo, desarrollo, uso y mantenimiento. El trabajo se hace buscando el

12

mayor grado posible de estandarizacin y los menores costes durante la totalidad del ciclo de vida de los programas.

La Ingeniera del Software implica que un programa bien estructurado satisfaga las siguientes condiciones:

El programa ha de tener una estructura general en forma de mdulos, que a su vez estarn formados por procedimientos o segmentos. Debe existir un interfaz claramente definido entre los diversos mdulos Cada mdulo debe de ser una combinacin sencilla de construcciones elementales de un lenguaje de programacin Debe existir una fuerte correspondencia entre la estructura de los mdulos y la de los datos sobre los que operan Cada mdulo debe dejar las estructuras de datos sobre las que opera en un estado consistente con su definicin Un mdulo no debe tener efectos secundarios

Por lo que respecta a las tcnicas de diseo de programas, el mtodo ms simple y uno de los ms populares es el conocido como de "Refinamiento Progresivo". Se fundamenta en el uso de algoritmos que se escriben en un lenguaje intermedio entre el castellano y un lenguaje de programacin como el Pascal, este lenguaje se denomina seudocdigo. El proceso se puede describir en trminos de un lenguaje de esta naturaleza:

Establecer todos los pasos del programa en un algoritmo breve de alto nivel Repetir: Expandir cada sentencia del algoritmo en detalle, especificando los pasos necesarios Hasta que las tareas hayan sido especificadas con el detalle suficiente como para que pueda generarse el cdigo del programa.

Existen otras metodologas ms depuradas como por ejemplo la conocida como "Descomposicin Funcional". A diferencia de la anterior en cada etapa se especifican las propiedades esenciales de las estructuras de datos, y cada algoritmo se expresa como una funcin matemtica que transforma esta estructura de datos.

Una vez desarrollado un programa como es lgico se ha de comprobar su buen funcionamiento. Actualmente en la mayora de los casos se prueban con cualquier tipo de datos que pueden presentarse en la realidad. Sin embargo este proceso

13

nunca puede establecer si un programa es o no correcto, sin importar cuantos conjuntos de datos de usen. Si un programa es de importancia crtica, como ocurre en el presente con muchas aplicaciones comerciales, industriales o militares, es necesario tomar todas las precauciones posibles para asegurar que estn libres de errores. Se estn empezando a utilizar tcnicas para asegurar que los mdulos (y los algoritmos) son correctos, que los consideran como teoremas matemticos y entonces se emplean los mismos mtodos que se utilizan para demostrar los teoremas. Esta tarea es muy compleja y no siempre aplicable.

14

8. CONCLUCIONES.
Se concluye que la evolucion de los diversos campos de la programacion, cada vez ha tenido mas fuerza ya que, algunos lenguajes se complementan de lo otros, cuyo fin proposito es facilitar la revision de algun programa, basados en 3 estructuras basicas.

15

9. BIBLIOGRAFIA.
Informatica aplicada (2005) lenguajes de programacion, crative commons. Disponible en: http://www.um.es/docencia/barzana/IATS/Iats06.html Polilibro, (2000), Programacion estructurada. mexico. Disponible en:http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_terminados/Polilibro FC/Unidad_III/Unidad%20III_8.htm

16