PARADIGMAS Y LENGUAJES DE PROGRAMACION

MATERIA:

PARADIGMAS Y LENGUAJES DE

PROGRAMACIÓN

TEMA:

INTRODUCCION DE PARADIGMAS

CATEDRÁTICO:

LIC. MIGUEL ÁNGEL CHAN CABRERA

NOMBRE DEL ALUMNO:

ING. BALDEMAR FLORES JIMÉNEZ

CARRERA:

ING. EN SISTEMA COMPUTACIONALES

CUATRIMESTRE:

II

PALENQUE CHIAPAS A 15 DE MARZO 2014

Ambiente de referencia.

Cada programa o subprograma tiene un conjunto de asociaciones de identificador disponibles para su uso al hacer referencias durante su ejecución. Este conjun¬to de asociaciones de identificador se conoce como el ambiente de referencia del subprograma (o programa). El ambiente de referencia de un subprograma es ordinariamente invariable durante su ejecución. Se establece cuando se crea la activación del subprograma, y permanece 5111 cambio durante el tiempo de vida de la activación. Los valores contenidos en los diversos objetos de datos pueden cambiar, pero no así las asociaciones de nombres con objetos de datos y subprogramas. El ambiente de referencia de un subprograma puede tener varios componentes:

1. Ambiente local de referencia (o simplemente ambiente local). El conjunto de asociaciones creadas al entrar a un subprograma y que representan parámetros formales, variables locales y subprogramas definidos sólo dentro de ese subprograma conforma el ambiente local de referencia de esa activación del subprograma. El significado de una referencia a un nombre en el ambiente local se puede determinar sin salir de la activación del subprograma.

2. Ambiente no local de referencia. El conjunto de asociaciones para identificadores que se pueden usar dentro de un subprograma pero que no se crean al entrar a él se conoce como el ambiente no local de referencia del subprograma.

3. Ambiente global de referencia. Si las asociaciones creadas al inicio de la ejecución del programa principal están disponibles para usarse en un subprograma entonces estas asociaciones forman el ambiente global de referencia de ese subprograma. El ambiente global es parte del ambiente no local.

4. Ambiente predefinido de referencia. Ciertos identificadores tienen una asociación predefinida, la cual se define directamente en la definición del lenguaje. Cualquier programa o subprograma puede usar estas asociaciones sin crearlas en forma explícita.

Visibilidad. Se dice que una asociación para un identificador es visible dentro de un subprograma si es parte del ambiente de referencia para ese subprograma.

Una asociación que existe pero no forma parte del ambiente de referencia del subprograma actualmente en ejecución se dice que está oculta de ese subprograma. Con frecuencia una asociación está oculta cuando se entra a un subprograma que redefine un identificador que ya está en uso en otra parte del programa.

Alcance dinámico. Cada asociación tiene un alcance dinámico, el cual es la parte de la ejecución del programa durante la que esa asociación existe como parte de un ambiente de referencia.

Así, el alcance dinámico de una asociación se compone del conjunto de activaciones de subprograma dentro de las cuales es visible.

Operaciones de referencia. Una operación de referencia es una operación con la signatura:

Ref_op : id x ambiente_de_ referencia ! objeto de datos o subprograma

donde ref_op, dado un identificador y un ambiente de referencia, encuentra la asociación apropiada para ese identificador en el ambiente y regresa el objeto de datos o la definición de subprograma asociada.

Referencias locales, no locales y globales. Una referencia a un identificador es una referencia local si la operación de referencia encuentra la asociación en el ambiente local: es Lina referencia no local o global si la asociación se encuentra en el ambiente no local o global,respectivamente. (Los términos no local y global se suelen usar de manera indistinta para indicar cualquier referencia que no es local.)

Ambiente de programación es el entorno en el que un programador desarrolla sus aplicaciones.

Claro, entendiendo por entorno el que puedes ver en tu monitor...

Hay dos ambientes reconocidos...

La programación en ambiente visual (donde manipulas los objetos y generas conexiones como el caso de velneo) y la programación en ambiente código (donde genera las instrucciones de programación a base de ir escribiendo y compilando como VBasic, c/c++ etc.)...

Ambos son regulares y muchos lenguajes los emplean los dos...

Modelos de Implementación

Este documento trata de la etapa de implementación del desarrollo del ciclo de vida y en particular de la creación de código fuente para implementar un sistema.

Claramente el código fuente que se escribe para implementar un sistema tiene que basarse en los modelos generados en las etapas previas del desarrollo de software, especialmente del diseño de diagramas de clase, de secuencia y de estados. La creación de código puede ser informada simplemente por estos modelos o basada en su transformación (o la de alguno de ellos) en fragmentos de código. Esta clase presenta una forma de transformar diagramas de diseño de clases UML en código C++.

La lección comienza discutiendo la distancia (gap) entre el diseño y los editores de UML. Luego se centra en los fragmentos de código que pueden ser generados por varias clases de elementos del modelo que pueden encontrarse en un diagrama de clases UML incluyendo:

 clases,

 relaciones de generalización,

 relaciones de delegación,

 atributos,

 asociaciones, y

 operaciones.

Los modelos generados durante la etapa de diseño del desarrollo de software especifican las relaciones y comportamiento de las clases individuales de un sistema hasta cierto punto y cierta formalidad, pero no con un nivel de detalle ni con una notación que pudiera ser usada directamente como su implementación. Para crear un ejecutable todavía necesitamos escribir el código fuente del sistema. Para este fin existen herramientas que pueden utilizarse de apoyo e incluso automatizar partes de la actividad de generación de código (ej. Compiladores, depuradores, generadores de código).

A continuación describiremos el uso de una de estas herramientas: el generador de código de C++ de Rose. Rose actualmente viene con dos generadores de código, uno que genera código C++ a partir del diseño del diagrama de clases y otro que genera código Java. Nuestra discusión cubrirá solamente el generador de código C++.

El generador de código C++ de Rose produce código fuente C++ a partir de la información contenida en un modelo de Rose. El código generado para cada componente del modelo se determina por la especificación del componente en el modelo y las propiedades de la generación de código que pueden ser especificadas para el componente individual o ser aplicadas al modelo como un todo (el último puede denominarse propiedades del proyecto). Estas propiedades especifican una información de lenguaje específico requerido para fijar un componente UML en un fragmento de código C++ y permiten al programador controlar el código generado para cada uno de los componentes.

A continuación vamos a presentar los patrones de código generados por los diferentes tipos de componentes que pueden encontrarse en un diagrama de clases.

Para cada clase UML, el generador de código C++ produce los siguientes fragmentos de código:

 una clase C++ que implementa la clase UML tiene el mismo nombre que ella

 comentarios extraidos del formulario de especificación de la clase UML

 un constructor de clase

 un destructor de clase

Si la clase UML es una clase abstracta, es decir una clase que no tiene instancias directas, la clase C++ que se crea para su implementación se declara como una clase abstracta mediante un constructor virtual puro.

Si la clase UML es una clase “hoja” (una clase que no tiene subclases) no podemos especificarlo en la clase C++. Se podría implementar un analizador sintáctico que comprobara que la clase no tiene subclases. En UML una clase hoja se representa poniendo la cadena “leaf” entre corchetes bajo el nombre de la clase.

Si la clase UML ha sido estereotipada como una clase interface entonces heredaremos de una clase que defina la interfaz (con métodos virtuales puros).

Si la clase UML pertenece a una serie de paquetes anidados entonces dentro de un fichero de cabecera se incluirá las sentencias #include que definan la jerarquía de paquetes que contiene la clase creada.

Como se muestra en la transparencia de arriba, el generador de código C++ produce una clase C++ llamada LibraryItem para implementar la clase UML LibraryItem.

El contenido del campo de documentación del formulario de especificación de la clase UML se transforma en un comentario

...