Prácticas para Crear Grandes Aplicaciones de LabVIEW con un Enfoque de Desarrollo Estructurado

Fecha de Publicación: Jun 11, 2008 | 8 Ratings | 4.12 out of 5 |  PDF

Visión General

Por muchos años, LabVIEW ha sido conocido como una herramienta de desarrollo fácil de usar para construir de sistemas de adquisición de datos y control de instrumentos de manera muy fácil y rápida. El lenguaje de programación gráfica LabVIEW, con su interfaz de usuario gráfica integrada, está hecho especialmente para crear rápidamente prototipos de sistemas. Esto resulta particularmente evidente con el desarrollo de Express VIs en LabVIEW 7, lo cual lo hizo mucho más fácil desarrollar sistemas de adquisición de datos con LabVIEW.

Sin embargo, en alguna forma, la simplicidad y velocidad para desarrollar un sistema con LabVIEW ha escondido el hecho de que LabVIEW es de hecho, un lenguaje de programación completo, hecho para manejar las aplicaciones más grandes y complejas que ingenieros y científicos se enfrentan hoy en día. En particular, programadores creando aplicaciones críticas – control embebido, aplicaciones de monitoreo industrial, sistemas de prueba de alto desempeño – no pueden darse el lujo de introducir errores o incertidumbre al sistema. Para este tipo de aplicaciones, debe seguirse un proceso de programación muy estructurado y en algunos casos, certificado por externos para asegurar la calidad y repetición de los códigos desarrollados. Específicamente, muchos ingenieros de prueba se enfrentan al reto de construir más y más sistemas de prueba complejos para mantenerse al día en cuanto a la creciente complejidad de los productos que están probando. Las situaciones donde un proceso de programación estructurado puede requerirse se pueden generalizar de la manera siguiente:

  • Cuando se construye una aplicación particularmente grande.
  • Cuando se trabaja como equipo en el código de prueba, requiriendo un acercamiento estructurado para asegurar que los miembros del equipo puedan trabajar con seguridad y eficiencia en diferentes áreas del proyecto sin conflicto alguno.
  • Cuando se trabaja en una industria o área de aplicación que requiere de un proceso de codificación a certificarse por una agencia gubernamental (FDA, FAA, etc.) o por un cliente (manufacturero automotriz trabajando con proveedores).
En todos estos casos, los ingenieros pueden fácilmente adecuar la herramienta o lenguaje al proceso. Por ejemplo, muchos ingenieros pueden pensar que estas situaciones requieren de un lenguaje de programación basado en texto par desarrollar el código de prueba. En realidad, un proceso estructurado para desarrollar códigos – en cualquier lenguaje – es independiente del lenguaje o herramienta utilizada. Este documento enfatiza en algunas prácticas comunes para el seguimiento de procesos de programación estructurada y muestra cómo LabVIEW puede ser utilizado en estas situaciones. Con la introducción de LabVIEW 8, LabVIEW incorpora un número de características nuevas que lo hacen una herramienta ideal para que científicos e ingenieros puedan construir sistemas a gran escala ó críticos que requieren de acercamientos de programación estructurada.

Contenido

  1. Generalidades del Proceso de Desarrollo de Software
  2. Requerimientos de Administración
  3. Diseñando una Aplicación Grande en LabVIEW
  4. Desarrollo – Organizando Archivos y Administrando Objetivos
  5. Desarrollo – Ingeniería de Software de Colaboración
  6. Desarrollo - Depuración
  7. Desarrollo – Procesos de Automatización
  8. Probando y Revisando el Código
  9. Distribuyendo Aplicaciones
  10. Conclusión

1. Generalidades del Proceso de Desarrollo de Software

En procesos de ingeniería de software estructurado, el desarrollo de software empieza con el establecimiento de los requerimientos tanto del sistema como del software continuando con el diseño de la arquitectura, desarrollo del código, prueba y distribución. Estas fases, definidas más adelante, se discuten en este documento con respecto al desarrollo del software con LabVIEW. Los usuarios LabVIEW deben seguir la mayor parte de los procedimientos que los diseñadores que usan lenguajes más tradicionales como C, con excepción de algunas veces en que se requieran de herramientas y prácticas únicas a discutir más a detalle. Las fases generales del desarrollo de software son típicamente las siguientes:

  • Requerimientos y Especificaciones. Establecen los componentes para construir el sistema, incluyendo los requerimientos del hardware, herramientas de software, y otros componentes necesarios. Ejemplos incluyen decisiones en hardware, como tableros de conexión (número de canales, velocidad de adquisición, y más), y decisiones en piezas externas del software, como bases de datos o bibliotecas. También establece las expectativas para la funcionalidad del software e identifica qué requerimientos del sistema son afectados por el software. El análisis de requerimientos incluye la determinación de interacción requerida con otras aplicaciones, requerimientos de desempeño, requerimientos de interfase con el usuario, y más.
  • Diseño. Determina el marco de trabajo del software del sistema para cubrir con los requerimientos especificados. El diseño define los componentes del sistema y su interacción. Los desarrolladores también determinan la interfaz externa y herramientas a utilizar en el proyecto.
  • Desarrollo. Implementa la especificación de diseño en código. El desarrollo puede ser completado por un solo desarrollador; para un equipo se requieren procesos adicionales para compartir códigos y aseguran la calidad y consistencia. Esta fase también incluye la depuración del código.
  • Prueba. Determina si el software cumple con los requerimientos especificados y encuentra cualquier error presente en el código.
  • Distribución. Empaque y entrega del software al usuario final.  

Regresar al Inicio

2. Requerimientos de Administración

Un paso clave en el desarrollo de cualquier sistema grande es la captura previa de los requerimientos del sistema, antes de que inicie cualquier desarrollo serio. Los desarrolladores del sistema usan muchas aproximaciones diferentes para capturar y documentar los requerimientos del sistema, desde simples documentos Microsoft Word o Excel al uso de herramientas de administración para requerimientos especiales como Telelogic DOORS o IBM Rational Requisite Pro. La clave para administrar requerimientos consiste en documentar claramente lo que son, para posteriormente asociarlos con facilidad al código actual que implementa cada uno (en caso de proyectos de software embebido) o prueba cada uno (en el caso de un sistema de prueba). Con la herramienta NI Requirements Management Gateway, los usuarios asocian fácilmente sus requerimientos con VIs de LabVIEW específicos para rastrear su implementación. La herramienta proporciona las siguientes características:

  • Usuarios pueden documentar sus requerimientos utilizando archivos de texto, Microsoft Word, Excel, o Project, Telelogic DOORS, IBM Requisite Pro y otras herramientas. Si no están utilizando actualmente cualquiera de estas herramientas, pueden utilizar el administrador simplificado de requerimientos que se incluye en la herramienta.
  • Usuarios pueden ligar cada requerimiento a VIs de LabVIEW específicos a través del LabVIEW Project (Proyecto de LabVIEW), introducido en LabVIEW 8, para rastrear fácilmente la forma en que cada requerimiento es implementado o probado.
  • Usuarios pueden rastrear requerimientos según se vayan cambiando. Por ejemplo, a medida que se desarrollan proyectos, con frecuencia cambian los requerimientos. Con la herramienta, los usuarios pueden rápidamente ver cuándo es que un requerimiento cambia y puede ser notificado respecto a qué VI está asociado con el requerimiento probando nuevamente que el requerimiento ya haya sido cubierto.  

Regresar al Inicio

3. Diseñando una Aplicación Grande en LabVIEW

Después de definir los requerimientos del sistema, mucho desarrolladores LabVIEW inician de inmediato con un método de desarrollo de codificar y corregir, construyendo VIs que creen necesitar, para posteriormente darse cuenta que necesitan de algo completamente diferente. Consecuentemente, tal técnica resulta en desarrollos innecesarios, trabajo ineficiente, o código descartado. Los desarrolladores que utilizan LabVIEW para crear grandes aplicaciones deben invertir tiempo en considerar cómo convertir sus requerimientos del sistema a un código de manera óptima.

El diseño de aplicaciones grandes en LabVIEW no es tan diferente al diseño del software en cualquier lenguaje y se centra en la división de la aplicación en pequeñas piezas lógicas de tamaño manejable. Sin embargo, la metáfora de programación del diagrama de bloques en LabVIEW hace que el diseño inicial a final de una aplicación sea muy directa e intuitiva. La mayoría de los ingenieros ya emplean diagramas de bloque para describir sus sistemas de prueba y control, lo cual hace mucho más fácil la conversión de estos diagramas de bloque en códigos de trabajo LabVIEW. Los desarrolladores pueden iniciar con un diagrama de bloques de alto nivel que incluya componentes principales de una aplicación, las cuales pueden incluir diferentes secciones para configuración, adquisición, análisis, desplegado de datos, acceso a datos y manejo de errores. Después de diseñar el diagrama de bloques de alto nivel, los desarrolladores pueden definir entradas y salidas de los subVIs vacíos. Finalmente, se crea la funcionalidad elemental de los subVIs que hacen el diagrama de bloques de alto nivel.

El entorno de desarrollo de LabVIEW incluye muchas plantillas de diseño que pueden utilizarse para tipos de aplicaciones específicas, como Productor/Consumidor, Maestro/Esclavo, Máquinas de Estado y Manejo de Evento. Los desarrolladores pueden utilizar estas plantillas de diseño como puntos de inicio al momento de desarrollar software nuevo con el uso de LabVIEW.

Para obtener mayor información respecto al uso de las plantillas de diseño LabVIEW, por favor visite aquí.  

Regresar al Inicio

4. Desarrollo – Organizando Archivos y Administrando Objetivos


Durante la fase de desarrollo, los usuarios de LabVIEW trabajan para traducir el diseño del software en código LabVIEW. A medida que una aplicación crece, se requieren herramientas para ayudar a administrar los archivos asociados con la aplicación, como los VIs, documentación, bibliotecas de terceros, archivos de datos, configuraciones iniciales para el hardware. Al iniciar con LabVIEW 8, los ingenieros pueden utilizar el LabVIEW Project para agrupar archivos LabVIEW con otros tipos, crear especificaciones de construcción, y desplegar o descargar archivos a objetivos. Los usuarios LabVIEW tienen una vista a los archivos del sistema, construyen especificaciones y objetivos a través de la ventana denominada Project Explorer (Figura 1). A través de la ventana Project Explorer, los desarrolladores pueden interactuar en conjunto con los archivos relacionados con el proyecto y grupo dentro de directorios virtuales.

Figura 1. Project Explorer de LabVIEW

La información de proyectos, que incluye referencias a los archivos en el proyecto, información de configuración, información de construcción, información de desplegado, y más, es almacenada en un archivo legible para el humano llamado XML project file (.lvproj) el cual, puede ser editado fuera de LabVIEW y rastreado con las herramientas de administración de códigos fuente (ver Figura 2).

Figura 2. XML Project File

Dentro del proyecto de LabVIEW, los desarrolladores pueden utilizar directorios virtuales para organizar todos los archivos que conforman su aplicación. Los directorios son de naturaleza lógica y no reflejan los directorios de archivo en disco. Esta división de la organización de archivos en la PC y la organización de los archivos en el proyecto de LabVIEW promueve el nuevo uso del mismo código en múltiples proyectos, cada uno dentro de su configuración muy particular, según su organización. Por el contrario, para estandarizar cada proyecto en la organización, requeriría mantener múltiples copias del código. Para simplificar la migración del código LabVIEW existente y otros archivos hacia un proyecto, LabVIEW permite a usuarios importar a un proyecto directorios completos. Sin embargo, una vez importado, el directorio virtual y el directorio dentro del sistema operativo ya no está sincronizado y cualquier cambio al contenido de un directorio no se verá reflejado en el otro. Esta característica asegura que la organización de archivos en LabVIEW sea independiente de la organización en disco.

Para mayores informes referente a esta materia, por favor refiérase al documento titulado Administrando Grandes Aplicaciones con el Proyecto de LabVIEW   (en inglés).  

Regresar al Inicio

5. Desarrollo – Ingeniería de Software de Colaboración

Si múltiples desarrolladores trabajan en el mismo proyecto, es importante definir claramente la interfaz al código e identificar los estándares de codificación para asegurar que los diferentes componentes sean fáciles de comprender y trabajen entre sí. Esto, puede lograrse a través de lo siguiente:

  1. Hacer que el código sea modular y proporcione una interfaz estándar.
  2. Almacenar copias maestras de los archivos del proyecto, incluyendo VIs, en un solo servidor e instituir una política de control de códigos fuente.
  3. Implementar estándares de codificación dentro de un grupo o compañía

Modularidad de Código en LabVIEW
Grandes aplicaciones de LabVIEW requieren de un acercamiento de desarrollo modular en el cual el sistema completo es dividido en componentes lógicos. Esto es muy importante cuando múltiples desarrolladores trabajan juntos en un proyecto y requieren responsabilidades de programación bien definidas. LabVIEW es, por definición, un lenguaje de programación modular. Cada VI de LabVIEW puede ejecutarse como una aplicación individual, o ser llamada por otro VI como subVI. Un subVI corresponde a una llamada de subrutina en lenguajes de programación basados en texto. Los controles e indicadores (perillas, medidores, válvulas, desplegados gráficos, etc) del subVI reciben datos del VI que llama y regresan los datos al diagrama de bloques. Los desarrolladores deben crear subVIs para tareas independientes dentro de la aplicación LabVIEW. Usar subVIs modulares como parte de una aplicación más grande, simplifica el diagrama de bloques de alto nivel del VI y también ayuda en la administración de cambios y depuración del sistema.
A medida que trabajan en equipo personas dentro de un proyecto de desarrollo de software común, requerirán inevitablemente compartir códigos. En tales casos, es importante para los desarrolladores, proporcionar a su código una interfaz definida. Por ejemplo, un sistema complejo de monitoreo de datos puede tener un conjunto de VIs para desplegar y manipular datos y otro conjunto de VIs para adquirir y almacenar información. Estos dos módulos son sustanciales, no se traslapan, y pueden asignarse a diferentes desarrolladores. Inevitablemente, existe alguna interacción entre estos módulos. Una interfaz definida para cada módulo identifica cómo es que esos módulos interactúan unos con otros. Siempre y cuando los módulos se comuniquen a través de interfases definidas, su arquitectura y funcionalidad puede alterarse sin causar fallas no intencionadas. Para facilitar la creación de tales interfases definidas a los VIs, LabVIEW 8 proporciona la project library, la cual lleva a un paso más allá la modularidad permitiendo la creación de interfases definidas a un conjunto de VIs.

Una biblioteca de proyectos es un conjunto de VIs y otros archivos de LabVIEW los cuales tienen dos beneficios principales:

  • Las bibliotecas de proyecto califican nombres de miembros de VIs y otros archivos LabVIEW. La autorización de un nombre de archivo incluye el nombre del archivo y la adjudicación del nombre del archivo de la biblioteca de proyecto, ayuda también a asegurar que los nombres de los miembros sean únicos, especialmente cuando la biblioteca será usada nuevamente en múltiples proyectos que contienen diversas bibliotecas.
  • Las bibliotecas de proyecto limitan el acceso a ciertos archivos. Los desarrolladores pueden configurar el acceso a objetos y directorios en una biblioteca de proyecto ya sea como pública o privada para prevenir que los usuarios tengan acceso a ciertos objetos. Los miembros privados solamente pueden ser llamados como subVIs por otros miembros de la misma biblioteca. Esta restricción asegura que los desarrolladores que dependan de esta biblioteca solamente utilicen la interfaz pública para tener acceso a los VIs, mitigando los efectos de los cambios que el VI privado pueda tener posteriormente.


Para mayores informes referentes a este tema, por favor refiérase al documento Compartiendo Códigos con el Project Library de LabVIEW (en inglés).

Compartiendo Código con Software de Control de Código Fuente
Al inicio del proyecto de desarrollo de software, los ingenieros deben implementar un proceso para lidiar con los cambios y compartir trabajo. Este proceso resulta crítico para proyectos con múltiples desarrolladores trabajando de manera colaborativa. Las herramientas de control de código fuente son la mejor solución para resolver el problema que implica compartir códigos y controlar el acceso para evitar pérdida accidental de datos. El software de control de código fuente rastrea cambios a los módulos de código y facilita el proceso de compartir archivos entre múltiples usuarios y proyectos de software. El software de control de código fuente también funge como incentivo para utilizar el mismo código una y otra vez haciendo que todos los códigos sean fácilmente accesibles. Aunado a mantener el código fuente como VIs, el software de control de código fuente puede manejar otros aspectos de un proyecto de software. Por ejemplo, un desarrollador puede utilizar un software de control de código fuente para rastrear cambios realizados a especificaciones próximas y otros documentos.

El software de control de código fuente mantiene una copia maestra centralizada de los archivos del proyecto. Cuando un desarrollador decide modificar un archivo, revisa el archivo del control de código fuente para editarlo. Esta acción, marca el archivo con el nombre del desarrollador para que ningún otro lo modifique al mismo tiempo. Después de la edición, el desarrollador revisa en la nueva versión del archivo, la cual se convierte en parte de la copia maestra, está ahora disponible nuevamente para todo el equipo. En este momento, un segundo desarrollador puede revisar el archivo y realizar ediciones posteriores. Cada vez que un archivo sea registrado, el software de control de código fuente avisa al usuario para describir los cambios realizados. El software de control de código fuente mantiene esta información para que los desarrolladores puedan documentar claramente la evolución de cada archivo en el proyecto.


LabVIEW proporciona integración con proveedores de control de código fuente estandarizados como Microsoft Visual SourceSafe, Perforce, Rational ClearCase, PVCS Version Manager, MKS Source Integrity y software libre como CVS. A través de esta integración, los desarrolladores pueden revisar archivos dentro y fuera del control de código fuente dentro del ambiente LabVIEW, así como obtener los registros históricos de los archivos y realizar diferenciación gráfica en VIs para identificar visualmente ediciones hechas entre versiones. Para revisar un VI dentro y fuera de LabVIEW una vez que el proveedor de control de código fuente ha configurado, un desarrollador simplemente presiona con el botón derecho sobre el archivo en el Project Explorer y selecciona la acción apropiada del menú. LabVIEW permite que el software de control de código fuente sea utilizado con todos los archivos en un proyecto de LabVIEW o granularmente con archivos individuales (ver Figura 3).

Figura 3. Integración LabVIEW con las Herramientas de Control de Código Fuente

Los desarrolladores que usan LabVIEW para crear aplicaciones grandes deben seguir las siguientes recomendaciones:

  • Almacenar todos sus archivos que sean parte de una aplicación – VIs, bibliotecas externas, requerimientos, especificaciones, ilustraciones, revisiones, y otro documentos – en una herramienta de control de código fuente para controlar el acceso a estos archivos y compartirlos según se necesite.
  • Bloquear VIs cuando estén en la etapa de edición; LabVIEW actualmente no cuenta con una característica de fusión, así que solo un desarrollador debe editar el VI en ese momento.
  • Utilizar la herramienta de diferenciación gráfica para ver los cambios realizados entre el VI que está siendo editado y la última versión revisada almacenada en el control de código fuente.

Para más información acerca de este tema, referirse al documento titulado Uso de Software de Control de Código Fuente con LabVIEW (en inglés).

Guías de Estilo
Un desarrollador o grupo de desarrolladores debe siempre implementar prácticas de codificación estándar para un proyecto de desarrollo de software; los estándares de codificación son críticos al momento de desarrollar programas de software con calidad en cualquier ambiente de desarrollo de aplicación. Sin embargo, estas prácticas desarrolladas para otros lenguajes como C no necesariamente aplican al modelo gráfico orientado a flujo de datos utilizado en LabVIEW. Para promover buenos estándares de codificación, National Instruments ha desarrollado guías de estilo especiales para LabVIEW. Para obtener información respecto a las guías de estilo, por favor refiérase a las Guías de Estilo de LabVIEW.
 

Regresar al Inicio

6. Desarrollo - Depuración

Las capacidades de depuración son clave para un ambiente de desarrollo, y LabVIEW cuenta con herramientas de depuración comparables a aquellas disponibles en lenguajes de programación basadas en texto, así como herramientas únicas solamente posibles en lenguajes gráficos. Estas herramientas de depuración incluyen:

  • Ejecución resaltada, la cual muestra el movimiento de datos en el diagrama de bloques de un nodo a otro utilizando puntos que se mueven a través de los cables.
  • Paso a paso, guiando por partes a través del VI y mostrando cada acción en el diagrama de bloques a medida que se ejecuta.
  • Puntos de quiebre, los cuales pueden ser colocados en un VI, nodo, o cable en el diagrama de bloque para pausar la ejecución en cualquier localidad.
  • Puntas de prueba, los cuales despliegan valores intermedios en un cable a medida que se ejecuta un VI.


Los desarrolladores también pueden ejecutar un VI con una sección del diagrama de bloques deshabilitado, similar a que una sección del código sea ignorado en un lenguaje de programación basada en texto. Deshabilitar partes del código sin que el programa entero sea inoperable resulta una técnica valiosa cuando el código no es ejecutable o presenta fallas. LabVIEW 8 proporciona esta funcionalidad a través de la nueva Diagram Disable Structure (Estructura para Deshabilitar Diagramas) (Figura 4). Cada estructura contiene dos o más marcos – al menos un marco contiene un código deshabilitado, el cual es completamente ignorado por el compilador LabVIEW y no es ejecutado cuando el VI es ejecutado. Un solo marco puede contener el código que ejecutará al correr el VI. Una segunda estructura, Conditional Disable Structure (Estructura Condicional Deshabilitada), puede utilizarse como el #if-def en lenguaje C para habilitar o deshabilitar partes de manera global en el diagrama de bloques.

Figura 4. Diagram Disable Structure de LabVIEW

La herramienta VI Profiler en LabVIEW (ver Figura 5) ayuda a evaluar el desempeño midiendo dónde es que la aplicación invierte su tiempo y aloja memoria durante la ejecución. Por tanto, esta herramienta resulta útil para la depuración de una aplicación para descubrir dónde está el mal funcionamiento.

Figura 5. Herramienta VI Profiler de LabVIEW  

Regresar al Inicio

7. Desarrollo – Procesos de Automatización

Los usuarios de LabVIEW pueden utilizar el LabVIEW VI Server para cargar, editar y ejecutar los VIs dinámicamente en una computadora o bien, a través de una red de trabajo remota. LabVIEW 8 simplifica dramáticamente la programación del servidor con el Class Browser, una ventana interactiva que despliega todas las propiedades del servidor así como sus métodos en un árbol organizado (ver Figura 6). Una vez que el desarrollador selecciona una propiedad o método del servidor, puede arrastrarlo del Class Browser directamente al diagrama de bloques para generar automáticamente la propiedad apropiada o invocar el nodo apropiado. El Class Browser también opera en las propiedades y métodos localizados en las bibliotecas externas ActiveX y ensambles .NET.

Figura 6. Class Browser de LabVIEW.

Los desarrolladores pueden utilizar las propiedades del servidor así como sus métodos para el proyecto de LabVIEW y bibliotecas de proyecto, así como los VIs en el control de código, las paletas de VI Analyzer y Application Builder, para automatizar procedimientos que son parte del proceso de desarrollo del software. Por ejemplo, los desarrolladores pueden utilizar los VIs de Application Builder para automatizar la creación de ejecutables e instaladores durante el proceso de prueba, ahorrando tiempo valioso y reduciendo la posibilidad de inconsistencias en la creación de ejecutables.  

Regresar al Inicio

8. Probando y Revisando el Código

Las pruebas no son planes de últimas hora, sin embargo los ingenieros bajo la presión de una fecha límite, con frecuencia prestan menos atención a la fase de prueba, dedicando más tiempo a otras fases del desarrollo. Aún así, el periodo de prueba es clave para que un proyecto de desarrollo de software sea exitoso y el nivel de prueba refleja la calidad de las metas. A medida que los desarrolladores crean los requerimientos y especificaciones de diseño desde el inicio del proyecto del software, deben desarrollar de forma simultánea un plan para verificar que el sistema y todos sus componentes funcionen correctamente. Dentro de un proyecto de desarrollo de software, las metodologías de prueba deben estandarizarse y los resultados de las pruebas deben rastrearse.

El realizar pruebas manuales en su totalidad es prácticamente inconcebible, la mayoría de las organizaciones automatizan las pruebas al software en menor o mayor grado. LabVIEW hace que la automatización del proceso de prueba sea muy fácil – los VIs de LabVIEW pueden ser fácilmente probados como módulos de código individuales al crear controles de entrada e indicadores de salida, con terminales que corresponden a cada conector del VI. Un VI de alto nivel puede entonces llamar al VI bajo prueba como un subVI y pasarlo por varias entradas a través del diagrama de bloques mientras revisa y despliega las salidas.

Para obtener mayores informes en cuanto a pruebas formales de código LabVIEW por favor refiérase al documento titulado Procedimiento de Prueba de Validación de Unidades LabVIEW (en inglés).

Cuando un desarrollador se sienta a una revisión de código, lleva al revisor a través de la ruta principal del código y contesta cualquier pregunta. El código debe reflejar el diseño acordado y la discusión debe enfocarse principalmente en su arquitectura. (máquina de estado, productor/consumidor, etc.). Algunos de los tópicos que pueden discutirse incluye la facilidad con la que se agrega una nueva característica o modifica de acuerdo a la arquitectura del código, cómo es que son reportados y manejados los errores, y si el código es lo suficientemente modular. Si se utilizan variables globales o locales, el desarrollador debe explicar cómo es que se ha eliminado la posibilidad de condiciones de carrera. El desarrollador también puede demostrar que el código no utiliza todos los recursos del procesador o bien, que utiliza una cantidad de memoria prohibitiva.

Para simplificar la preparación de revisión del código, los desarrolladores necesitan tomar ventaja de las herramientas que le ayudan a inspeccionar el código de automatización e identificar mejoras. Un ejemplo es el LabVIEW VI Analyzer, mostrado en la Figura 7, el cual analiza el código LabVIEW y encamina al usuario a través de las pruebas de fallas. El VI Analyzer contiene más de 60 pruebas las cuales abordan un amplio rango de conflictos de desempeño y estilo. Estas pruebas están organizadas en categorías principales del diagrama de bloques, pantalla principal, documentación y general, las cuales unifican conflictos como propiedades del archivo, íconos y conectores, así como propiedades del VI. Con el VI Analyzer, los desarrolladores pueden mejorar el desempeño del VI, su uso y mantenimiento. VI Analyzer opera como una guía interactiva o puede llamarse también programáticamente a través de su API. En ambos casos, los desarrolladores tienen control granular sobre las pruebas que usted ejecuta en cada uno de sus VIs. También genera reportes de tal manera que los desarrolladores puedan rastrear mejoras en el código a través del tiempo, las cuales deben revisarse dentro del control de código fuente junto con otros archivos del proyecto.

Figura 7. VI Analyzer de LabVIEW

 

Regresar al Inicio

9. Distribuyendo Aplicaciones

Como conclusión del desarrollo y pruebas, los desarrolladores deben empacar y entregar el software terminado. El LabVIEW Application Builder (Constructor de Aplicaciones) proporciona la tecnología para construir ejecutables, DLLs, distribuciones fuente y archivos en zip. Adicionalmente, los desarrolladores pueden utilizar el Application Builder para crear instaladores Windows de tal manera que el usuario final tenga una experiencia de instalación y aplicación confiable y conveniente. El usuario final puede correr un ejecutable LabVIEW en cualquier computadora con el Run-Time Engine de LabVIEW instalado.

Figura 8. LabVIEW Application Builder

En LabVIEW 8, el Application Builder ahorra especificaciones de construcción como parte del proyecto. Una especificación de construcción contiene todas las configuraciones para la construcción, como los archivos a incluir, directorios a crear, y configuraciones para directorios de VIs. Sin embargo, los desarrolladores con especificaciones de versiones previas de LabVIEW pueden importarlas a LabVIEW 8.0. Cuando los desarrolladores importan una codificación ya escrita, LabVIEW creará un proyecto para ella automáticamente y agregará cualquier archivo asociado con la importación de la codificación construida. En LabVIEW 8, el Application Builder puede reunir software adicional tal como dispositivos de hardware, configuraciones de hardware, el Run-Time Engine de LabVIEW y licencias a un solo instalador con archivos ejecutable u otro archivo ya construido.

Al crear software autónomo a utilizarse en otras computadoras que no cuentan con el entorno de desarrollo LabVIEW instalado, los desarrolladores pueden utilizar el Application Builder para crear ejecutables y DLLs que pueden depurarse remotamente a través de una red de trabajo. Utilizando esta característica, se puede tomar ventaja de las características de diagnóstico como Ejecución Resaltada, puntas de prueba, y ejecución paso a paso mientras se utiliza una aplicación construida. Esto permite a los desarrolladores afinar sus entregas antes de que el usuario final lo utilice.

Para mayores informes sobre el tema, refiérase al documento Distribuyendo Aplicaciones con el LabVIEW Application Builder (en inglés).  

Regresar al Inicio

10. Conclusión

A pesar de ideas falsas, LabVIEW puede y es utilizado dentro de procesos de ingeniería de software para crear sistemas grandes. LabVIEW 8 introduce muchas nuevas herramientas que simplifican el diseño, prueba y distribución del software. Sin embargo, el proceso global utilizado para crear grandes aplicaciones con LabVIEW es muy similar a los lenguajes basados en texto y, en muchos casos, las herramientas provistas por LabVIEW ofrecen facilidad de uso y productividad no encontradas en otro entorno de desarrollo.  

Regresar al Inicio

Bookmark & Share

Ratings

Rate this document

Answered Your Question?
Yes No

Submit