Mod 1 introducción a la programación

03-23-05
Universidad Andrés Bello
Facultad de Ingeniería
Introducción a la
programación

PEMO-2015
Lenguajes de programación
Definición
Fuente: Definición de la Encyclopedia of Computer Science
Definición de Abelson y Sussman

PEMO-2015
Definición
Un lenguaje de programación es un idioma artificial diseñado
para ser entendido por por máquinas como las computadoras.
Pueden usarse para crear programas que controlen el
comportamiento físico y lógico de una máquina, para expresar
algoritmos con precisión, o como modo de comunicación
humana.
Está formado por un conjunto de símbolos y reglas sintácticas
y semánticas que definen su estructura y el significado de sus
elementos y expresiones.
Al proceso por el cual se escribe, se prueba, se depura, se
compila y se mantiene el código fuente de un programa
informático se le llama programación

PEMO-2015
Definición
Aspectos que provocan la evolución de los
Lenguajes de Programación
• Nuevas tecnologías, microprocesadores integrados
• Recursos y tipos de ordenadores
• Aplicaciones y necesidades de los usuarios
• Nuevos métodos de programación
• Estudios teóricos
• Estandarización

PEMO-2015
Por qué estudiar lenguajes de programación
• Mejora el uso del lenguaje de programación
• Aumenta y mejora el vocabulario de los elementos de
programación
• Permite una mejor elección del lenguaje de programación
• Mejora la habilidad para desarrollar programas efectivos y
eficientes
• Facilita el aprendizaje de un nuevo lenguaje de
programación
• Facilita el diseño de nuevos lenguajes de programación

PEMO-2015
Características de los lenguajes de programación
• Define un proceso que se ejecuta en un computador
• Es de alto nivel, cercano a los problemas que se quieren
resolver (abstracción)
• Permite construir nuevas abstracciones que se adapten al
dominio que se programa
• Los lenguajes deben ser independientes de la máquina o sea
una sentencia no depende del diseño de hardware de una
computadora en particular.

PEMO-2015
Tipos

PEMO-2015
Introducción

PEMO-2015
Elementos de los lenguajes de programación
Para Abelson y Sussman, todos los lenguajes de
programación permiten combinar ideas simples en
ideas más complejas mediante los siguientes tres
mecanismos
• Expresiones primitivas que representan las entidades
más simples del lenguaje
• Mecanismos de combinación con los que se
construyen elementos compuestos a partir de
elementos más simples
• Mecanismos de abstracción con los que dar nombre
a los elementos compuestos y manipularlos como
unidades

PEMO-2015
• El concepto abstracción está vinculado al verbo Abstraer (separar
las propiedades de un objeto a través de una operación mental,
dejar de prestar atención al mundo sensible para centrarse en un
pensamiento). La abstracción, por lo tanto, es alguna de
estas acciones o sus efectos.
• La abstracción en informática se refiere a aislar un elemento de su
contexto o del resto de los elementos que lo acompañan, entonces
una capa de abstracción, es la manera de ocultar los detalles de
implementación de ciertas funcionalidades.
• Una misión fundamental de los lenguajes de programación es
proporcionar herramientas que sirvan para construir abstracciones
• Abstracciones: sirven para tratar la complejidad del mundo real
• Existen abstracciones propias de la computación: listas, árboles,
grafos, tablas hash...

PEMO-2015
• En resumen, la abstracción es la herramienta/habilidad
fundamental de los informáticos.
• En palabras simples es la capacidad de obtener los datos
fundamentales de los objetos o elementos.
• Ejemplos:
• Alumno: Matrícula, Nombre, Apellido, edad, Rut, etc.
• Producto: Código, Nombre, descripción, fabricante, etc.

PEMO-2015
Traductores
Un traductor es cualquier programa que toma como entrada
un texto escrito en un lenguaje, llamado fuente y da como
salida otro texto en un lenguaje, denominado objeto. Todos se
basan en los "meta-programas" (compiladores, intérpretes,
etc.) cuyos datos de entrada son el código fuente de otros
programas.
Existen distintos tipos de traductores, entre ellos destacan:
• Compiladores
• Ensambladores
• Preprocesadores
• Intérpretes
TraductorTexto lenguaje
fuente
Texto lenguaje
objeto

PEMO-2015
Traductores de Lenguajes
Compilador
• El compilador es un traductor que tranforma un lenguaje de
origen (código desarrollado por el programador) en un
lenguajes objetivos que la mayoría de las veces es lenguaje
de máquina, es decir, un programa que ha sido compilado
puede correr por si sólo sobre una máquina.
• Como una parte fundamental de este proceso de traducción,
el compilador le hace notar al usuario la presencia de errores
en el código fuente del programa.
• Los compiladores requieren de un tiempo antes de poder
generar un ejecutable, sin embargo los programas creados
con compiladores se ejecutan mucho más rápido que un
mismo programa ejecutado con un intérprete.
• Existen múltiples compiladores para un mismo lenguaje. Por
ejemplo lenguaje C tiene un compilador para PC, otro para
Apple Macintosh.

PEMO-2015
Ensamblador
• Se refiere a un tipo de programa que se encarga de traducir
un archivo fuente escrito en un lenguaje ensamblador, a
un archivo objeto que contiene código máquina, ejecutable
directamente por la máquina para la que se ha generado.
• El propósito para el que se crearon este tipo de aplicaciones
es la de facilitar la escritura de programas, ya que escribir
directamente en código binario, que es el único código
entendible por la computadora, es en la práctica imposible.
• La evolución de los lenguajes de programación a partir del
lenguaje ensamblador originó también la evolución de este
programa ensamblador hacia lo que se conoce como
programa compilador.

PEMO-2015
Interprete
• Los intérpretes realizan la traducción y ejecución de forma
simultanea, es decir, un intérprete lee el código fuente y lo
va ejecutando al mismo tiempo.
• Se pueden utilizar como alternativa a los compiladores para
traducir lenguajes de alto nivel.
• No se graba el código objeto para utilizarlo posteriormente.
La siguiente vez que se utilice una instrucción, se le debe
interpretar otra vez y traducir a lenguaje máquina.
• En general, se puede decir que un lenguaje es interpretado
si sus instrucciones se ejecutan secuencialmente a partir de
código fuente. Para ejecutar el código de un lenguaje
interpretado, necesitamos un intérprete de ese lenguaje.
El intérprete irá recibiendo líneas de código que traducirá a
lenguaje máquina para que se ejecute.

PEMO-2015
Diferencia entre compilador e interprete
• Un programa compilado puede correr por si solo, pues en
el proceso de compilación se lo transformo en otro lenguaje
(lenguaje máquina).
• Un intérprete traduce el programa cuando lo lee,
convirtiendo el código del programa directamente en
acciones.
• La ventaja del intérprete es que se puede interpretar en
cualquier plataforma (S.O.), en cambio el archivo generado
por el compilador solo funciona en la plataforma en donde
se lo ha creado.
• Un archivo compilado puede ser distribuido fácilmente
conociendo la plataforma, mientras que un archivo
interpretado no funciona si no se tiene el intérprete.
• La velocidad de ejecución un archivo compilado es de 10
a 20 veces más rápido que un archivo interpretado.

PEMO-2015
Programas compilados
• Ejemplos: C, C++
• Diferentes momentos en la vida de un programa:
tiempo de compilación y tiempo de ejecución
• Mayor eficiencia

PEMO-2015
Programas interpretados
• Ejemplos: BASIC, LISP, Scheme, Python, Ruby
• No hay diferencia entre el tiempo de compilación y el
tiempo de ejecución
• Mayor flexibilidad: el código se puede construir y
ejecutar "on the fly" (funciones lambda o clousures)

PEMO-2015
Ejecutados sobre máquina virtual
• Ejemplos: Ejemplos: Java, Scala

PEMO-2015
Evolución del software
Introducción

PEMO-2015
• En los primeros años de la era de la computadora, el
software se consideraba como un añadido.
• El desarrollo del software se realizaba virtualmente sin
ninguna planificación.
• Los programadores trataban de hacer las cosas bien, y con
un esfuerzo heroico, a menudo salían con éxito.
• El software se diseñaba a medida para cada aplicación.
• La mayoría del software se desarrollaba y era utilizado por
la misma persona u organización
• La misma persona lo escribía, lo ejecutaba y, si fallaba, lo
depuraba.
• Técnicas de gestión orientadas a hardware.
Primera era

PEMO-2015
• La multiprogramación y los sistemas multiusuario
introdujeron nuevos conceptos de interacción hombre –
maquina.
• Establecimiento del software como producto, llegada de
las "casas del software".
• Extensión de las bibliotecas de software de computadora
• Desarrollo de proyectos con decenas de miles de sentencia
fuente.
• Los programas debían ser adaptados a los nuevos
dispositivos de hardware adquiridos.
Segunda era

PEMO-2015
• Llegada y amplio uso de los microprocesadores.
• Sistemas distribuidos, múltiples computadoras, ejecutando
funciones concurrente.
• Redes de área local y de área global
• Comunicaciones digitales de alto ancho de banda y la
creciente demanda de acceso "instantáneo" a los datos,
supusieron una fuerte presión sobre los desarrolladores del
software.
Tercera era

PEMO-2015
• La industria del software es la cuna de la economía del
mundo.
• Las técnicas de la cuarta generación para el desarrollo del
software
• Las tecnologías orientadas a objetos están desplazando
rápidamente los enfoques de desarrollo de software más
convencionales en muchas áreas de aplicaciones.
• Nuevos modelos aplicados al desarrollo de software.
Cuarta era

PEMO-2015
Ciclo de vida del software
El ciclo de vida del software incluye todas las tareas a realizar
desde que se concibe un programa hasta que se deja de
utilizar (no sólo “hasta que se codifica” ni “hasta que se
instala”)
Ref: Modelo secuencial
Análisis
Diseño
Implementación
Pruebas
Mantenimiento

PEMO-2015
En palabras sencillas
Análisis
Diseño
Implementación
Pruebas
Mantenimiento
“Quiero 3 habitaciones,
2 baños, garaje...”
Planos, diseño circuito
eléctrico y de agua...
Se construye la casa
Se comprueba la solidez de la
estructura, el funcionamiento de
las instalaciones, el acabado...
Algunas reparaciones, se cierra
la terraza, se instala aire
acondicionado...
Casa
¿Qué tiene que hacer
exactamente nuestro
programa?
¿Cómo vamos a organizar
el programa? ¿Qué partes
tendrá y cómo funcionará?
Se construye el software
Ponemos a prueba nuestro
programa, incluso en
situaciones límite
Pequeñas modificaciones o
correcciones (parches),
actualizaciones, etc...
Software

PEMO-2015
Actividad en la que se analizan y clarifican los diferentes
aspectos del problema que debe ser resuelto por la
aplicación, con el fin de establecer claramente qué debe ser
construido
El resultado es, normalmente, un documento de requisitos
software que especifica claramente las funcionalidades de la
aplicación
Análisis

PEMO-2015
• Actividad en la que se decide la organización y la
estructura de una aplicación que satisfaga los diferentes
requisitos establecidos en la fase de análisis
• El resultado es uno (o varios) documentos de diseño que
especifican claramente cómo construir la aplicación
• Mientras que el análisis se ocupa de qué hay que hacer, el
diseño se ocupa de cómo hacerlo
• Hay varias técnicas de diseño, en la actualidad se utiliza
UML a través de algunos de los diagramas propuestos
Diseño

PEMO-2015
• Actividad en la que se construye (codifica) la aplicación
utilizando un lenguaje de programación concreto, y
siguiendo, las directrices marcadas por los documentos de
diseño
• Si las actividades anteriores han sido realizadas
correctamente, la fase de implementación debería ser
bastante trivial
• La implementación se encarga de concretar el diseño
teniendo en cuenta un lenguaje y herramienta de
desarrollo concreta
Implementación

PEMO-2015
• Actividad en la que se asegura que la aplicación construida
satisface los requisitos del usuario
• Se debe invertir mucho tiempo en hacer pruebas (mucho
más que en su implementación!)
• Dos pasos diferenciados
• Verificación: ¿Se ajusta la aplicación construida a los requisitos
establecidos?
• Validación: ¿Resuelve la aplicación el problema que realmente tenía
el usuario?
Pruebas

PEMO-2015
Actividad en la que la aplicación se modifica para satisfacer
cambios o ampliaciones en los requisitos del usuario, corregir
errores, etc.
Es la actividad más costosa en el desarrollo de software
(Consisderar que hay programas que están muchos años en
funcionamiento y lo usan miles de personas)
Estos costes pueden aliviarse si se hacen bien todo lo
anterior
Mantenimiento

PEMO-2015
En 1970 Winston Royce definió flujos de retorno sobre el modelo
secuencial, acuñando así el modelo en cascada.
Refleja la necesidad real de retornar desde una fase hacia las
anteriores con la información generada al avanzar el desarrollo.
Un representaciones permite retorno posible entre una fase y la
anterior, el otra permite el retorno en cualquier fase para modificar
cualquiera de las anteriores.
Reconoce la importancia de disponer de los requisitos y diseño
antes de comenzar con la codificación del sistema, lo anterior puede
actuar como una barrera que bloquee el comienzo de la siguiente
fase.
Se puede caer en la tentación de comenzar con el diseño o incluso
con la codificación, sin tener un conocimiento suficiente de los
requisitos.
Resulta apropiado para:
Desarrollar nuevas versiones de sistemas legados en los que el
desconocimiento de las necesidades de los usuarios, o del
entorno de operación no plantean riesgos.
Sistemas pequeños, sin previsión de evolución a corto plazo.
Modelo en cascada
Introducción

PEMO-2015
• Muy utilizado para adaptaciones o mejoras de sistemas
existentes.
• Útil cuando los requisitos están fijos.
• Es raro que los proyectos reales sigan el flujo secuencial.
• Es difícil que el cliente sepa de manera explícita todos los
requisitos de manera explícita.
• El cliente debe tener paciencia.
• Es inflexible y no motiva al cambio.
• Poco apropiado para aplicaciones para la toma de
decisiones.
• Los usuarios tienen una participación limitada.
Modelo en cascada
Introducción

PEMO-2015
Actividad en la que la aplicación se modifica para satisfacer
cambios o ampliaciones en los requisitos del usuario, corregir
errores, etc.
Es la actividad más costosa en el desarrollo de software
(Consisderar que hay programas que están muchos años en
funcionamiento y lo usan miles de personas)
Estos costes pueden aliviarse si se hacen bien todo lo
anterior
Modelo en cascada
Introducción

PEMO-2015
Metodologías de desarrollo de software
Consideraciones para aplicar un ciclo de vida
Al iniciar el proyecto, el responsable de la arquitectura debe
considerar aspectos como:
Posibilidad de descomposición del sistema en subsistemas de
software, con agendas y entregas diferenciadas.
Estabilidad esperada de los requisitos.
Novedad del proceso o procesos gestionados por el sistema en
el entorno del cliente.
Criticidad de las agendas y presupuestos.
Grado de complejidad del interfaz de operación, criticidad de la
usabilidad.
Grado de conocimiento y familiaridad con el entorno de
desarrollo, componentes externos empleados, etc.

PEMO-2015
Que Modelo a utilizar
Proyecto de software
Un proyecto es una organización transitoria de individuos
dedicados a alcanzar un objetivo especifico dentro de un
periodo de tiempo, un presupuesto, y un objetivo técnico.
Un proyecto:
• Tiene un principio y un fin.
• Debe de tener un objetivo (debe de ser medible).
• Requiere de un líder y de un equipo.

PEMO-2015
Que modelo usamos
• Dado que cada proyecto es único, no existe un modelo que
se aplique al 100% a todos los proyectos de una
organización.
• Una organización puede contar con uno o más modelos de
desarrollo para ser utilizados dependiendo del tipo de
proyecto.
• El modelo seleccionado tendrá influencia en el éxito del
proyecto y en el tipo de decisiones que se deberán hacer.

PEMO-2015
Como sabremos cual es el más adecuado
Para seleccionar el modelo a adoptar habrá que
hacerse una serie de cuestionamientos:
– ¿Qué tantos son los riesgos del proyecto?
– ¿Qué tan claros están los requerimientos?
– ¿Se conoce bien la tecnología ha utilizar?
– ¿Visibilidad que requiere el proyecto?
– ¿Qué tanta planeación hacia adelante es requerida?
– ¿Qué restricciones se tienen?

PEMO-2015
Criterios de éxito
• Contar con un modelo debidamente documentado. (entradas,
salidas, entregables, aprobaciones)
• Los documentos deben de estar actualizados.
• La gente que participa en el proyecto debe estar capacitada en su
uso.
• Se debe de reforzar el uso del modelo mediante auditorias y
revisiones.
• La alta gerencia debe soportar la utilización de un modelo.
• Cualquier desviación al modelo debe ser documentada y aprobada.
• Se debe de medir la eficiencia del modelo.
• Retroalimentar y ajustar.

PEMO-2015
Lecciones aprendidas por el profesor
• No existe una formula que indique cual es el modelo más
adecuado, Ud. debe ser capaz de definir el más apropiado, de
acuerdo al proyecto. Ningún proyecto es igual a otro.
• Un modelo no plantea un solución única, complementar modelos
puede ser la mejor solución.

PEMO-2015
• Se refiere a la dificultad en escribir programas, libres de
defectos, fácilmente comprensibles, y que sean
verificables.
• Las causas son, la complejidad que supone la tarea de
programar, y los cambios a los que se tiene que ver
sometido un programa para ser continuamente adaptado a
las necesidades de los usuarios.
Crisis del software
Interrogantes del software

PEMO-2015
• La complejidad que supone la tarea de programar
• Inexistencia de herramientas de estimación para
determinar el esfuerzo desarrollar un programa.
• Los proyectos no terminaban en plazo.
• Los proyectos no se ajustaban al presupuesto inicial
• Baja calidad del software generado.
• Software que no cumplía las especificaciones.
• Código inmantenible que dificultaba la gestión y
evolución del proyecto
Crisis del software
Qué generó la crisis del software

PEMO-2015
Crisis del software
Qué generó la crisis del software

PEMO-2015
Crisis del software
Algunos indicadores
Fuente: Apuntes Ingeniería del Software de Gestión. “Tema 1: Software e Ingeniería del Software”

PEMO-2015
• Las personas disponen de las herramientas de desarrollo más
avanzadas, después de todo, les compramos las computadoras
más modernas.
• Si fallamos en la planificación, podemos añadir más programadores y
adelantar el tiempo perdido.
• Una declaración general de los objetivos es suficiente para comenzar
a escribir los programas.
• Los requisitos del proyecto cambian continuamente, pero los
cambios pueden acomodarse fácilmente, ya que el software es
flexible.
• Una vez que escribimos el programa y hacemos que funcione,
nuestro trabajo ha terminado.
• Lo único que se entrega al terminar el proyecto es el programa
funcionando.
• Hasta que no tengo el programa «ejecutándose », realmente no
tengo forma de comprobar su calidad.
Mitos del software

Mod 1 introducción a la programación

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Mod 1 introducción a la programación

Similar a Mod 1 introducción a la programación (20)

Más de Pedro Montecinos Gaete

Más de Pedro Montecinos Gaete (8)

Último

Último (20)

Mod 1 introducción a la programación