universidad autonoma metropolitana …148.206.53.84/tesiuami/uam3631.pdf · ... construir su...

UNIVERSIDAD AUTONOMA METROPOLITANA Unidad lztapalapa

REPORTE DE PROYECTO TERMINAL DE LA LIC. INGENIERíA ELECTR6NICA

CON AREA DE CONCENTRAClbN EN COMPUTACI~N

“Estudio para el desarrollo de un sistema de adquisici6n, control y andlisis automdtico de datos

experimentales”

Elaboró: Maribel Pelcastre Cruz 91 31 9701 Alvaro Ávila Marquez

Asesor: Alejandro Martinez González Profesor del Area de Sistemas Digitales

Abril de 1997

UNIVERSIDAD AUTONOMA METROPOLITANA Unidad lztapalapa

Elaboró:

Ing. Alejandro Martínez GonAlez Asesor

Estudio para el desarrollo de un sistema de adquisición, control y análisis automática de datos experimentales

Contenido Temático

Contenido Temático

Tabla de figuras y listados

Capítulo I

Planteamiento del problema Objetivo de la primera etapa

Capitulo 2

Especificaciones del problema Descripción de las funciones de las tarjetas Diagrama de contexto

Definición de elementos los relevantes del diagrama de contexto ¿Qué es el esquema de comportamiento?

Clasificación de las señales de control Diagrama de flujo de datos

Definición de los elementos d e l diagrama de flujo de datos 1) Agentes Externos 2) Flujos De Datos 3) Procesos

¿Para dónde vamos?

Capitulo 3

Tecnología Orientada a Objetos ¿,Qué es la tecnología orientada a objetos?

Topología de los lenguajes de programación orientados y basados en objetos Fundamentos del modelo de objetos

Programación orientada a objetos Diseño orientado a objetos Análisis orientado a objetos

Capítulo 4

Elementos del modelo orientado a objetos Paradigmas de programación Elementos del modelo orientado a objetos

Abstracción Encapsulado Modularidad

1

3

4

4 5

6

6 6 6 7 8

10 10 10 10 12 14 15

16

16 16 17 18 18 19 19

21

21 21 22 23 26 29

Páglna 1

Estudio para el desarrollo de un sistema de adquisición, control y andlisis automático de datos experimentales

Jerarquía Herencia simple Herencia múltiple

Tipeado Concurrencia Persistencia

Capítulo 5

Premisas de diseño en el modelo orientado a objetos Remisas referentes a clases y objetos. Remisas de clasificación (creación e identificación de clases) Premisas de notación Premisas del proceso de análisis y diseño de sistemas orientados a objetos

Capítulo 6

¿Qué herramienta vamos a utilizar?

Capítulo 7

Los componentes fundamentales de Delphi ¿Qué son los proyectos?

Los projects de Delphi La palabra reservada program La declaración Uses La directiva $R App1ication.Create.Form Applicati0n.Rt.m

Librerías de Delphi Las unidades de Delphi

Sección Interface Sección Implementation Sección Initialization

Las formas de Delphi Los módulos de datos en Delphi Archivos include Los componentes de Delptu

Capitulo 8

Conclusiones

Bibliografía

Indice alfabético

32 33 35 36 38 40

42

42 42 43 44 45

48

48

50

50 50 51 52 52 52 53 53 53 54 55 55 56 56 56 57 57

58

58

61

63

Pdgina 2

Estudio para el desarrollo de un sistema de adquisición, control y anilisis automático de datos experimentales

Tabla de figuras y listados

Figura 1. Diagrama de contexto del problema 7 Figura 2. Conjunto de operadores básicos que sirven para construir señales de control. 9 Figura 3. Dagrama de Flujo de Datos. 11 Figura 4. Topologia de una aplicación orientada a objetos. 18 Figura 5. Una abstracción enfoca las característicasprincipales de un objeto desde el

punto de vista del observador. 23 Figura 6. El encapsulado oculta los detalles de la implementación de un objeto. 27 Figura 7. La modularidad empaca las abstracciones en unidades discretas. 30 Figura 8. Las abstracciones se clasijican mediante las jerarquías. 35 Figura 9 Las estructuras con fuerte tipeado, previenen la mezcla de abstracciones. -37 Figura 1 O. La concurrencia permite a diferentes objetos actuar al mismo tiempo. -39 Figura 11. La persistencia guarda el estado y clase de un objeto a través del tipo o el

espacio. 41 Listado 1. Archivo Project del sistema Invernadero 51 Listado 2. Ejemplo de una librería sencilla de Delphi. 54

Página 3

Estudio para el desarrollo de un sistema de adquisición, control y análisis automático de dabs experimentales

Capítulo 1

Planteamiento del problema

Dadas 2 tarjetas de adquisición de datos, una analógica y una digital se desea crear un algoritmo de control y monitoreo de una o más de las tarjetas mencionadas. Se pretende que este algoritmo sea la plataforma para desarrollar el software que lleve a cabo el monitoreo y control de experimentos, usando como medio las tarjetas, a través de una PC.

El objetivo principal es que el usuario de este software cuente con una herramienta capaz de controlar una amplia gama de experimentos únicamente definiendo un esquema de comportamiento específico para cada experimento.

La primera etapa consiste en realizar el análisis y planteamiento del problema, enfocándolo desde una perspectiva general y tratando de buscar una solución con la cual puedan resolverse una gran variedad de problemas de control.

La herramienta de desarrollo con la que se atacará el problema, también se definirá a lo largo del desarrollo del mismo. Dado que actualmente se cuenta con una gran variedad de ellas y la que al final se elija deberá contar con instrumentos potentes para poder manejar el hardware en forma eficiente, ya que el objetivo es en buena medida


hacer que la solución corra en una plataforma distribuida y utilice la capacidad nativa del ambiente de trabajo Windows para manejar sistemas concurrentes.

El problema puede ser divido en varias etapas, en primera instancia se identificaron dos, la primera de las cuales d e h e las necesidades del sistema así como la herramienta de desarrollo que se utilizará. En esta parte se deben desarrollar las habilidades para manejar y comprender la herramienta de desarrollo y establecer las políticas de desarrollo, para de este modo, pasar a la segunda fase, en la cual se lleva a cabo el desarrollo en sí del sistema. Esta segunda parte deberá ser gradual, y poco a poco ir refinándose hasta obtener un sistema consistente.

Objetivo de la primera etapa

Definir en forma clara las especificaciones y necesidades del sistema así como una forma de expresión que permita establecer el “esquema de comportamiento” de eQeriment0.r eqen$icos de tal forma que puedan ser interpretados por la computadora para que esta los mantenga dentro de dicho esquema.

El paso siguiente es desarrollar un software capaz de permitir al usuario, que desea controlar y/o estudiar un experimento, construir su esquema usando la forma de expresión anterior y posteriormente controlarlo con dicho esquema a través de las taqetas analógicas y/o digtales existentes.

Página 5

Estudio para el desarrollo de un sistema de adquisición, control y análisis automático de datos experimentales

Capítulo 2

Especificaciones del problema

Descripción de las funciones de las tarjetas

Dado el hardware con que se cuenta es posible:

Recibir señales asociadas a variables dentro de un experimento, mismas que pueden obtenerse mediante un transductor. (Medio para conocer el estado actual del experimento ).

Enviar señales de control que alteren variables del experimento por medio de transductores. (Medio para alterar el estado actual del experimento).

Diagrama de contexto

El siguiente diagrama, Figura 1, plantea el problema en un contexto general, en el se representan los principales flujos de datos entre los entes que componen el sistema.

Páglna 6

Estudio para el desarrollo de un sistema de adquisicion. control y análisis automAtico de datos experimentales

COMUNICACION

MEDIO AMBIENTE

Figura 1. Diagrama de contexto del problema

Definicidn de elementos los relevantes del diagrama de contexto

Esquema

Conjunto de reglas.

Pagina 7

Estudio para el desarrollo de un sistema de adquisición, control y análisis automhtico de datos experimentales

Esquema de Comportamiento del Sistema

Contiene las reglas que permiten emitir señales de control en base a la información que se recibe de las tarjetas.

Control

Señales de control que emite la PC hacia las tarjetas y estas hacia el experimento.

Información

Señales muestreadas que se reciben en la PC, a través de las tarjetas, desde el experimento.

¿Que es el esquema de comportamiento?

La parte más importante dentro del diagrama de contexto es el esquema de comportamiento, puesto que es aquí donde se definen las especificaciones del experimento.

Se proponen el siguiente par de reglas básicas de un esquema:

IF (condición o evento) THEN (acción) WHILE (condición) DO (acción)

A continuación se describe la interpretación de dichas características.

Condición

Resultado de la asociación de operadores y señales. En la

Figura 2 se presenta el conjunto de operadores básicos, a partir de ellos es posible construir una amplia gama de condiciones.

Evento

Situaciones externas al sistema o no previstas. (Transiciones de tiempo).

Acción

Modificación de los parámetros de una seña l de control en un instante dado o en un tiempo (f(t+b)).

Pdgina 8


OPERADORES ARITMETICOS

a b

OPERADORES LóGICOS

awb b

OPERADORES BlNARlOS

a - aANDb a w b ;.lb p a b -AND b a -NOT -

Figura 2. Conjunto de operadores básicos que sirven para construir señales de control.

Estos dos conceptos son básicos en el control de señales, y pueden combinarse para construir sentencias tan complejas como sea necesario. Pero de alguna manera tenemos que tomar en cuenta que en nuestro entorno de estudio estamos manejando dos tipos de señales:

Pdgina 9


Clasificaci6n de las seiiales de control

Los dos tipos de señales que debe soportan el sistema son:

Diagrama de flujo de datos

En este diagrama, Figura 3, se presenta el flujo de datos entre los procesos que se han definido en una primera propuesta, la numeración de cada proceso únicamente se utiliza para tener una referencia en los refinamientos posteriores, pero no tiene nada que ver con el orden en el tiempo en que estos se llevan a cabo.

Las elipses representan un proceso, los rectángulos cerrados indican los agentes externos al algoritmo, los semirectángulos indican almacenes de información, las flechas junto con las leyendas asociadas, representan los datos que fluyen entre procesos, agentes externos y almacenes.

Definición de los elementos del diagrama de flujo de datos

1 ) Agentes Externos

Tarjetas

Son todas las taqetas analógicas y digitales que maneja el software y que están conectadas al experimento.

PBgina 10

Estudio para el desarrollo de un sistema de adquisición, control y analisis automático de datos experimentales

\ Espeaflcaciones del esquema de cmpatamento del Esquema de Determinación

I u Acciones

Detenninadas

Acciones SdcitadaS Priorización de Instrucciones Acciones.

i it-

Es~eaficaaones de

Configuración

- 7 Datos de ConflguraUdn puertos.

4

Mmstas de !as seilales

TARJETAS Senales para PW de

J Datos Mueskeados

puertos .I

I Datos Muesb'eados ,

I 1

Figura 3. Diagrama de Flujo de Datos.

Usuario

Es la persona que administra el sistema en su totalidad, entendiendo sistema como: el experimento, el software de control y las taqetas anal6g;lcas y/o digitales.

Phgina 11


2) Flujos De Datos

Acciones determinadas

Son las acciones que se han obtenido del análisis de las reglas contenidas en el esquema en conjunto con los datos obtenidos del experimento.

Acciones priorizadas

Acciones expedidas para su ejecución inmediata y en el orden dado por el proceso de priorización.

Acciones solicitadas

Son acciones que han sido derivadas de una instrucción dada por el usuario.

Datos formateados

Son los datos muestreados y organizados de tal forma que puedan almacenarse en un archivo.

Datos muestreados

Son las muestras convertidas a un formato entendible por la computadora y separadas de acuerdo al “nombre” de la señal de la que provienen.

Datos ordenados en pantalla

Una visualización de los datos en pantalla conforme al conjunto de especificaciones dadas por el usuario.

Especificacih de formato de almacén y datos para ser almacenados

Descripción del tipo de organización que se hará sobre los datos muestreados y especificación de los nombres de las señales cuyas muestras serán almacenadas.

PBgina 12


Especificaciones de puertos

Descripción de los parámetros que caracterizan a un puerto (niveles de voltaje, frecuencia de muestro, etc.).

Especificaciones del entorno gráfico

Nombres de las señales a ser monitoreadas asociadas a una forma gráfica o alfanumérica de visualización.

Especificaciones del sistema de comportamiento

Descripción de la forma de actuar del experimento empleando la forma de expresión que haya sido definida para tal efecto, ya sea en forma gráfica o en un archivo de texto en forma de comandos.

Instrucciones directas

Es una petición del usuario para realizar una acción en el experimento que no ha sido contemplada en el esquema.

Muestras de las señales

Son los valores digitalizados de una señal externa analógica o valores binarios de una señal externa digital obtenidos en tiempos específicos.

Parámetros de un puerto

Son los datos necesarios que describen a un puerto para realizar el poleo sobre é1 y enviar las señales de control.

Reglas

Son los componentes básicos del esquema de comportamiento, cada una de ellas dispara una o más acciones asociadas a un evento o a una condición simple o compuesta (de condiciones más simples).

Señales de control

Respuestas del software hacia las tarjetas con el propósito de que el experimento realice las acciones priorizadas que han sido requeridas.

Psgina 13

Estudio pera el desarrollo de un sistema de adquisición, contml y analisis automático de datos experimentales

3) Procesos

Decodificación del esquema de comportamiento

Descompone el esquema de comportamiento en las reglas básicas que lo forman.

Determinación de acciones

A partir del análisis de las reglas y los datos muestreados determina en forma continua si se han dado las condiciones para disparar las acciones determinadas.

Interpretación de las instrucciones directas

Determina acciones a tomar en base a instrucciones directas dadas por el usuario.

Priorización de acciones

E n lo posible se establecerá un prioridad para ejecutar acciones y se buscará evitar inconsistencias en las mismas.

Organización de salida a pantalla

Dadas las especificaciones del usuario, controla el entorno gráfico de interface a la pantalla de la PC.

Ejecución de acciones

Recibe las acciones a ser ejecutadas y determina las señales de control necesarias para llevarlas a cabo.

Configuración de puertos

En base a las especificaciones para las señal asociada a un puerto, determina la forma en que el software manejará a dicho puerto (poleo, etc.).

Recepción de las muestras proporcionadas por las tarjetas

Recibe las muestras de las tarjetas poleando los puertos y l a s organiza en forma apropiada para ser enviadas a otros procesos (datos muestreados).

Página 14


Organizacidn de datos para ser almacenados

Se encarga de dar formato y clasificar los datos muestreados para mandarlos a un archivo.

Interpretación de las instrucciones directas

Determina acciones a tomar en base a las instrucciones directas dadas por el usuario.

¿Para dónde vamos?

Analizando la estructura del problema, parece lógco pensar que la solución puede obtenerse de una manera fácil utilizando herramientas orientadas a objetos. En los 3 capítulos siguientes se hace una breve introducción al modelo de programación orientado a objetos, comparándolo con otros tipos de modelos. En el capítulo 5 se establecen las premisas a tomar en cuenta al diseñar un sistema utilizando este modelo (orientado a objetos)' .

Sin oumplir con esas pranisas esteremos desarrollando con una herramienta orientada a objetos, pero sin u t i l i z a r la filosofía del modelo orientado a objetos, lo cual redundará m desperdicio de recursos.

Página I S


Capítulo 3

Tecnología Orientada a Objetos

¿Qué es la tecnología orientada a objetos?

La tecnología orientada a objetos es una fusión de elementos tecnológlcos. El modelo orientado a objetos est6 compuesto por los principios de abstracción, encapsulado, modularidad, jerarquía, tipeado (datos), concurrencia y persistencia. Por sí solos, ninguno de estos principios son nuevos. Lo más importante del modelo orientado a objetos es la forma que en estos elementos se unen para trabajar juntos y crear sinergia.

Un hecho evidente es que existe una diferencia abismal entre la programación orientada a objetos y la programación estructurada tradicional, y muchas ocasiones los programadores acostumbrados a esta última tendencia, suelen utilizar herramientas orientadas a objetos tendiendo a crear aplicaciones estructuradas. La programación orientada a objetos requiere una nueva forma de pensar, pues aunque son métodos de diseño diferentes, no son ajenos; la diferencia radica en que los métodos de diseño estructurados construyen programación estructurada mientras que el diseño orientado a objetos desarrolla


programación orientada a objetos, aunque la diferencia parezca evidente, para mucha gente no lo es y desafortunadamente cada quien tiene su propia concepción de lo que significa programación orientada a objetos.

En este capítulo se intenta mostrar que significa el desarrollo orientado a objetos.

Topología de los lenguajes de programacidn orientados y basados en objetos

Por topologia entiéndase al conjunto de bloques básicos de construcción del lenguaje y como estos pueden conectarse para generar las aplicaciones. En la programación estructurada los bloques y sub- bloques eran las piezas hndamentales con las que se generaban aplicaciones.

Los bloques de construcción en los lenguajes orientados a objetos son “módulos” que representan una colección lógica de clases y objetos en lugar de subprogrmas como en lenguajes anteriores. E n otras palabras, si los procedimientos y las funciones son verbos y los conjuntos de datos son sustantivos, un programa orientado a procedimientos está organizado alrededor de verbos, mientras un programa orientado a objetos está organizado alrededor de sustantivos. Por esta razón, la estructura física de una aplicación orientada a objetos de tamaño moderado aparece como una gráfica, lo cual es tipico en los lenguajes orientados a objetos, que nada tiene que ver con un árbol, como sería el caso de una aplicación estructurada; además, en este modelo se declaran escasos datos globales; en lugar de esto, los datos y las operaciones están unidos de modo que el bloque de construcción fundamental de estos sistemas es muy pequeño, se tienden a eliminar los algoritmos largos pero en su lugar estos se substituyen por clases y objetos. Esta topología se muestra en la Figura 4.

Pagina 17

Estudio mra el desarrollo de un sistema de adauisición. control v análisis automático de datos exwrimentales

Figura 4. Topología de una aplicación orientada a objetos.

Fundamentos del modelo de objetos

Analizando la perspectiva del modelo podemos ver las fases que lo componen y las características que identifican a cada una de ellas.

Programacidn orientada a objetos

Informalmente, un objeto puede definirse como una entidad que combina las propiedades de procedimientos y datos desde el punto de vista de que llevan a cabo cálculos y guardan un estado local. La idea principal aquí es que los objetos sirven para unificar las abstracciones de algoritmos y datos. En el modelo orientado a objetos, se enfatiza la fragilidad de los componentes fisicos o abstractos de un sistema para ser modelado por un sistema programado.

Los objetos tienen cierta integridad, misma que no puede ni debe ser violada, un objeto puede únicamente cambiar de estado, de comportamiento, ser manipulado o permanecer relacionado con otros objetos en forma apropiada.

Pero <qué es entonces lapmgramacidn orientadz a objetos?

Es un método de implementaci6n en el cual los programas e s t h organizados como una cooperativa de colecciones de objetos, cada uno de los cuales representa una instancia de una clase y cuyas clases

Página 18


son todas miembros de una jerarquia de clases unidas vía relaciones de herencia.

En esta definición, encontramos tres partes hndamentales, h pmgramación orientada a objetos:

1. Su unidad de construcción básica, son los objetos, no los . . algontmos.

2. Cada objeto es una instancia de una clase (pertenece a una clase).

3. Las clases se relacionan entre si vía atributos de herencia.

Un programa puede parecer orientado a objetos, pero si carece de cualquiera de las tres características anteriores no es un programa orientado a objetos. Específicamente podemos llamar programación orientada a objetos a aquella en la cual se maneja el concepto de herencia, lo demás solamente será programación con tipos abstractos de datos.

Un lenguaje que soporta herencia maneja una relación entre tipos, por ejemplo, una rosa es un tipo de flor, y una flor es un tipo de planta.

Diseno orientado a objetos

El énfasis de programas objetos se basa en el uso apropiado y efectivo de los mecanismos de un lenguaje de programación particular. Por el contrario, el diseño orientado a objetos, enfatiza la apropiada y efectiva estructuración de un sistema complejo. Una forma de definir que es el diseño orientado a objetos, seria la siguiente:

Es el método de diseño enfocado al proceso de descomposición del problema en objetos mediante una notación que describa, lógica, físicamente y dinámicamente dicho problema.

En general, llamamos diseño orientado a objetos a cualquier método orientado a descomponer el problema orientándolo hacia la filosofia de objetos.

Analisis orientado a objetos

Este análisis se basa en la construcción de modelos del mundo real, usando la visión orientada a objetos del mundo real:

Pagina 19


El análisis orientado a objetos es un método de análisis que examina los requerimientos desde la perspectiva de clases y objetos basados en el vocabulario del contexto del problema.

Pagina 20

Estudio para el desamllo de un sistema de adquisicion, control y análisis automático de dabs experimentales

Capítulo 4

Elementos del modelo orientado a objetos

Paradigmas de programación

Muchos programadores trabajan en un lenguaje y utilizan únicamente un estilo de programación. El estilo de pmgramaión es un modo de organizar programas en base a un modelo conceptual de programación y con un lenguaje apropiado para escribir programas en forma clara.

Básicamente encontramos 5 estilos de programación, fundamentados por los modelos de lenguajes existentes.

Orientados aprocedmzentos son aquellos basados en algoritmos.

Orientados a obetos basados en clases y objetos.

Orientados a U'ica aquellos basados en metas, con frecuencia expresados en cálculo de predicados.

Orientados a Rghs basados en sentencias If- then - reglas.

PBgina 21

Estudio para el desarrollo de un sistema de adquisici6n, control y anllisis autom&ico de datos experimentales

Orientados a mtricnones basados en relaciones invariantes.

E n realidad no existe un estilo de programación Único que sea el mejor para todas las aplicaciones. La programación orientada a procedimientos puede ser la mejor opción para el diseño de operaciones de cálculos complejos en cuyo caso usar orientación a objetos sería como cortarse las uñas con una tijera para podar pasto.

Cada uno de los estilos anteriores tiene un marco de trabajo propio y cada uno requiere una forma diferente de pensar y razonar a cerca del problema

Elementos del modelo orientado a objetos

Los cuatro elementos principales del modelo son:

Abstracción.

Encapsulado.

Modularidad.

Jerarquía (Herencia).

Entendiendo por principales que sin cualquiera de ellos, no hablamos de orientación a objetos. Además existen 3 características de menor importancia inherentes a este modelo, donde menor importancia significa que cada uno de estos elementos es útil, pero no parte esencial del modelo de objetos.

Tipeado (datos).

Concurrencia

Persistencia.

Sin estos elementos dentro de un marco de trabajo, quizá se llegue a programar en lenguajes como Delphi, Smalltalk o cualquier otro orientado a objetos y el resultado tenga más parecido a una aplicación desarrollada en C, Pascal o Fortran.

PBgina 22

Estudio para el desarrollo de un sistema de adquioici6n. control y análisis automático de datos experimentales

Abstraccidn

La abstracción es una de las formas con las que los humanos tratamos de modelar la complejidad. La abstracción parte del reconocimiento de las similitud entre ciertos objetos, situaciones o procesos en el mundo real, y se fundamenta en la decisión de concentrarse en esas similitudes e ignorar en el tiempo subsecuente las diferencias.

Una abstracción denota las características esenciales de un objeto que se distingue de los demás objetos y tiene claramente defmidas sus fronteras desde las perspectivas de un observador.

Una abstracción se enfoca a la parte exterior de un objeto, captura el comportamiento de este, sin más ni menos, pero en muchas ocasiones sucede que las abstracciones dependen del punto de vista del observador, y en la programación orientada a objetos debemos captar muy bien el enfoque que tiene el usuario de nuestro sistema o bien transmitir claramente nuestro enfoque para homologar abstracciones. La Figura 5 ilustra lo anterior.

Figura 5. Una abstracción enfoca las características principales de un objeto desde el punto de vista del observador.

Decidtr cual es el conjunto correcto de abstracciones para un problema dado, es el problema central en el diseño orientado a objetos. Hay quienes mencionan que existe un espectro de abstracción, en el cual están contenidas las entidades que modelan el dominio de un problema

Página 23


y que no dan cabida a objetos que no tienen razón de ser. De la más a la menos útil, este tipo de abstracciones incluyen las siguientes:

Abstracción de Entidad Un objeto que representa un modelo útil del dominio del problema o una entidad solución-dominio.

0 Abstracción de Acción Un objeto que provee un conjunto de operaciones cada una de las cuales desarrolla el mismo tipo de función.

Abstracción de máqzlina uirtztal Un objeto que agrupa juntas operaciones que son todas usadas por algún nivel superior de control u operaciones que usan todas algún conjunto de operaciones menor.

Abstracdn coincidental Un objeto que empaca un conjunto de operaciones que no tienen relación entre si.

Un programador orientado a objetos debe esforzarse en construir abstracciones de entidad, porque estas, estarán relacionadas directamente al vocabulario de un problema dado.

E s posible caracterizar el comportamiento de un objeto al considerar los servicios que este presta a otros objetos, así como las operaciones que este puede llevar a cabo para otros objetos.

La parte exterior de cada objeto define un contrato del cual otros objetos pueden depender, este contrato establece así todas las suposiciones que un objeto cliente debe hacer con respecto a un objeto servidor*. En otras palabras este contrato establece las responsabilidades de un objeto: nombre, su comportamiento, etc.

Un protocolo d e h e el modo en el cual un objeto puede actuar y reaccionar y de este modo constituir una entrada estática y una salida dinámica desde el punto de vista de la abstracción.

Junto con la idea de abstracción está el concepto de invarianza. Una invariante es una condición booleana (cierta o falsa) cuyo valor, debe preservarse. Para cada operación asociada a un objeto, deben defmirse precondciones (que la operación debe asumir como invariantes), así como postcondiciones (invariantes satisfechas por la operación). Si una precondición es violada significa que el cliente no ha satisfecho su parte

* Senidor en este caso se retiere a un objeto que lleva a cabo una tarea para un cliente.

Pagina 24


del contrato y en consecuencia el servidor no puede completar la suya. Algo similar ocurre si una poscondición es violada, esto significa que el servidor no ha llevado a cabo en forma satisfactoria su parte del contrato y sus clientes no pueden validar su comportamiento.

Algunos lenguajes permiten a los objetos manejar excepciones para así abandonar el proceso y alertar a algún otro objeto del problema.

Los términos operaciones, métodos y miembros de función, evolucionaron de diferentes culturas de programación (Ada, Smalltalk y C++) Todos ellos significan virtualmente lo mismo.

Todas las abstracciones tienen propiedades dinámicas y estáticas, por ejemplo, un objeto archivo tiene una cierta cantidad de espacio en un dispositivo de memoria, tiene un nombre y un contenido; todas estas son propiedades estáticas, pero el valor de cada una de ellas es dinámico y es relativo al tiempo de vida del objeto. El mismo objeto archivo puede crecer o disminuir su tamaño, puede cambiar su contenido, en un estilo de programación orientado a procedimientos la actividad que cambia el valor dinámico de los objetos es la parte central de todos los programas; en un estilo de programación orientado a objetos las cosas suceden cuando se envía un mensaje al objeto y se invoca una operación que es llevada a cabo por el objeto.

Para ilustrar el concepto de abstracción, supongamos que nos encontramos en una granja hidropónica, en donde las plantas crecen en una solución de nutrientes dentro de un invernadero, mantener el ambiente exacto dentro del invernadero es una tarea delicada, y depende del tipo de planta que está creciendo y de su edad; uno debe controlar diversos factores como temperatura, humedad, luz, pH y concentración de nutrientes. Si la granja fuese grande sería conveniente automatizar el proceso para que un sistema constantemente monitoreara y ajustara los elementos anteriores.

Una de las claves de abstracción de este sistema es un sensor , en la actualidad hay varios tipos de estos. Cualquier cosa que afecte la producción debe ser medida, ad, debemos tener sensores para la humedad, temperatura, luz, pH, concentraciones de nutrientes, además de otros. Visto desde fuera, un sensor de temperatura es simplemente un objeto que sabe medir la temperatura de un h p r epen$fco, (la importancia de ver desde afuera esta en ver solo los resultados, no nos interesa como hace las cosas por dentro). <Qué es la temperatura? Es un algún valor numérico dentro de un rango específico de valores y con cierta precisión en la escala que sea más apropiada para el

P b i n a 26

Estudio para el desarrollo de un sistema de adquisición. control y análisis automático de datos experimentales

problema. <Qué es un hgar espec$fco? Cualquier lugar dentro de la granja que sea designado para colocar el sensor y que sea identificable es decir que no pueda confundirse con otros sensores. Una vez definido lo anterior, estamos listos para definir cuales son las responsabilidades del sensor de temperatura. La decisión de diseño dice que el sensor es responsable de saber la temperatura de un ligar espenj%co dado y reportarla cuando esta le sea solicitada. De otra forma: ?Que operaciones puede un cliente solicitar a un sensor de temperatura? Supongamos que queremos que el cliente sea quien calibre nuestro termómetro y que este mismo cliente pueda preguntar cual es la temperatura actual.

Un plan de crecimiento es otra abstracción legitima y útil, ya que forma parte del vocabulario del dominio del problema; cada planta tiene su propio plan de crecimiento, pero los planes de todas las plantas tienen la misma forma, pues un plan de crecimiento es básicamente un mapa de tiempo - acción.

Un plan de crecimiento es entonces responsable de mantener un monitoreo de todas las acciones de interés asociadas con el crecimiento de una planta, y relacionadas con las acciones que deben llevarse a cabo. Desde la perspectiva exterior de cada objeto phn de crecimiento un cliente debe ser capaz de establecer los detalles de un plan, correlacionados con los tiempos en los que se lleva a cabo cada acción.

Como en este ejemplo apunta, ningún objeto permanece solo, cada objeto colabora con los demás para llevar a cabo alguna acción. Nuestras decisiones de diseño respecto a como colaboran entre sí los objetos definen las fronteras de cada abstracción y de este modo las responsabilidades y protocolos de cada objeto.

Encapsulado

Ninguna parte interna de un sistema complejo debe depender del exterior del mismo. Mientras la abstracción ayuda a la gente a pensar que se está haciendo, el encapsulado permite al programa cambiar y ser actualizado con un esfuerzo limitado.

La abstracción y el encapsulado son conceptos complementarios la abstracción se enfoca al comportamiento observable de un objeto mientras que el encapsulado trabaja con la implementación que da vida al comportamiento del objeto. La palabra encapsulado muchas veces se liga con “información oculta” es decir el proceso de mantener ocultas las características de un objeto que no contribuyen con sus

Página 26


características esenciales; en general, la estructura de un objeto es oculta, así como las implementación de sus métodos. Lo anterior lo ilustra la Figura 6.

Figura 6. El encapsulado oculta los detalles de la implementación de un objeto.

El proceso de encapsulado provee barreras explícitas entre diferentes abstracciones y de este modo establece una clara separación de conceptos, muchos autores mencionan que para que una abstracción trabaje, es necesario que su implementación sea encapsulada. Llevando esto a la práctica significa que una clase* debe constar de dos partes una interface y una implementación. La interface de la clase captura únicamente su vista exterior, describiendo en el comportamiento de nuestra abstracción el de todas las instancias de la misma clase. La implementación de una clase, comprende la implementación en sí de nuestra abstracción así como el desarrollo de los mecanismos que describen el comportamiento deseado de esta. La interface de una clase es el Único lugar donde deben hacerse todas las suposiciones a cerca de lo que un cliente puede solicitar a cualquiera de las instancias de la clase. La implementación encapsula los detalles sobre los cuales el cliente no puede hacer suposiciones.

En resumen, entendemos el proceso de encapsulado como sigue:

* Este concepto se describirá más adelante.

PIgina 27

Estudio para el desarrollo de un sistema de adquisición, control y análisis aubmático de datos experimentales

Encapsulado, es el proceso de separar los elementos de una abstraccidn (estructura y comportamiento), es decir el encapsulamiento sirve para separar la interface contractual* de una abstracción, de su implementacidn.

Podemos referimos a los elementos encapsulados como los secretos de una abstracción.

Para ilustrar este principio regresemos al ejemplo anterior; otra llave de abstracción dentro del dominio del problema es un “calentador” que seguramente será un nivel muy bajo de abstracción, en el diseño se pueden decidir tres actividades para ser llevadas a cabo por el “calentador”, es decir actividades que puede llevar a cabo el objeto: encenderse, apagarse y saber si está fbncionando, no es posible hacer que el fijar una temperatura sea responsabilidad del “calentador” en lugar de esto podemos asignar esa tarea a otro objeto, el cual puede interactuar con el sensor de temperatura y el calentador para realizar este comportamiento de nivel superior. Es de nivel superior porque de algún modo utilizará los conceptos de “sensor de temperatura” y “calentador” así como otros que son de bajo nivel, los cuales se encargarán de que el “calentador” se encienda o apague rápidamente cuando se alcancen las condiciones de frontera. El decidir separar estas responsabilidades, hace a cada abstracción individual más unida.

Si consideramos como ejemplo el phn de crecimiento, veremos que es esencialmente un mapa de tiempo - acción, la representación más razonable de esta abstracción debe ser un diccionario de pares de tiempo acción usando una tabla de hash abierta. No es necesario almacenar una acción por cada hora, pues los eventos no cambian tan rápidamente, en lugar de eso es recomendable almacenar acciones solamente para cuando sea necesarias.

Del modo anterior nuestra implementación encapsula dos secretos: el uso de una tabla de hash abierta (la cual forma parte del dominio de solución del problema, no del dominio del problema en sí.) y el uso de la extrapolación para reducir los requerimientos de almacenamiento (de otro modo deberían ser almacenados todos los eventos del periodo de crecimiento). Ningún cliente de estas abstracciones necesita conocer su implementación.

La parte que establece que es lo que la dase proporcionará y recibirá hacia y desde el exhior.

Página 2%

Estudio para el desanollo de un sidema de adquisición, control y anAlisia automático de dabs experimentales

La habilidad para cambiar la representación de una abstracción sin perturbar a ninguno de sus clientes es el principal beneficio del encapsulado.

En la mayoría de los lenguajes orientados a objetos, las clases poseen tres lugares donde pueden colocarse a sus elementos: publica (public), privada(private) y protegida(pr0tected). Los miembros declarados en la parte pública son visibles para todos los clientes; los declarados en la parte privada están completamente encapsulados; y los miembros declarados en la parte protegida son visibles únicamente a la misma clase y a sus subclases.

Modularidad

El acto de particionar un programa en componentes individuales puede reducir su complejidad. Pero esta no es la razón m& importante por la cual se particionan los programas en un estilo orientado a objetos, dicha importancia radica en que al particionar se crean un número bien definido de fronteras documentadas dentro de un programa. Estas fronteras o interfaces son de gran valor para la comprensión de un programa, en algunos lenguajes como Smalltalk, no existe el concepto de módulo, y las clases son la última parte fisica que se descompone. En la mayoría de los lenguajes como Pascal, Delphi, C++, CLOS, y ADA el módulo es la parte básica en la construcción de los programas y garantiza un conjunto separado de decisiones de diseño. En estos lenguajes, las clases y los objetos forman la estructura lógica de un sistema, al llevar las abstracciones a módulos se constituye la estructura fisica de un sistema. En especial para aplicaciones de gran tamaño para las cuales existen grandes cantidades de clases, el uso de módulos es esencial para manejar la complejidad.

La modularización consiste en dividir un programa en módulos que pueden ser compilados en forma separada, pero que guardan relaciones con otros módulos. La conexión entre módulos, se basa en las suposiciones que los módulos hacen entre sí.

Muchos lenguajes que soportan el módulo como un concepto separado también distinguen entre la interface de un módulo y su implementación. De este modo es seguro afirmar que modularidad y encapsulado son dos conceptos que van de la mano.

Así como el encapsulado, los diversos lenguajes, soportan la modularidad de varias formas, por ejemplo los módulos en C++ no son más que archivos compilados en forma separada. La práctica

PgBina 29


tradicional en los programadores de C es colocar las interfaces de los módulos en archivos con extensión .h que son considerados cabeceras de archivos, mientras la implementación de los módulos se almacena en archivos con extensión .c. Las dependencias entre estos archivos se ligan mediante la macro #include.

Sin lugar a dudas, decidir cual será el conjunto correcto de módulos para un problema dado es tan dificil como definir el conjunto correcto de abstracciones. Dado que la solución se ignora en el momento de desarrollar el sistema, modularizar llega a ser generalmente dificil.

figura 7. La modularidad empaca las abstracciones en unidades discretas.

Los módulos sirven como los contenedores físicos en los cuales se declaran las clases y los objetos de un diseño lógico dado. En el argot de la electrónica modularizar es similar a diseñar una tarjeta de computadora, las compuertas NAND, NORD y NOT se usan para construir la lógica necesaria, pero esas compuertas debe ser encapsuladas dentro de circuitos integrados estándares, tales como el 280, el 8080, etc.

Incluso para los programas más triviales una mejor solución será agrupar lógicamente las clases y objetos relacionados en el mismo módulo y exponer únicamente los elementos que los módulos restantes deban ver. La modularización arbitraria es en ocasiones peor que no modularizar nada, ya que muchos programadores tienden a modularizar cosas que no tienen razón de existir dentro de un módulo.

Página 30

Estudio para el desarrollo de un sistema de adquisición, control yanálisis automático de datos experimentales

En un diseño estructurado tradicional, la modularización está principalmente asociada con el significado de agrupar subprogramas, usando el criterio de acoplamiento y cohesión. Por el contrario, en un diseño orientado a objetos el problema es ligeramente diferente: la tarea consiste en decidir donde se empaquetaran fisicamente las clases y objetos de la estructura lógica del diseño, lo cual es radicalmente diferente al manejo de subprogramas.

La experiencia indica que hay varias técnicas útiles así como tips no técnicos que pueden ayudamos a alcanzar una modularización inteligente de clases y objetos. La meta principal de la descomposición en módulos es la reducción del costo del software permitiendo que los módulos sean diseñados y revisados independientemente. Cada estructura del módulo debe ser suficientemente simple para ser comprendida en su totalidad. Debería ser posible cambiar la implementación de otros módulos, sin necesidad de conocer la implementación de los módulos restantes y sin afectar el comportamiento de estos.

El desarrollador debe entonces balancear dos cosas: El deseo de encapsular todas las abstracciones y la necesidad de hacer ciertas abstracciones visibles a otros módulos.

Los detalles del sistema que son susceptibles de cambio independiente deberían ser secretos entre módulos separados. Las únicas suposiciones que deberían aparecer entre módulos son aquellas consideradas susceptibles de cambio. Cada estructura de datos es “privada” para un módulo, este puede ser directamente accedido por uno o más programas dentro del módulo, pero no por programas fuera del módulo. Ningún otro programa que requiera información almacenada en las estructuras de datos de los módulos ajenos a ella debe obtenerla.

En otras palabras el programador debe esforzarce para construir módulos que sean cohesivos (agrupando lógicamente las abstracciones relacionadas) y perdiendo la dependencia (es decir minimizando estas cuando se dan entre módulos). Desde esta perspectiva podemos defmir la modularidad como:

Modularidad es la propiedad de un sistema que ha sido descompuesto en un conjunto de mddulos unidos entre s i y con una baja cohesidn entre ellos.

Página 31


Entonces, los principios “abstracción” , “encapsulado” y “modularidad”, son sinergéticos. Un objeto provee una frontera clara alrededor de una abstracción simple, y ambos, encapsulamientos y modularidades generan barreras alrededor de esta abstracción.

Dos técnicas adicionales pueden afectar las decisiones de modularización. La primera, desde que el módulo se emplea como una unidad elemental indivisible de software que puede ser reutilizado a través de la aplicación. Un desarrollador puede escoger el empaquetado de clases y objetos en módulos de modo qye haga su reutilización óptima. Segundo: muchos compiladores, generan el código objeto en segmentos, unos por cada módulo entonces existen límites prácticos en el tamaño de módulos individuales.

Los programadores expertos generalmente se hacen cargo de la implementación de las interfaces del módulo , mientras que los menos experimentados se encargan de la implementación de las mismas.

Encontrar las clases y objetos adecuados y organizarlos en módulos separados son decisiones de diseño independientes. La identificación de clases y objetos es parte de un diseño lógico del sistema, pero la identificación de módulos es parte del diseño fisico del mismo.

Jerarquía

El concepto de abstracción es muy útil, pero en la mayoría de los problemas, excepto en los más simples, pueden encontrarse diferentes tipos de abstracciones que no pueden comprenderse al mismo tiempo. El proceso de encapsulado nos ayuda a manejar esta complejidad ocultando el contenido de estas abstracciones, la modularidad ayuda también al proporcionar una forma lógica de manejar las abstracciones, pero aún así esto no es suficiente; así que un conjunto de abstracciones con frecuencia forman una jerarquía y al identificar estas jerarquías dentro del problema, la comprensión de este se simplifica en gran medida.

El significado de Jerarquía dentro del contexto de la programación orientada a objetos se define como

Es el proceso de ordenar o dar un rango a las abstracciones.

Las dos estructuras jerárquicas más importantes en un sistema complejo son las clases y las unidades derivadas de estas, los objetos.

PBgina 32


Esto es más claro si pensamos en las clases, como las fuentes de las cuales derivamos subclases u objetos para generar nuevas estructuras.

El ejemplo más claro de jerarquía se encuentra en el concepto de herencia simple, y como hemos notado antes, es un elemento esencial de la programación orientada a objetos. Básicamente al heredar estamos definiendo una relación entre clases, donde una clase comparte la estructura o comportamiento definido en una o más clases ( lo anterior se denota como herencia simple en el primer caso y herencia compuesta en el segundo).

De este modo la herencia representa una jerarquía de abstracciones en la cual una clase hereda de una o mas superclases. Típicamente una subclase incrementa o redefine las estructuras y comportamiento de sus superclases.

Herencia simple

Semánticamente la herencia denota una relación “es un”, por ejemplo, un oso “es .un” tipo de mamífero, un rosa “es un” tipo de flor, el quick sort “es zm” tipo especial de algoritmo. De este modo la herencia establece un tipo de jerarquía generalización/especialización, dentro de la cual una subclase especializa y mejora la estructura general de su superclase. La siguiente es la prueba de la herencia. Si B no es un tipo de A, entonces B no debe heredar de A.

Llevando lo anterior al ejemplo del jardm hidropónico, si consideramos los diferentes tipos de planes de crecimiento deberíamos usar sistema de jardinería hidropónica. Antes de pensar en la existencia de varios tipos de planes, habíamos pensado en una abstracción de un plan generalizado de crecimiento, pero diferentes tipos de plantas demandan planes de crecimiento especializados. Por ejemplo, el plan de crecimiento de las plantas frutales es generalmente el mismo entre las mismas plantas frutales, pero es esencialmente diferente de un plan de crecimiento para vegetales o de un plan para cultivos florales. Partiendo de este, parece razonable crear un plan de crecimiento para las plantas frutales que encapsule el comportamiento común de todas l a s plantas frutales, que contenga la información de los periodos de polinización, o los periodos de cosecha, etc.

Al evolucionar las jerarquías de herencia, la estructura y comportamiento son comunes para diferentes clases que tenderán a migrar a superclases comunes. Es por esto que frecuentemente se habla de la herencia como una jerarquía de

PBgina 33


generalización/especialización. Las superclases representan abstracciones generalizadas y l a s subclases representan las especializaciones en las cuales los métodos y campos de una superclase se pueden añadir, modificar e incluso ocultar. De este modo la herencia nos permite establecer nuestras abstracciones economizando expresiones. Sin la herencia, cada clase sería una unidad independiente que debería ser desarrollada por separado.

Clases diferentes pueden relacionarse entre sí mediante métodos provistos por el diseñador, de otro modo, estas clases son entes independientes. Cualquier consistencia a través de las clases es resultado solamente de la disciplina de los programadores. Hay una saludable relación entre los principios de abstracción, encapsulado y jerarquía. La Figura 8 ilustra el significado de la jerarquía.

Pagina 34

Estudio para el desarrollo de un sistema de adquisición, control y análisis automfico de datos experimentales

Figura 8. Las abstracciones se clasifican mediante las jerarquias.

Para una clase dada, hay generalmente dos tipos de clientes: objetos que invocan operaciones desde instancias de la clase y subclases que heredan las propiedades de la clase.

Herencia múltiple

En la sección anterior se explicó el manejo de la herencia simple, y en el ejemplo, se puede manejar una subclase PlanDeCrecimientoFrutal que hereda sus características de una superclase PlanDeCrecimiento,

Pdgina 36


este tipo de herencia se conoce como herencia simple, pero para algunas abstracciones es útil manejar la herencia de varias superclases. Por ejemplo si definimos que describa una planta, la superclase planta; cada instancia de esta clase tend6 un nombre de la especie, la fecha en que se plantó, una especie. Adicionalmente se pueden establecer algunas condiciones de crecimiento óptimo para cada tipo particular de planta, es de esperarse que este comportamiento se especialice por subclases.

Nuestro análisis del dominio del problema puede sugerir que las plantas florales, las vegetales y las frutales tengan propiedades especiales que son relevantes para nuestra aplicación, por ejemplo para una planta floral dada: el tiempo esperado en que florecerá y la época en que debe ser sembrada pueden ser datos importantes. En forma similar la época de cosecha para las plantas frutales y las vegetales. Una forma en la que podemos capturar nuestras decisiones de diseño puede ser la creación de dos nuevas clases: una clase Flor y otra Frutavegetal, ambas subclases de la clase planta. Pero, <qué necesitamos para modelar una planta que produzca tanto flores como frutos?, para esta abstracción necesitamos una tercera clase FlorFrutaVegetal que duplica información de las clases Flor y Frutavegetal. Una forma de expresar nuestras abstracciones y eliminar esta redundancia es utilizar herencia múltiple. Primero debemos inventar clases que capturen independientemente las propiedades referentes a las plantas florales y a las plantas vegetales, a partir de estas clases, generaremos las demás subclases. En caso de definir clases florales o clases frutales, podemos heredar de estas superclases, y si hubiese necesidad de crear una subclase Calabaza que tiene tanto flor como vegetal, esta heredada de ambas superclases.

Tipeado

El concepto de @o se deriva de las teorías de Tipos de Datos Abstractos’ . Un tipo es una caracterización precisa de estructuras o propiedades de comportamiento que son compartidas por una colección de entidades. En el contexto de la programación orientada a objetos muchas ocasiones se utilizan los conceptos tipo y clase como si hesen lo mismo, pero un tipo y una clase no son exactamente lo mimos. Algunos lenguajes actualmente distinguen ambos conceptos, en nuestro contexto, será suficiente entender que una clase complementa

Este concepto nace al pensar que l o s ímicos tipos de datos reales son la palabra, el byte, el bit y otras estructuras similares que dependen de la arquitectun, de l o s CPU’s todos los demás arreglos de datos se conocen como tipos de datos abstractos y se construyen a partir de estas unidades fundamentales.

Phglna 36

a un tipo. En el contexto de la programación orientada a objetos entendemos por tipeado a

Una forma de restricción que se ejerce sobre los datos de un objeto, para que sólo exista intercambio entre aquellas entidades que compartan un mismo tipo de datos, o en el peor de los casos, este intercambio se restringe.

El tipeado nos permite expresar nuestras abstracciones de modo que el lenguaje de programación en el cual estamos implementando puede forzar las decisiones de diseño.

Por ejemplo si consideramos la unidades de medición en fisica. Cuando dividimos distancia entre tiempo, esperamos un valor que denote velocidad no peso ni otra cosa, este es un ejemplo de fuerte tipeado es decir, mediante el tipeado se establecen las reglas en las que coexistirán las relaciones entre nuestros datos.

La Figura 9 ilustra lo útil que puede llegar a ser un fuerte tipeado como auxiliar en el control para evitar la mezcla de abstracciones.

figura 9 Las estructuras con fuerte tipeado, previenen la mezcla de datos.

Estudio para el desarrollo de un sistema de adquisición, control y anPlisis automático de datos experimentales

Concurrencia

Para ciertos tipos de problemas, un sistema puede necesitar manejar muchos eventos en forma simultánea. Otros problemas pueden involucrar muchos cálculos y exceder la capacidad de un procesador simple. En cualquiera de estos casos es común considerar el uso de sistemas distribuidos para un modelo de implementación, o usar un procesador que sea capaz de soportar la multitarea. Un proceso simple (conocido como una línea de control) es la raíz desde la cual acciones dinámicas independtentes ocurren dentro de un sistema. Cada programa tiene al menos una línea de control, pero un sistema que involucra concurrencia puede tener varias líneas de control, algunas de ellas transitorias que están activas durante toda el tiempo de ejecución del programa. Los sistemas que se ejecutan a través de múltiples procesadores permiten la concurrencia de varias líneas de control. Mientras que aquellos que trabajan sobre un sistema de un sólo procesador, solamente pueden simular estas líneas de control concurrentes.

Es posible distinguir también entre Concurrencia ligera y concurrencia pesada. Un proceso de concurrencia pesada es tipicamente manejado por un modelo de sistema operativo, de este modo se apropia de su propio espacio para direccionar, en tanto que un proceso de concurrencia ligera, funciona dentro de un entorno de sistema operativo de un solo proceso y comparten las mismas dtrecciones, es decir comparten recursos. La comunicación entre procesos de concurrencia pesada es muy costosa y con frecuencia involucra los datos compartidos.

Muchos sistemas operativos modernos proveen soporte transparente para manejar la concurrencia. Ademis, en altos niveles de concurrencia la programación orientada a objetos puede resolver los problemas de concurrencia de la mayoría de los programadores al ocultar la concurrencia dentro de abstracciones reusables. Un modelo orientado a objetos es muy apropiado para un sistema distribuido porque implícitamente define las unidades de distribución y movimiento asi como las entidades que se encargan de la comunicación.

Mientras la programación orientada a objetos se enfoca a la abstracción de datos, el encapsulado y la herencia, la concurrencia se enfoca a los procesos de abstracción y sincronización. El concepto de objeto unifica estos dos puntos de vista: cada objeto (una abstracción del mundo real) puede representar una línea de control ( un proceso de abstracción). Algunos objetos son llamados activos. En un sistema

Página 38

Estudio para el desarrollo de un sistema de adquisicion. control y análisis automático de datos experimentaks

basado en un diseño orientado a objetos es posible conceptualizar el mundo como un conjunto de objetos que cooperan entre sí, partiendo de esto podemos definir la concurrencia como:

Concurrencia es la propiedad que distingue un objeto activo de uno que no lo está.

La Figura 10 describe en forma clara el concepto de concurrencia.

F'igura 10. La concurrencia permite a diferentes objetos actuar al mismo tiempo.

Para ejemplificar la concurrencia podemos retomar el sensor de temperatura, cuyo comportamiento requiere un periódico censo de la tempera actual para Io cual invoca a una función de un objeto cliente, siempre que la temperatura cambia un cierto número de grados de un punto dado. No se explicó como es que la clase implementa este comportamiento, este hecho es un secreto de la implementación, pero es claro que se requiere alguna forma de concurrencia. En general hay tres formas de concurrencia en el diseño orientado a objetos.

La primera es una característica intrinseca de algunos lenguajes de programación , por ejemplo es posible crear objetos activos que corran algún proceso concurrente con todos los demás objetos activos.

La segunda forma utiliza una librería de clases que implementa alguna forma de proceso de concurrencia ligera. Naturalmente la implementación de este tipo de librerías es altamente dependiente de la

PBgina 39


plataforma, aunque la interface de la misma es relativamente portable. En este caso la concurrencia no es una parte intrínseca del lenguaje, pero aparece como si lo fuese a través de la presencia de las clases estándares.

La tercera forma usa interrupciones para similar la concurrencia. Este modo requiere de cierto conocimiento del funcionamiento del hardware. Por ejemplo en nuestra implementación del sensor de temperatura podemos tener un timer de hardware que periódicamente interrumpa la aplicación y en ese momento se lea la temperatura actual.

Sin importar el tipo de concurrencia que se utilice una de las realidades a cerca de la concurrencia es que una vez que se ha introducido esta en el sistema es necesario considerar como sincronizan sus actividades los objetos activos entre sí, así como con objetos que llevan a cabo actividades puramente secuenciales. Por ejemplo si dos objetos activos tratan de enviar mensajes a un tercer objeto debemos estar seguros de usar algún subsistema de exclusión mutua, de modo que el estado del objeto sobre el cual se está actuando no sea corrompido mientras dos objetos tratan de modificarlo al mismo tiempo.

Este es el punto donde las ideas de abstracción, encapsulado y concurrencia interactúan. En la presencia de la concurrencia no es suficiente simplificar para definir los métodos de un objeto, debe hacerse lo necesario para que estos métodos sean preservados en la presencia de múltiples líneas de control.

Persistencia

Un objeto en software ocupa cierta cantidad de espacio y existe por una cantidad de tiempo particular. El espectro de persistencia de un objeto esta fundamentado en los siguientes puntos:

0 Resultados transitorios en la evaluación de expresiones.

0 Variables locales en la activación de procedimientos.

0 Variables propias, variables globales y cabeceras.

0 Datos existentes entre ejecuciones de un programa.

0 Datos que existen entre varias versiones de un programa.

PAgina 40

Estudio para el desarrolla de un sistema de adquisicion, control y an&lisis autom&tico de datos experimentales

Los lenguajes de programación tradicionales generalmente direccionan los primeros tres tipos de persistencias, los últimos dos tipos de persistencia son característicos de las tecnologías de bases de datos.

La persistencia se define entonces como:

La persistencia es la propiedad de un objeto a través de la cual su existencia trasciende en espacio y /o en tiempo, es decir, el objeto continua existiendo después de que su creador deja de existir.

La Figura 11 ilustra el concepto de persistencia.

figura 11. La persistencia guarda el estado y clase de un objeto a través del tipo o el espacio.

Pdgina 41


Capítulo 5

Premisas de diseño en el modelo orientado a objetos

A continuación se presenta una lista de premisas básicas en el desarrollo de sistemas mediante el uso del modelo orientado a objetos.

Premisas referentes a clases y objetos.

Un objeto tiene estado, comportamiento e identidad.

0 L a estructura y comportamiento de objetos similares esta definida en su clase común.

El estado de un objeto está compuesto por todas sus propiedades que generalmente son estáticas (en el ejemplo del termómetro: su rango, etc.) además de los valores actuales de cada una de estas propiedades, mismos que generalmente son dinámicos @ara el objeto termómetro el valor de la temperatura a cada momento ).

El comportamiento de un objeto describe como se comporta y reacciona este en términos de sus cambios de estado y del paso de mensajes entre objetos.

Pagina 42


La identidad es la propiedad de un objeto que lo distingue de los demás.

Los dos tipos de jerarquía de objetos incluyen ligas y relaciones agregadas.

Una clase es un ente a partir del cual es posible derivar objetos que comparten una estructura y un comportamiento comunes.

Se conoce como llaves de abstracción a las clases y los objetos que conforman el vocabulario del dominio de un problema, es decir el conjunto de entidades que modelan el problema (el plan de crecimiento del ejemplo, es una llave de abstracción).

Las llaves de abstracción reflejan el vocabulario del dominio del problema y pueden obtenerse del análisis de dicho dominio o inventarse como parte del diseño.

Un mecanismo es una estructura medante la cual un conjunto de objetos trabajan juntos para proveer un comportamiento que satisfaga algunos requerimientos de un problema.

La calidad de una abstracción puede ser medida por su cohesión, suficiencia, integración. Es decir, pueden existir abstracciones evidentes dentro del problema, pero que no sean relevantes para este. Dependiendo del contexto en el que se plantean, las abstracciones cobran o carecen de calidad.

Premisas de clasificación (creación e identificación de clases)

La identificación de clases y objetos es fundamental en el diseño orientado a objetos, la identificación involucra tanto el descubrimiento como la invención.

0 La clasificación es un problema fundamentalmente de agrupación.

La clasificación es un proceso incremental e iterativo. Puede ser dificil porque un conjunto de objetos pueden ser clasificados en muchas formas y todas o por lo menos varias de ellas pueden ser adecuadas.

Página 43

Estudio para el desarrollo de un sistema de adquisicibn, control y análisis automático de datos experimentales

Las tres técnicas de clasificación son:

l. Categorización clásica: Clasificación por propiedades.

2. Agrupación conceptual: Clasificación por conceptos.

3. Teoría de prototipos: Clasificación por asociación con un prototipo, es decir se crea un prototipo de solución, que la mayoría de l a s veces tiene más que ver con un modelo que del problema que con una solución programada en algún lenguaje.

0 El planteamiento de escenarios es una herramienta muy poderosa en el análisis orientado a objetos y puede usarse para conducir el proceso de análisis clásico, el análisis de comportamiento y el análisis de dominio.

0 L o s mecanismos denotan decisiones de diseño específico respecto a la actividad de colaboración de muchos tipos diferentes de objetos.

Premisas de notación

0 Diseñar no es el acto de dibujar diagramas, un diagrama simplemente captura un diseño, pero no por contar con un diagrama podemos decir que hemos hallado una solución eficiente.

En el diseño de un sistema complejo es importante ver el diseño desde diferentes perspectivas: la estructura lógica y fisica así como la semántica estática y dinámica.

La notación para el desarrollo orientado a objetos incluye cuatro diagramas básicos:

1. Diagramas de clase

2. Diagramas de objeto

3. Diagramas de módulo

4. Diagramas de proceso

asi como dos diagramas suplementarios:

PBgina 44


1. Diagrama de transición de estados.

2. Diagramas de interacción.

0 Un diagrama de clase es usado para mostrar la existencia de clases y su relación en el diseño lógico de un sistema.

Un diagrama de objeto es usado para mostrar que la existencia de estos mantiene una relación con el diseño lógico de un sistema. Un diagrama de objeto simple es usado para representar un escenario.

Un diagrama de módulo se usa para mostrar la distribución de clases y objetos en módulos dentro del diseño fisico del sistema. Un diagrama de módulo simple representa una vista de la arquitectura de módulos de un sistema.

Un diagrama de proceso es usado para mostrar la distribución de procesos en el diseño fisico de un sistema Un diagrama de proceso simple representa una vista de la arquitectura de procesos de un sistema.

Un diagrama de transición de estados se usa para mostrar el espacio estado de una instancia de una clase dada, los eventos que causan una transición de un estado a otro y las acciones que resultan del cambio de estado.

0 Un diagrama de interacción se usa para trazar la ejecución de un escenario en el mismo contexto que en un diagrama de objeto.

Premisas del proceso de análisis y diseño de sistemas orientados a objetos

0 Dado que los proyectos exitosos son aquellos que satisfacen y/o solucionan la necesidad que los originó de acuerdo a las condiciones y restricciones impuestas por la misma naturaleza del problema o de las necesidades que lo originan; para llegar a ellos en la programación orientada a objetos, debe seguirse pacientemente un conjunto de pasos para hacer refinamientos sucesivos que permanezcan dentro del marco problema, esto refinamientos se llevan a cabo en lo que se conoce como administración de los ciclos de vida interactivo (los miembros del equipo de desarrollo interactúan entre si y con los miembros del equipo de implantación

Pagina 46

Estudio para el desarrollo de un sistema de adquisición, control yanáliris automático de datos experimentales

de la solución) e incremental (a una solución base se incrementan trozos que poco a poco conformaran la solución final).

No es posible llevar a cabo un diseño de sistemas completamente racional, muchos sistemas son más artesanales y producto del ingenio y la creatividad que del raciocinio de sus diseñadores.

Una de las fases del ciclo del desarrollo de un sistema está representada por las actividades cotidianas del equipo de desarrollo.

E l primer paso de esta fase involucra la identificación de las clases y objetos en un nivel dado de abstracción: las actividades principales incluyen el descubrimiento y la invención.

El segundo paso involucra la identificación de la semántica de las clases y objetos.

El tercer paso involucra la identificación de las relaciones entre las clases y los objetos, las actividades principales incluyen la especificación de las asociaciones y la identificación de colaboraciones.

El cuarto paso consiste en implementar las clases y objetos y la actividad principal consiste en seleccionar las estructuras de datos y los algoritmos.

La otra fase dentro del desarrollo de sistemas orientados a objetos sirve como controlador del marco de trabajo para el análisis del sistema y define un número de productos medibles y actividades de administración de riesgo.

El primer paso en esta fase consiste en conceptualizar cuales son los requerimientos básicos del sistema.

El segundo paso es analizar como proveer un modelo del comportamiento del sistema, la actividad principal consisten el análisis del dominio y la planeación de escenarios.

El tercer paso consiste en diseñar una arquitectura para la implementación y establecer una política de tácticas común (en especial cuando muchas personas trabajan en el sistema), las actividades principales consisten en llevar a cabo la planeación de la arquitectura, desarrollar el diseño táctico y actualizar la planeación.

Página 46


o El cuarto paso consiste en hacer evolucionar el sistema, este paso utiliza sucesivos refrnamientos para ultimar los detalles en la producción del sistema. Las actividades principales incluyen la aplicación de los micro procesos y la administración del cambio.

0 El quinto paso radica en los procesos de mantenimiento, los cuales son indispensables en las actividades posteriores a la liberación del sistema. Las actividades principales son similares a las del paso cuatro y además se incluye la administración de una lista de tarjetas en las que se manejan los requerimientos de los usuarios.

Pagina 47

Estudio para el dmarrollo de un sistema de adquisición, wntml y análisis automitico de dabs experimentales

Capítulo 6

¿Qué herramienta vamos a utilizar?

En este punto del proyecto ya estabamos seguros que para obtener la mejor solución, debíamos usar un lenguaje orientado a objetos, pero ¿cuál?, estabamos en busca del mejor, los requerimientos eran varios y comprometedores:

0 El lenguaje debe ser capaz de permitir la programación en bajo nivel, es decir debe permitir al programador incluso trabajar en ensamblador si fuese necesario.

0 Debe trabajar en el ambiente Windows y aprovechas todas las características de este entorno.

0 Debe permitir un fácil aprendizaje de su gramática y sus reglas, de lo contrario el desarrollo tomará más tiempo de lo esperado.

0 Debe ser compatible con al menos algunos componentes que puedan generarse en otros lenguajes.

PBgina 48

Estudio para el clesamllo de un sistema de adquisición. control y anllisis automático de datos experimentales

Debe ser totalmente orientado a objetos, para poder de algún modo optimizar las líneas de programación y permitir que sean reutilizadas, aprovechando sobre todo las propiedades de herencia de una herramienta completamente orientada a objetos.

E n el transcurso del análisis del problema evaluamos tres herramientas, en el orden que se indica a continuación:

1. Visual Basic

2. Visual C++

3. Delphi

Visual Basic, resulto ser muy orientado a aplicaciones sencillas, basado en el legendario lenguaje BASIC, conserva muchas de sus características, sobre todo en lo que respecta a la gramática. Además de no ser completamente orientado a objetos, por lo que no es posible reutilizar todas las líneas de programa.

Por otro lado Visual C++ es tan complicado y complejo que para aprender las reglas de programación del mismo, aún siendo experto programador en sus ancestros (C++ y C) realmente tomaría mucho tiempo aprender a utilizar todas sus potencialidades, además de que, para decepción nuestra, tampoco Visual C++ es totalmente orientado a objetos.

La solución ideal la encontramos en Delphi, una herramienta robusta que cumple con todas las especificaciones que planteamos, está totalmente orientado a objetos, lo que nos da la ventaja de ahorrar tiempo en el desarrollo, al utilizar la potencia de la herencia. Además que nos permite programar tanto a bajo como a alto nivel, lo que nos da la ventaja de interact" directamente con el hardware involucrado en el problema. Permite utilizar módulos que hayan sido creados en otros lenguajes como Visual Basic o incluso Visual C++. Además de ser fácil de manejar, con varias de las características de su ancestro Pascal.

Ahora como cuando decidimos trabajar con tecnología orientada a objetos, tendremos que aprender a manejar las características fundamentales de lo que es DELPHI. Fm el capitulo siguiente presentamos una introducción a las características y reglas principales de esta herramienta de desarrollo.

PQina 49

Estudio para el desarrollo de un sistema de adquisición, control y analisir automático de datos experimentales

Capítulo 7

Los componentes fundamentales de Delphi

En este capítulo comenzamos a armar el rompecabezas de lo que el Delphi. Es un breve resumen de lo que son los proyectos, una introducción al tipo de librerías que maneja, un repaso a las unidades que son herencia de Pascal, a las formas, a los módulos de datos y a los archivos include y al final nos introducimos a lo que consideramos la piedra angular de este proyecto y quizá de Delphi: Los componentes.

¿Qué son los proyectos?

Dependiendo del software que se utilice el termino prtjech puede tener un s in número de significados diferentes. En el entorno de los sistemas basados en el modelo de objetos, un project es el “contenedor” de más alto nivel de todos los objetos en una aplicación. Su propósito es relacionar los archivos que generan una aplicación con cualesquiera otros, para establecer relaciones de dependencia entre ellos. Un pmject sencillo generalmente actúa como contenedor de todos los objetos de la aplicación, pero no siempre es el caso. Las aplicaciones complejas muchas veces están compuestas de múltiples project y en ocasiones un

Estudio para el desarrollo de un sistema de adquisici6n. control y analisis automático de datas experimentales

p~oject se utiliza para más de una aplicación sencilla. En muchas herramientas de desarrollo un pyect produce un archivo ejecutable.

Los projects de Delphi

En Delphi, un project es una lista maestra de todos los archivos que componen una aplicación sencilla. Los projects de Delphi son un poco inusuales con respecto a los pyects tradicionales, porque estos también contienen código fuente. Esto es: Un proj’ect de Delphi es el código fuente de un objeto de Pascal que puede visualizarse y modificarse si es necesario.

Pero aunque es posible modificar un archivoproject de Delphi en forma manual, no es necesario hacerlo; debido a que Delphi puede cambiar partes de este archivo, por esto es mejor evitar hacer cambios sobre este, dado que Delphi puede confundirse, o sobreescribir sobre las modificaciones que hicimos e incluso alterarlas..

Dado que los projects de Delphi se almacenan como código íüente y para el sistema operativo residen como archivos, los nombres de estos archivos están limitados únicamente por las restricciones de los identificadores de Pascal. Los nombres de archivos project y de unidades deben empezar con una letra y pueden incluir letras, números y el carácter de subrayado, pero no se permiten espacios, ni puntos.

program Invernadero uses

Forms , formal in ’Formas.pas‘ {fmFormas} Reporte in ‘Reportes.pas’{fmReportes)

f $R *.RES}

begin Application.Title:= ‘Invernadero’; Application.CreateForm(TfmFORMA 1) ; Application.Run;

-

end.

Listado 1. Archivo Project del sistema Invernadero

Página 61


La palabra reservada program

Observemos en el Listado 1, la posición y uso de la palabra reservada progmm, es la primera palabra dentro de un archivo p~oject y, en aplicaciones sencillas, generalmente va seguida del nombre del programa. Esta palabra le indica al compilador que este archivo se convertirá en su propio ejecutable. En una librería de ligas dinámicas o unidades, la palabra reservada program podría ser reemplazada por Lbra? o unit, respectivamente.

La declaración Uses

La declaración uses lista las unidades de Object Pascal que Delphi liga para construir un ejecutable. Las unidades son como las moléculas en las aplicaciones de Delphi. Cualquier unidad cuyo código fuente es m& reciente que su código compilado se recompila automáticamente al compilar o ejecutar el archivo py’ect.

La unidad Forms en el Listado 1 es parte de la librería de componentes visuales de Delphi y define las características visuales de las formas de Delphi. Las otras unidades listadas corresponden a las formas que han sido añadidas al archivo pyed, cada línea lista el nombre de la unidad el nombre del archivo en el que se localiza esta dentro del entorno del sistema operativo y el nombre de la forma que contiene la unidad. El nombre de la forma le fue asignado dentro de la propiedad name en el inspector de objetos de Delphi.

Con la ventaja de Delphi para soportar nombres largos, el nombre de la unidad y el nombre del archivo en la que esta está almacenada son idénticos, a excepción de la extensión de dicho archivo. Durante la compilación, si el compilador de Delphi no puede encontrar una unidad usando su nombre largo, este tratará de hallarlo truncando o acortando el nombre.

La directiva $R

La directiva de compilación $R, Listado 1, le indica al compilador que debe incluir el recurso de Windows especificado dentro del project. El asterisco indica al compilador que el archivo tiene el mismo nombre base que elproject. Delphi crea un archivo de recursos para cada módulo en el project incluyendo el mismo archivo project. Si los archivos no existen cuando Delphi está ligándolos, manda el mensaje de error:

Estudio para el desarrollo de un sistema de adquisición, control y anilisis automática de datos experimentales

File not found xxx.RES

Con este mensaje puede suceder que la ruta no sea la misma donde se encuentra el project o que el archivo no existe.

Application.Create.Form

La sentencia Application.Create.Form carga en memoria las formas que se indican dentro del archivo project. Generalmente todas las formas del proyecto están listadas aquí. Es posible controlar si alguna forma será creada manualmente por el programador, esto se consigue utilizando las selecciones de menú Options/Project dentro del entorno de desarrollo de Delphi (Integrated Development Environment IDE).

El orden en el cual están listadas los conjuntos de sentencias Application.Create.Form es muy importante ya que determina el orden en el cual las formas serán creadas. La primera forma que deberá ser creada debe ser la forma principal del proyecto. Si se desea cambiar el orden de creación de las formas debe utilizarse la opción de menú: OptionslProject y jamás deberá editarse el archivopyect.

Application.Run

Application.Run comienza a correr la aplicación, captura el ciclo dentro del cual correrá la aplicación.

Librerías de Delphi

Delphi contiene un mecanismo muy práctico para construir librerías DLL's (Dinamic Link libraries). A diferencia de otros lenguajes de programación en Windows, Delphi en general incluye una sintaxis especial para construcción de DLL's. Para activar las opciones de Delphi de modo que soporte DLL's se utilizan dos palabras reservadas lybrary y export, la palabra reservada l y b r a r y ocuparía el lugar de la palabra reservada program en el caso del ejemplo anterior. Esta palabra indica a Delphi que debe construir un DLL en lugar de un archivo ejecutable. Por otro lado la palabra reservada export tiene dos aplicaciones: primero esta señala las rutinas individuales dentro de los DLL's como exportables y segundo, en su forma plural, hace que las funciones indicadas por ella dentro del DLL puedan ser exportadas para que otros programas ejecutables puedan utilizarlas.

Página 63

Estudio para el desarrollo de un sistema de adquisición, control y an&lisis automático de datos experimentales

La forma de las librerías es muy similar a la de los programas. En el Listado 2 se presenta un ejemplo de lo anterior.

library StrUtil; uses

function Pad(1nString: String; Len: Integer): String; export; begin

end; function LPad(1nString: String; Len: Integer): String; export; begin

end ; exports

SysUtils;

Result:=Fomat('%-*s',[Len, InString]);

Result:=Format('%*s',[Len, InString]);

Pad index 1 , LPad index 2;

begin end.

Listado 2. Ejemplo de una librería sencilla de Delphi.

Aquí se observa como ambas funciones son señaladas con la palabra reservada export. La sentencia export le indica a Delphi que debe exportar las rutinas que se ubican bajo esta, desde el DLL hacia otras llamadas ejecutables.

Las unidades de Delphi

Así como las formas, las unidades son bloques de construcción moleculares dentro de las aplicaciones de Delphi. Las unidades albergan las formas que le dan a las aplicaciones la apariencia visual. Además, en las unidades se almacena código que el programador escribe para soportar las funciones que su aplicación proporciona.

Cada forma que se agrega a un project viene con su propia unidad fuente. Esta unidad fuente contiene una definición de clase que es el reflejo de la representación visual de la forma. Para cada componente que se agrega a una forma, el diseñador de formas de Delphi modifica la definición de la clase para reflejar el nuevo componente. Cada vez que se agrega un manejador de eventos a la forma el código de este manejador de eventos se almacena en el archivo de la unidad. En general todo el código que el programador genera en Delphi, se almacena en archivos de unidad.

Pdgina 64

Estudio para el desarrollo de un sistema de adquisición, c o n t r o l y analisio automático de d a b experimentales

Cada archivo de unidad está compuesto de varias secciones:

1. La sección de Interface.

2. La sección de implementación.

3. La sección de inicialización.

Además de otros componentes importantes. A continuación se describen las secciones importantes dentro de una Unidad.

Sección lnferface

La sección de interface contiene la cabecera de información de la unidad. Esta incluye las declaraciones de funciones y procedimientos, así como las defmiciones de las variables, constantes y tipos que desean habilitarse. Para los programadores en C, esto es similar a los archivos *.h sin embargo, no es necesario almacenar en forma separada el código del archivo fuente. Una unidad compilada almacena la información de la interface en su encabezado. Cuando otro módulo hace referencia a esta unidad en su sentencia uses, Delphi analiza el encabezado de la unidad compilada, no su código fuente, para determinar si la interface está presente.

Esta aproximación le permite distribuir las unidades en Delphi tan solo como código objeto, sin la necesidad de un archivo de encabezado de cualquier género. Además esto e h i n a la redundancia que se genera al recompilar una cabecera cada vez que un módulo que la ocupa es compilado.

Esta aproximación es mejor que la que se utiliza en los compiladores C y representa el siguiente paso lógtco más allá del archivo de encabezados de C.

Secci6n lmplemenfafion

Contiene el código de programa de la unidad. Los puntos que se colocan aquí son visibles úricamente dentro de la misma unidad, a menos que se listen en la sección de interface. La organización tipica de una unidad coloca las declaraciones de las funciones en la sección de interface y su código en la sección de implementación.

Pdgina 55

Estudio para el desarrollo de un sistema de adquisición, control y análisis automitico de datos experimentales

Secci6n initialization

Cuando se necesita dar de alta código que se ejecute cuando la unidad se carga por primera vez, este debe colocarse en la sección de inicialización de la unidad. Cualquier cosa que se coloque en esta sección, se ejecutará al momento en que se carga la aplicación.

El orden en el cual se ejecuta el código de inicialización de la unidad, está determinado por la posición que este guarda dentro de la sentencia uses en el archivo fuentepmject.

Las formas de Delphi

Las formas de Delphi proporcionan a las aplicaciones la apariencia que estas tendrán en pantalla. La “forma” que tendrán los diseños, se almacena en un archivo deforma. Cuando se establece las propiedades o movimientos de los componentes, se estará modificando las características que se almacenaron en el módulo del archivo forma.

Debido a que las herramientas de Delphi se pueden utilizar de dos formas es posible editar una forma, y el texto, salvarlo, y entonces ver los cambios efectuados, en forma visual. Es decir, puede diseñarse una forma gráficamente, asignando las posiciones de sus componentes, y posteriormente editar en modo texto sus propiedades.

Los módulos de datos en Delphi

Delphi soporta un tipo especial de forma denominado aka modde, este modulo se crea seleccionando new &fa modtlle del menú$íe de Delphi, los módulos de datos permiten agrupar controles no visuales, (por lo general, componentes de bases de datos) dentro de una forma central.

Es posible referenciar los módulos de datos de otras formas en la aplicación para de algún modo referencia estos componentes de bases de datos. También es posible añadir módulos de datos al contenedor de objetos de Delphi (object repository) y heredar, copiar o usar estos tal y como otros miembros originales del contenedor. No es posible colocar controles visuales dentro de los módulos de datos: únicamente se permiten los controles no visuales.

Página S6


Archivos include

Como la mayoría de los lenguajes, el compilador de Delphi soporta archivos incZ.de, los cuales le permiten establecer secciones comunes de código de los que se desea compartir a través de diversos módulos. Debido a que Delphi recompila los archivos znchde cada vez que los encuentra en el código fuente, el programador deseará restringir su uso y sustituirlos por unidades siempre que sea posible, de modo que se optime el desempeño del sistema.

Una aplicación común de archivos include es la lista de las directivas de compilación utilizadas en varias unidades y para lograr que estas se recompilen automáticamente cuando los programadores alteran los contenidos de los archivos incZ.de.

Los componentes de Delphi

Los componentes son bloques atómicos de contrucción de las aplicaciones de Delphi. Combinan las formas de construcción, así como los átomos se combinan entre sí para formar moléculas. En la representación visual de las formas, es posible ver que el diseño de estas está basado en componentes construidos en código fuente de Pascal.

La füncionalidad que proporcionan los componentes se paga a un precio muy bajo. E l proceso para crear un nuevo componente consiste en activar el menú File/New Component. Usando esta opción, se especificarán las clases de las cuales se heredaran las propiedades, los nombres de las nuevas clases y las páginas en las cuales residen estas.

Fmtonces Delphi generará el código fuente necesario, mismo que se complementará con las características adicionales que el programador necesite para que el componente se comporte como sea necesario.

P&ina 57

Estudio para el desarrollo de un sistema de adquisición, control y análisis automática de dabs experimentales

Capítulo 8

Conclusiones

A lo largo de este reporte se plantearon las características fundamentales del problema, se propuso el modelo orientado a objetos como la base de la solución y se hace una introducción a este modelo, dado que a lo largo de la carrera no hay ninguna materia dentro del plan de estudios que lo presente aunque fuese en esencia, mucho menos a fondo, nos tuvimos que dar a la tarea de comprender los conceptos del modelo así como sus técnicas fundamentales. El paso siguiente consistió en la elección de la herramienta, la mejor opción resultó ser Delphi por todas las ventajas de compilación y potencia al manejar los niveles bajos de programación, que por la naturaleza del problema serán muy necesarios en la implementación del sistema final. En el último capítulo se presentó una breve radiografia de lo que es esta herramienta de desarrollo.

Ahora, para donde va el camino, nuestro objetivo al inició del proyecto fue desarrollar una plataforma sobre la cual se lograsen montar los prototipos de experimentos a desarrollar y establecer el control automatizado de estos.

Conforme avanzamos descubrimos que lo que en realidad necesitábamos era un compilador gráfico, que es algo en si complejo, no tanto como para no desarrollarlo, pero si lo bastante como para consumir una buena cantidad de recursos y sobre todo de tiempo.

Pagina 58

Estudio para el desarrollo de un sistema de adquisición, control y análisis autom¿itico de datos experimentales

La solución que encontramos al final, fue de algún modo utilizar la potencia que ya en si tiene Delphi como compilador gráfico para de alguna forma comenzar a escalar el sistema hasta lograr refinarlo en el tan anhelado compilador gráfico.

La pregunta aquí es (cómo utilizar Delphi para lograr arrancar con el proyecto?, la respuesta la encontramos cuando conocimos los componentes de Delphi, que no son otra cosa que objetos encapsulados y de los cuales solamente vemos su interface y están listos para interconectarse con otros componentes diferentes o iguales..

El objetivo se reduce entonces a crear tantos componentes como sean necesarios, para esto debe llevarse a cabo un análisis de las necesidades que se plantean en los laboratorios para, de este modo, reproducir los elementos que intervienen en los experimentos y reproducirlos en coqbonentes de Delphi, que puedan integrarse con otros componentes para reproducir el experimento.

La ventaja que de alguna manera obtenemos usando estos componentes es que son reutilizables, es decir, que una vez que se cree un componente multimetro para usarse en un experimento, este componente estará disponible en el ambiente de Delphi para ser reutilizado en otros experimentos.

L a pregunta sugerida en este momento es &ómo vamos a integrar estos componentes? Esto se conseguirá de una manera fácil con un poco de programación dentro del entorno de Delphi, misma que se reducirá en la medida en que los componentes estén bien definidos y se haya pensado en todas sus propiedades' y en sus mktodos*.

El problema con esta implementación radica que las personas que desarrollen estos componentes deben tener conocimientos tanto del modelo orientado a objetos como del ambiente de trabajo Delphi, pero esa barrera se puede salvar si el proyecto evoluciona a la siguiente etapa.

Una vez definida una buena cantidad de componentes. El siguiente paso en el refinamiento de este sistema consistirá en crear una plataforma especializada en la que puedan convivir de un modo sencillo los componentes antes creados, y que permita a usuarios no necesariamente expertos ni en el modelo orientado a objetos ni en la

Las p r o p i e d a d e s son todas aquellas caracteristicas que identifican a un componente. Los métodos son todas aquellas acciones que puede llevar cabo un oomponente.

Página 69

Estudio para el desarrollo de un sistema de adquisición, c o n t r o l y anidisis automático de datos experimentales

plataforma de diseño, crear sus propios experimentos y controlar las variables de estos.

Quizá el siguiente paso sea desarrollar o modificar la herramienta del refinamiento anterior para que los usuarios finales tengan una forma fácil de crear componentes.

Pdgina 60

Estudio para el desarrollo de un sistema de adquisición, control y analiris automático de datos experimentales

Bibliografía

Database Developeer’s Guide with Delphi 2.

Henderson, Ken

Editorial Borland Press

Delphi 2 Unleashed

Charles Calvert

Editorial Borland Press

Análisis y diseño de sistemas

Kendall & Kendall

Editorial Prentice Hall

Piglna 61

Análisis Estructurado Moderno

Yourdon

Editorial Prentice Hall

Pdgina 62

Estudio para el desarrollo de un sistema de adquisición . control y análisis automático de datos experimentales

lndice alfabético

I

1) AGENTES EXTERNOS ....................... 10

2

2) FLUJOS DE DATOS ............................ 12

3

3) PROCESOS .......................................... 14

A

Abstracclon ............................................... 23 Abstracción coincidental ........................... 24 Abstracción de Acción .............................. 24 Abstracción de Entidad ............................. 24 Abstracción de máquina virtual ................. 24 Acciones determinadas ............................ 12 Acciones priorizadas ............................... 12 Acciones solicitad as ................................. 12 Accron 8 M i s i s orientado a objetos ....................... 19 App1ication.Create.Form. .......................... 53

. r

., ........................................................

Application.Run ........................................ 5 3

c Clases ....................................................... 17 Clasificación de las señales de control ....... 10 componentes de Delphi ............................. S7 Conclusiones ............................................. S8 Condicron 8 Configuración de puertos ........................ 14 Control ....................................................... 8

D Datos formateados ................................... 12 Datos muestreados ................................... 12 Datos ordenados en pantalla ................... 12 Decodificaci6n del esquema de

comportamiento ................................... 14

.. ...................................................

Delphi ....................................................... 49 Determinación de acciones ...................... 14 Diagrama de contexto ................................. 6 Diagrama de flujo de datos ........................ 10 directiva $R ............................................... 52 Diseño orientado a objetos ......................... 19 DLL .......................................................... 53

E

Ejecución de acciones .............................. 14 Encapsulado ............................................. 26 Especificación de formato de almacbn y

datos para ser almacenados ................. 12 Especificaciones de puertos ..................... 13 Especificaciones del entorno grafico ....... 13 Especificaciones del sistema de

comportamiento ................................... 13 Esquema .................................................... 7 Esquema de Comportamiento del Sistema8 Estilo de programación .............................. 21 Evento ....................................................... 8 Excepciones ............................................... 25 export ....................................................... .S 3

F

formas de Delphi ....................................... 56

H Herencia .................................................... 33

I

IDE ........................................................... 53 include ...................................................... 57 Informacron 8 Instrucciones directas .............................. 13 Interpretación de las instrucciones

direct as ........................................... 14, 15

. r ...............................................

Pdgina 63

Estudio para el desarrollo de un sistema de adquisición. confrol y análisis automático de datos experimentales

..................... J Programa orientado a objetos 17 Jerarquía ................................................... 32

L project 50 projects de Delphi ..................................... 51

Programa orientado a procedimientos ........ 17 Programación orientada a objetos .............. 18

.......................................................

lybrary ...................................................... 53

M R

29 Muestras de las señales 13

Recepción de las muestras proporcionadas por las tarjetas 14 ............................................. .....................................

........................... Reglas ....................................................... 13 N

new data module ....................................... 56

O

object repository ........................................ 56 Organización de datos para ser

Organización de salida a pantalla .......... 14 almacenados ......................................... 15

Orientados a Mgica .................................. 2 1 Orientados a objetos .................................. 2 1 Orientados a procedimientos ..................... 2 1 Orientados a reglas ................................... 2 1 Orientados a restricciones ......................... 22

P Parámetros de un puerto ......................... 13 Postcondiciones ......................................... 24 Precondiciones .......................................... 24

program .................................................... 52 Priorización de acciones .......................... 14

S

Sección Implementation ............................. 55 Sección Initialization ................................ 56 Sección Interface ....................................... 55 Señales de control .................................... 13

T Tarjetas .................................................... 10 Tipeado ..................................................... 36 topología ................................................... 17

U unidades de Delphi .................................... 54 Uses .......................................................... 52 Usuario ..................................................... 11

V Visual Basic .............................................. 49 Visual C++ ................................................ 49

Página 64

universidad autonoma metropolitana …148.206.53.84/tesiuami/uam3631.pdf · ... construir su...

Documents